The Job of a CA
A Certificate Authority verifies that a requester is entitled to receive a certificate for a name, then cryptographically signs a certificate binding that name to a public key. When your browser visits a site, it checks whether the certificate matches the hostname, whether the signature chain is valid, and whether the chain terminates at a root already present in the trust store. If all checks pass, the padlock appears and the TLS handshake proceeds to establish an encrypted session.
Root CAs vs Intermediate CAs
| Certificate Type | Role | Why It Exists |
|---|---|---|
| Root CA | Trust anchor in browser or OS trust store | Starts the chain; its public key is pre-distributed |
| Intermediate CA | Signs site certificates on behalf of the root | Isolates root key from day-to-day issuance |
| Leaf / end-entity certificate | Presented by the website during TLS handshake | Binds the site hostname to its public key |
Root CA private keys are among the most sensitive secrets in public-key infrastructure. They are typically stored in Hardware Security Modules (HSMs) in physically secured facilities, often kept offline and used only to sign new intermediate certificates. Intermediates do the actual work of signing leaf certificates daily. If an intermediate is compromised, it can be revoked and replaced without requiring every browser and OS in the world to update their trust store — which is what would be necessary if the root itself were compromised.
Chain of Trust Verification
During a TLS handshake, the server sends its leaf certificate and typically its intermediate certificate(s). The client walks the chain: it verifies that the leaf is signed by the intermediate, then that the intermediate is signed by the root (or another intermediate), until it reaches a root it already trusts. Each signature is verified using the public key in the issuing certificate. The client also checks that each certificate in the chain has the correct Key Usage and Extended Key Usage flags — a certificate issued for email signing must not be accepted for TLS server authentication. Cross-signed intermediates, where a newer root signs the same intermediate key that an older root also signed, allow backward compatibility with older clients that trust only the older root.
How Browsers and OSes Ship Root Stores
There is no single global root store. Each major platform ships its own curated list. Mozilla maintains the Mozilla Root Store used by Firefox on all platforms. Apple ships roots in macOS and iOS. Microsoft ships the Windows root store. Google maintains its own root store used by Chrome on most platforms, though Chrome also uses the OS store on some platforms. Each program has its own criteria, audit requirements, and removal processes for CAs. A CA that is trusted by one root store may not be trusted by another, and a CA can be removed from one store without being removed from others. Let's Encrypt, for example, gained wide trust by cross-signing under IdenTrust's root while its own roots were being added to stores.
DV, OV, and EV Certificates
| Type | Validation Level | What the CA Verifies | Browser Indicator |
|---|---|---|---|
| DV (Domain Validation) | Domain control only | Applicant controls the DNS name | Padlock, no org name |
| OV (Organization Validation) | Domain + organization | Legal existence of the organization | Padlock; org in cert details |
| EV (Extended Validation) | Rigorous org vetting | Legal identity, jurisdiction, address | Padlock; org name formerly in address bar |
Most certificates today are DV, issued automatically in seconds by services like Let's Encrypt. The CA proves domain control by having the applicant place a token in DNS or serve a file over HTTP. OV and EV certificates require human review of business documents. Major browsers removed the green address bar for EV certificates in 2019 after research showed users did not reliably notice or interpret it, and EV now provides minimal additional visible trust signal to end users.
Certificate Transparency Logs
Certificate Transparency (CT), defined in RFC 6962, requires CAs to submit every issued certificate to publicly auditable logs before browsers will trust it. When a CA issues a certificate, it submits it to one or more CT logs and receives a Signed Certificate Timestamp (SCT) in return. The server must present SCTs during the TLS handshake, either embedded in the certificate, delivered via a TLS extension, or stapled in OCSP. Browsers check for SCTs and reject certificates that lack them. CT logs allow domain owners, security researchers, and automated monitors to detect certificates issued for their domains without authorization. Services like crt.sh provide a searchable interface over CT log data, making it easy to see every certificate ever issued for a domain.
OCSP and CRL Revocation
When a certificate's private key is compromised or the certificate is mis-issued, it must be revoked before its expiry. Two mechanisms exist. Certificate Revocation Lists (CRLs) are periodically published files listing revoked certificate serial numbers; clients download and cache them. Online Certificate Status Protocol (OCSP) lets clients query the CA in real time for the status of a specific certificate. OCSP stapling improves on basic OCSP: the server fetches its own OCSP response, caches it, and staples it to the TLS handshake, so clients receive fresh revocation status without making a separate network request to the CA. Revocation checking has historically been unreliable because browsers soft-fail (treat the certificate as valid) when OCSP servers are unreachable, to avoid breaking sites when the CA's OCSP infrastructure has problems.
CAA DNS Records
Certification Authority Authorization (CAA) DNS records, defined in RFC 8659, allow domain owners to specify which CAs are permitted to issue certificates for their domain. A CAA record looks like example.com. CAA 0 issue "letsencrypt.org". Before issuing a certificate, a CA must check for CAA records and refuse to issue if its own name is not listed. CAA records do not prevent a CA from technically being able to issue — they create a policy that compliant CAs must follow, and CT logs make violations detectable. Wildcards can also be controlled separately using the issuewild tag. CAA is a lightweight defense against mis-issuance and is straightforward to configure in any DNS hosting provider.
When a CA Is Distrusted: DigiNotar and Symantec
The consequences of CA distrust are severe. DigiNotar, a Dutch CA, was compromised in 2011 and issued fraudulent certificates for Google, the CIA, and others. Mozilla, Google, and Microsoft removed DigiNotar from their trust stores within days of the discovery. The company subsequently went bankrupt. Symantec faced a different path: after years of documented mis-issuance and failure to meet audit requirements, Google announced a gradual distrust plan in 2017. Symantec-issued certificates were distrusted in Chrome based on their issuance date, giving website operators time to replace certificates. Apple and Mozilla followed. Symantec sold its CA business to DigiCert as part of the response. These cases established that even large, established CAs are not immune to removal from trust stores when they fail to meet community standards, and that removal is the primary enforcement mechanism available to browser vendors.
Frequently Asked Questions
What is a Certificate Authority?
A Certificate Authority is an organization or system trusted to issue digital certificates that bind names, such as domain names, to public keys.
What is a certificate chain?
A certificate chain links a site certificate through one or more intermediate certificates back to a trusted root certificate in the browser or operating system trust store.
Can a CA see my HTTPS traffic?
A public CA does not automatically see your HTTPS traffic. It helps establish trust in the server certificate; the encrypted session is negotiated between your browser and the server.