Certificate authority (CA)
Also known as: certification authority
A trusted body that checks who someone is and then signs digital certificates vouching that a public key belongs to them.
Draft - this entry has not been reviewed yet.
Formal
The issuing party in a public key infrastructure. It signs each certificate with its own private key, keeps public lists of certificates it has cancelled before they expire, and is trusted because its root certificate is already stored in browsers and operating systems.
In plain English
Like the passport office - it checks your papers before issuing a passport, and border guards accept the passport because they trust the office, not because they know you.
In practice
A regional hospital needs a new certificate for its patient portal. The CA checks that the region really controls the web address and signs the certificate, and patients' browsers then open the site without a warning.
Why it matters
The whole chain of trust rests on a small number of issuers; if one is broken into or careless, attackers can get real-looking certificates for sites that are not theirs.
Technical deep dive
Technically a CA is a key pair plus the policy and operations around it. A root CA has a self-signed certificate distributed out of band in trust stores (Mozilla NSS, Apple, Microsoft, the Chrome Root Store); the root key is normally kept offline in an HSM and used only to sign a few intermediate CA certificates carrying basicConstraints cA=TRUE, an optional pathLenConstraint and keyCertSign/cRLSign key usage (RFC 5280 §4.2.1.9, §4.2.1.3). Issuance happens from the intermediates, so a compromised issuing CA can be revoked without replacing the root on billions of devices.
Publicly trusted CAs follow the CA/Browser Forum Baseline Requirements, enforced by browser root programs and checked by annual WebTrust or ETSI EN 319 411 audits. Domain control must be validated with a method from BR §3.2.2.4 (an HTTP token under /.well-known/, a DNS TXT record, the ACME challenges of RFC 8555), CAA records (RFC 8659) must be checked, and since 15 March 2025 validation and CAA results must be corroborated from multiple network perspectives to resist BGP and DNS hijacking. Maximum TLS certificate validity fell from 398 to 200 days on 15 March 2026 and is scheduled to drop to 100 days in March 2027 and 47 days in March 2029 (ballot SC-081), which makes automated renewal effectively mandatory.
A CA also publishes status information: CRLs (RFC 5280 §5) are signed lists of revoked serial numbers, OCSP (RFC 6960) answers per certificate. The Baseline Requirements made OCSP optional in 2024 while keeping CRLs mandatory, and Let's Encrypt among others has since shut its OCSP service down. Browser revocation checking is mostly soft-fail or based on vendor-pushed lists, so short lifetimes increasingly do the real work of revocation.
The central failure mode is misissuance. DigiNotar was breached in 2011, issued a fraudulent *.google.com certificate used against Iranian users, was removed from every trust store and went bankrupt; Symantec's roots were distrusted in 2018 after repeated violations, and Chrome stopped trusting newly issued Entrust TLS certificates from November 2024. Certificate Transparency (RFC 6962) requires publicly trusted certificates to be logged in append-only logs, so domain owners can detect misissuance. A CA differs from a registration authority, which only vets applicants, and from the PKI as a whole. Private enterprise CAs such as Active Directory Certificate Services are trusted only on managed devices, and misconfigured certificate templates there are a well-known privilege-escalation path.
What to learn first
Everything this builds on, foundations first.
- Cryptographic key
- →Hashing
- →Digital identity
- →Public-key cryptography
- →Digital signature
- →Digital certificate
- →Certificate authority (CA)
Relationships
- Used with
- TLS
Sources & further reading
Standards & official texts
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…