A Certificate Authority is the trusted entity that issues, signs, and manages digital certificates. Without CAs, there would be no reliable way to verify identities online. Every secure connection starts with trust in a CA.
Imagine you need to buy a house. Before the bank hands over the mortgage, a notary verifies the seller's identity, checks that the property documents are legitimate, and stamps everything with an official seal. Without the notary, neither you nor the bank could trust that the transaction is valid.
A Certificate Authority (CA) plays the same role in the digital world. It is the trusted third party that verifies the identity of an entity (a website, an organization, a device) and issues a digital certificate confirming that identity. The certificate binds a public key to the verified identity, and the CA's digital signature on the certificate is the seal that makes it trustworthy.
Every time your browser establishes an HTTPS connection, it checks whether the server's certificate was issued by a CA it recognizes. If the CA is trusted, the connection proceeds. If not, you see a security warning. This simple mechanism (verify the issuer, trust the certificate) is the foundation of online trust.
Not all Certificate Authorities serve the same purpose or operate at the same level. Understanding the distinctions is important when designing or evaluating a PKI.
Public CAs are trusted by browsers, operating systems, and devices worldwide. Companies like DigiCert, Let's Encrypt, and Sectigo operate public CAs. Their root certificates are pre-installed in trust stores, the curated lists of trusted CAs that ship with every browser and OS. Public CAs are required when you need certificates that external users or the general public will validate, such as TLS certificates for public-facing websites.
Private (or internal) CAs are operated by organizations for their own use. They issue certificates for internal services, employee authentication, device identity, and microservice communication. Because they are not in public trust stores, their certificates are only trusted by systems the organization configures. Private CAs give you full control over certificate policies, validity periods, and issuance rules.
A Root CA sits at the top of the trust hierarchy. Its certificate is self-signed and stored offline in highly secure environments, often in hardware security modules (HSMs) inside locked vaults. Root CAs rarely issue certificates directly. Instead, they sign the certificates of Intermediate CAs, which handle day-to-day issuance. This layered design limits exposure: if an intermediate CA is compromised, only its certificates need to be revoked, not the entire root. This architecture forms the chain of trust.
The issuance process follows a well-defined sequence. Whether you are requesting a certificate from a public CA for your website or from a private CA for an internal API, the steps are fundamentally the same.
The requester generates a public/private key pair. The private key stays secret and never leaves the requester's system. The public key will be included in the certificate.
The requester creates a CSR, a structured message containing the public key, the desired subject name (e.g., www.example.com), and other identifying details. The CSR is digitally signed with the requester's private key, proving they possess the corresponding key.
The CA verifies the requester's identity. For a public TLS certificate, this might involve proving control of the domain via a DNS record or HTTP challenge. For an organization-validated certificate, it means checking legal registration documents. For a private CA, verification might follow internal policies, such as checking an Active Directory record or an approval workflow.
Once the identity is verified, the CA constructs the certificate, embedding the public key, subject information, validity dates, and extensions, and signs it with the CA's own private key. This signature is what clients will verify to establish trust.
The signed certificate is returned to the requester, who installs it on the relevant server, device, or application. From this moment, any client that trusts the issuing CA will accept the certificate as valid.
Trust in the CA system is not blind. It is deliberately engineered through trust stores and certificate chains.
Every browser and operating system ships with a pre-configured list of trusted root CA certificates. Apple, Google, Mozilla, and Microsoft each maintain their own trust store programs with strict requirements CAs must meet, including regular audits, compliance with industry standards, and transparent reporting. If a CA fails to meet these requirements, its root certificate can be removed, instantly making all certificates it issued untrusted.
When your browser receives a certificate, it does not just check if the certificate itself is trusted. It follows the certificate chain, from the end-entity certificate, up through one or more intermediate CAs, all the way to a root CA in the trust store. Each link in the chain is verified by checking the digital signature of the certificate above it. If every signature is valid and the root is trusted, the entire chain is trusted.
Sometimes a new CA needs to gain trust before its own root is added to trust stores. Through cross-certification, an already-trusted CA signs the new CA's certificate, creating an alternative trust path. This technique was used by Let's Encrypt in its early years, when its root was cross-signed by IdenTrust.
Organizations running private CAs distribute their root CA certificates to internal systems through group policies, MDM profiles, or configuration management tools. This creates a private trust store that exists alongside the public one, enabling internal certificates to be validated without involving any public CA.
Because CAs are central to the trust model, a compromised CA is one of the most serious events in cybersecurity. If an attacker gains access to a CA's private key, they can issue fraudulent certificates for any domain, enabling man-in-the-middle attacks that are invisible to end users.
History provides stark examples. In 2011, DigiNotar, a Dutch CA, was breached, and attackers issued fraudulent certificates for Google, Yahoo, and other major domains. The incident led to DigiNotar's root being removed from all major trust stores and the company going bankrupt. Comodo suffered a similar breach the same year. These events underscored the need for robust CA security practices and led to initiatives like Certificate Transparency.
When a certificate needs to be invalidated before its expiration date, whether due to a key compromise, a change in ownership, or a CA breach, the CA revokes it. Revoked certificates are published in Certificate Revocation Lists (CRLs) or checked in real time via the Online Certificate Status Protocol (OCSP). Browsers and clients query these mechanisms to ensure they don't trust a certificate that has been revoked.
Modern CAs protect against compromise through offline root keys stored in HSMs, strict physical security controls, regular WebTrust or ETSI audits, and participation in Certificate Transparency logs. For private CAs, organizations should apply the same principles: keep root CAs offline, use intermediate CAs for issuance, and monitor all certificate activity.
Choosing between a public and a private CA depends on who needs to trust the certificate and how much control you need over issuance policies.
Use a public CA. Visitors need to trust your certificate without any special configuration. Their browsers already include the public CA's root in their trust store.
Use a private CA. You control the trust store of all internal systems, so there is no need to involve a public CA. This also avoids per-certificate costs and gives you full control over policies.
Use a private CA. Client certificates for VPN access, Wi-Fi authentication, or smart card login should be issued by an internal CA whose root is deployed to corporate devices.
Use a private CA. Devices you manufacture or manage authenticate to your infrastructure using certificates you control. A private CA lets you define custom validity periods, key algorithms, and revocation policies suited to your devices.
Use a public CA for software distributed to external customers. Use a private CA for internal scripts and tools where you control the endpoints.
Use a private CA. Service-to-service communication within your infrastructure should use certificates from an internal CA. This is the foundation of zero-trust architectures where every service proves its identity to every other service.
Many organizations use both. Public CAs handle externally-facing certificates, while a private CA, often managed through a platform like Evertrust PKI, handles everything internal. The key is to understand the trust boundaries and choose accordingly.
Run your own private CA: Evertrust PKI lets you deploy a fully featured private Certificate Authority with root and intermediate CA hierarchies, customizable certificate profiles, and policy-based issuance, all through a modern, auditable platform.
Automate issuance at scale: Support for ACME, SCEP, EST, and REST APIs means certificates can be requested and deployed automatically by servers, devices, and CI/CD pipelines, with no manual intervention required.
Enforce governance: Define certificate policies, approval workflows, naming constraints, and key algorithm requirements. Every issuance is logged and auditable, meeting the governance expectations of enterprise PKI deployments.
Unified visibility: Whether your certificates come from public CAs, private CAs, or both, Evertrust provides a single dashboard to monitor, alert, and report on your entire certificate estate.
