What is a Certificate Authority? How PKI Trust Works
A Certificate Authority (CA) is a trusted organisation responsible for issuing and signing digital certificates. When your browser shows a padlock icon, it is because a CA has verified the identity of the server you are connecting to. Understanding how CAs work is essential for anyone managing websites, APIs, or internal services.
What Does a Certificate Authority Actually Do?
A CA performs three core functions: it verifies the identity of certificate applicants, it digitally signs certificates with its private key, and it maintains Certificate Revocation Lists (CRLs) to invalidate compromised certificates. When a CA signs your certificate, it is effectively vouching for your identity to every browser and device that trusts that CA.
The trust flows from the CA's root certificate, which is pre-installed in operating systems and browsers. As of 2026, there are roughly 150 root CAs trusted by major browsers — each one responsible for millions of downstream certificates.
The PKI Trust Chain Explained
Public Key Infrastructure (PKI) is the system of roles, policies, and procedures that governs how certificates are created, managed, and revoked. The trust chain — also called the certificate chain — works as follows:
- Root CA: The highest level of trust. Root certificates are self-signed and embedded in OS/browser trust stores. Examples: DigiCert Root G5, ISRG Root X1 (Let's Encrypt).
- Intermediate CA: Signed by the root CA. Used to issue end-entity certificates. This protects root CAs from direct exposure — if an intermediate is compromised, only it is revoked, not the root.
- End-Entity Certificate: The certificate on your server. Signed by an intermediate CA. Contains your domain name, public key, expiry date, and subject details.
When a browser connects to your site, it walks this chain from your certificate up to a trusted root. If any link in the chain is broken — a missing intermediate, an expired certificate, or a revoked issuer — the connection fails with a trust error.
Types of Certificate Authorities
Trusted globally by browsers and OS. Examples: DigiCert, Sectigo, GlobalSign, Let's Encrypt. Certificates from these CAs work for public-facing websites.
Used within organisations for internal services. Not trusted by default externally. Common in enterprise networks using tools like Microsoft AD CS or HashiCorp Vault.
Let's Encrypt is the most popular free CA, issuing short-lived (90-day) certificates. Ideal for most websites but requires automation for renewal.
Some governments operate their own CAs for official websites. Not always universally trusted — usage is typically mandated by national policy.
How CA Validation Levels Work
Not all CAs verify identity the same way. There are three validation levels, each with different levels of identity assurance:
| Level | Verification | Best For | Issuance Time |
|---|---|---|---|
| DV (Domain Validated) | Domain ownership only | Blogs, apps, APIs | Minutes |
| OV (Organisation Validated) | Domain + company identity | Business websites | 1–3 days |
| EV (Extended Validation) | Full legal entity verification | Finance, healthcare | 1–2 weeks |
What Happens When a CA Is Compromised?
CA compromise is rare but devastating. In 2011, Dutch CA DigiNotar was breached — attackers issued fraudulent certificates for Google, Yahoo, and others. The CA was subsequently removed from all major browser trust stores, rendering every website with a DigiNotar certificate unreachable.
To protect against this, modern browsers use Certificate Transparency (CT) logs — public, append-only records of every certificate issued. Any certificate not in CT logs will be rejected by Chrome and Safari. This makes it much harder for a rogue CA to issue certificates undetected.
Choosing the Right CA for Your Use Case
Use Let's Encrypt — free, automated, and universally trusted. Pair it with Certbot or ACME clients for zero-maintenance renewal.
Let's Encrypt or DigiCert DV. Automate renewal with ACME. If you need OV for customer trust, use Sectigo or GlobalSign.
Consider EV certificates and OV certificates from DigiCert or Entrust. These provide higher assurance visible in certificate details (though browsers no longer show the green bar).
Deploy a private CA using HashiCorp Vault, AWS ACM Private CA, or cert-manager on Kubernetes. This gives you full control over certificate lifecycle.
Key Takeaways
Use our free Certificate Chain Checker to inspect any domain's certificate chain — seeing exactly which CA issued the certificate and verifying the full chain to the trusted root.
Common questions
What is a Certificate Authority (CA) and how does it work?
A Certificate Authority is a trusted organization that issues digital certificates after verifying the applicant's domain ownership or organizational identity. Browsers and operating systems maintain a trusted root store containing pre-approved CA public keys. The CA signs your certificate with its private key — browsers verify this signature to establish the chain of trust.
What is the difference between a root CA and an intermediate CA?
Root CAs are the ultimate trust anchors — their public keys are hardcoded into browsers and operating systems. They are kept offline for security and sign intermediate CA certificates. Intermediate CAs are used for day-to-day certificate issuance. If an intermediate is compromised, it can be revoked without affecting the offline root CA.
How many Certificate Authorities does a browser trust?
Major browsers trust roughly 150 root CA certificates operated by 50-60 organizations, which control many more intermediate CAs. These include DigiCert, Sectigo, Let's Encrypt (ISRG), GlobalSign, and others. Google, Apple, Mozilla, and Microsoft each maintain their own trust store — a CA can be trusted in one and not another.
What happens if a Certificate Authority is compromised or distrusted?
Browser vendors can remove a CA from their trusted root store, causing all its certificates to be rejected. Major distrust events include Symantec (2018, affecting millions of sites) and WoSign (2016). When a CA is distrusted, all websites using its certificates must reissue from a different CA. Monitoring your CA's trust status is part of certificate management.
References and further reading
The specifications and primary documentation this article is based on.
- CA/Browser Forum
Publishes the Baseline Requirements every public CA must follow.
- RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- RFC 6962 — Certificate Transparency
Read next
More guides on the same subject.