LiveChat 
Support 
What Is a Central Certificate Authority? A Clear Guide to Public and Internal CAs
Every time your browser shows a padlock next to a web address, an invisible chain of trust is being verified in milliseconds. At the root of that chain sits a certificate authority (CA) — a trusted entity that issues and signs the digital certificates proving a website, server, or device is who it claims to be. Understanding what a CA is, and the difference between a public CA and a central certificate authority run internally by an organization, is essential for anyone managing modern infrastructure.
This guide explains what a certificate authority does, how the CA hierarchy and chain of trust work, why organizations operate their own internal CAs, and — critically — when you must use a public CA instead.
Key Takeaways
• A certificate authority is a trusted entity that issues and digitally signs certificates, vouching for the identity behind a public key. It is the foundation of SSL/TLS trust.
• Public CAs are pre-trusted by browsers and operating systems, so their certificates work everywhere. Private/internal CAs are run by an organization for its own services and are trusted only by devices that have the internal root installed.
• A central certificate authority usually means a centralized internal CA that issues certificates for an organization’s apps, servers, devices, and microservices.
• The CA hierarchy runs root CA → intermediate CA → end-entity (leaf) certificates. Roots are kept offline; intermediates do the day-to-day signing.
• Never use a private CA for a public website — browsers will not trust it. Use a public CA (or free Let’s Encrypt) for anything public-facing.
What is a certificate authority?
A certificate authority is an organization or system that issues digital certificates. A digital certificate binds a public key to an identity — a domain name, a server, a person, or a device — and the CA digitally signs that binding to vouch for it.
When a CA signs a certificate, it is making a verifiable statement: “We have checked, to some standard, that this public key really belongs to this identity.” Because the CA’s signature can be cryptographically verified, anyone who trusts the CA can trust the certificates it issues without contacting the CA directly.
This is the bedrock of SSL/TLS — the protocol that encrypts traffic between browsers and websites. The encryption protects the data in transit, but the certificate (and the CA behind it) is what answers the more important question: *am I actually talking to the right server, and not an impostor?*
How does the CA hierarchy work?
CAs do not operate as a single flat layer. They are structured in a hierarchy so that the most sensitive key — the one everything else depends on — can be protected.
The hierarchy has three main tiers:
- Root CA — the top of the chain. Its certificate is self-signed and its private key is the ultimate anchor of trust. Because compromising it would invalidate everything beneath it, the root key is kept offline in a hardened, often air-gapped environment and used rarely.
- Intermediate CA — signed by the root, the intermediate does the actual day-to-day issuance. Operators can run several intermediates, revoke a compromised one, and rotate it without touching the precious root.
- End-entity (leaf) certificate — the certificate installed on your web server, load balancer, or device. It is signed by an intermediate and is what clients actually validate.
Here is how those roles compare:
| Tier | Signed by | Key handling | Primary role |
|---|---|---|---|
| Root CA | Itself (self-signed) | Kept offline / air-gapped, used rarely | Anchor of trust for the entire hierarchy |
| Intermediate CA | The root CA | Online but tightly secured | Issues and signs end-entity certificates |
| End-entity (leaf) | An intermediate CA | Lives on the server/device | Identifies a specific site, server, or device |
This layered design means a problem at the intermediate level can be contained and replaced, while the root — the part that browsers and operating systems actually trust — stays insulated.
What is the chain of trust and how do clients verify it?
The chain of trust is the path a client follows from a leaf certificate back to a trusted root.
When your browser connects to a secure site, the server presents its leaf certificate, usually bundled with the intermediate(s) above it. The client then:
- Reads the leaf certificate and checks which intermediate signed it.
- Verifies the intermediate’s signature, then checks which root signed the intermediate.
- Confirms that root exists in its local trust store — the pre-installed list of trusted root CAs shipped with the browser or operating system.
- Validates each signature up the chain, checks expiry dates, and confirms the certificate has not been revoked.
If every link verifies and the root is trusted, the connection succeeds silently. If any link is broken — an expired certificate, a missing intermediate, or a root the client does not recognize — the client throws a warning.
That final point is the crux of the public-versus-private distinction: trust ultimately depends on whether the root is in the client’s trust store.
What is the difference between a public CA and a private/internal CA?
A public CA is one whose root certificate is already distributed in the trust stores of major browsers and operating systems. To get there, public CAs must pass strict audits and follow industry baseline requirements. Their certificates are trusted everywhere, automatically — which is exactly what a public website needs.
A private or internal CA is one an organization runs itself. This is what people most often mean by a central certificate authority: a single, centralized internal CA that issues certificates across the organization. Its root is not in any public trust store, so its certificates are trusted only by devices on which the organization has manually installed that root.
| Aspect | Public CA | Private / Internal (Central) CA |
|---|---|---|
| Trusted by | All major browsers and OSes by default | Only devices with the internal root installed |
| Run by | Audited, third-party CA provider | Your own organization |
| Best for | Public websites, public APIs, anything internet-facing | Internal apps, servers, devices, microservices |
| Validation | Domain/organization checks per industry rules | Your own internal policies |
| Cost model | Per-certificate or free (e.g. Let’s Encrypt) | Infrastructure and operational cost you control |
| Revocation/control | Managed by the provider | Fully under your control |
Why would an organization run a central/internal CA?
Running a central certificate authority internally is common in mid-to-large infrastructures, for several practical reasons:
- Issuing certificates for internal services. Internal dashboards, databases, admin panels, and APIs that never face the public internet still benefit from TLS. An internal CA can issue certificates for hostnames that a public CA would not (or should not) certify.
- Microservices and mTLS. In service-mesh and zero-trust architectures, every service authenticates every other service using mutual TLS (mTLS). That can mean thousands of short-lived certificates rotating constantly — far cheaper and faster from an internal CA you control.
- Cost and scale. Issuing large volumes of certificates from your own CA avoids per-certificate friction.
- Control and policy. You set the validity periods, naming rules, key types, and revocation behavior to match your own security posture.
The trade-off is responsibility: when you run the CA, you own the security of the root key, the issuance process, and the revocation infrastructure. A compromised internal root can undermine trust across your entire estate.
The single most important rule of internal CAs: a private CA’s certificates are trusted *only* by devices that have its root certificate installed. That is a feature, not a bug — it is precisely why an internal CA is ideal for internal services, where you control every endpoint and can distribute the root. But it is also the reason you must never use a private CA for a public website. A visitor’s browser has no way to trust your internal root, so it will display a loud security warning and block or scare away users. For anything public-facing, use a public CA — or free, automated Let’s Encrypt — so the certificate is trusted everywhere by default. Match the CA to the audience: internal root for internal devices, public CA for the public internet.
What tools are used to run a central certificate authority?
Several well-established tools let organizations stand up and operate an internal CA:
- Microsoft Active Directory Certificate Services (AD CS) — deeply integrated with Windows and Active Directory, widely used in enterprise environments to auto-enroll certificates to domain-joined machines.
- OpenSSL — the foundational open-source toolkit. You can build a CA with it manually, which is excellent for learning and small setups, though it requires careful key and process management.
- step-ca (Smallstep) — a modern, open-source CA designed for automation, short-lived certificates, and ACME-style issuance, popular for cloud-native and microservice environments.
- HashiCorp Vault PKI — a secrets-management platform with a PKI engine that issues certificates dynamically, well suited to dynamic infrastructure and mTLS at scale.
The right choice depends on your environment: AD CS for Windows-centric enterprises, step-ca or Vault for cloud-native and automated workloads, and OpenSSL when you need full manual control or are running a small, focused CA.
How do public and private CA use cases differ in practice?
A simple way to decide: ask who needs to trust the certificate.
- Public-facing? Your website, customer-facing API, or anything a stranger’s browser must trust → public CA (or Let’s Encrypt). The certificate must validate against trust stores you do not control.
- Internal only? Service-to-service mTLS, internal admin tools, IoT or device fleets, staging environments → internal/central CA. You control every endpoint, so you can distribute your root and gain cost, automation, and policy advantages.
Many organizations run both: a public CA for everything internet-facing and a central internal CA for the private network. The two are not competitors — they serve different audiences.
Securing public and private infrastructure with DarazHost
Whether you need certificates the whole world trusts or a private CA only your devices trust, hosting choices matter.
For public-facing websites, include free SSL certificates from trusted public CAs, issued and renewed automatically so your sites are encrypted and trusted in every browser without manual work. That is the right path for any site real visitors reach.
For teams building internal services or custom PKI, a gives you full root access to run your own central certificate authority with tools like step-ca, OpenSSL, or HashiCorp Vault — ideal for microservice mTLS, internal apps, and device fleets. With reliable infrastructure and 24/7 expert support, you can build and operate the CA architecture your environment needs, public and private side by side.
Frequently asked questions
What is the difference between a CA and an SSL certificate? A certificate authority is the trusted entity that issues and signs certificates. An SSL/TLS certificate is the issued document that binds a public key to an identity (such as a domain). The CA is the issuer; the certificate is what it issues.
Is “central certificate authority” the same as a private CA? In most contexts, yes. “Central certificate authority” usually refers to a single, centralized internal CA that an organization runs to issue certificates across its own apps, servers, and devices. It is private because its root is not in public trust stores.
Why won’t browsers trust my internal CA’s certificate? Because your internal CA’s root certificate is not in the browser’s trust store. Browsers only trust roots from audited public CAs by default. Internal certificates are trusted only on devices where you have manually installed the internal root.
Can I use Let’s Encrypt instead of running my own CA? For public-facing services, yes — Let’s Encrypt is a free, automated public CA trusted everywhere, and it is usually the simplest option. For internal-only services and mTLS, an internal CA is typically the better fit because you control issuance and trust distribution.
Why are root CA keys kept offline? The root key is the anchor of the entire chain of trust; if it were compromised, every certificate beneath it could be forged. Keeping it offline and air-gapped, and using intermediates for daily signing, drastically limits exposure.
