A Certificate Authority (CA) is an organization that verifies control of a name or identity and then digitally signs an X.509 certificate that binds that identity to a public key. In Internet trust, CAs are the anchors of the Web PKI: a browser accepts a TLS connection to a website only if the server’s certificate leads back, through a certificate chain, to a root CA that the browser already trusts.
The CA does not encrypt traffic or host websites. Its single product is a signed statement about a key, and the value of that statement depends entirely on how carefully the CA validates requests, protects its own private keys and responds when something goes wrong.
How a Certificate Authority issues a certificate
Issuance follows a fixed sequence of request, validation, signing and logging. The applicant generates a key pair, keeps the private key and sends the public key to the CA in a certificate signing request (CSR) that also names the domains to be covered.
The CA then performs domain control validation. In the automated ACME protocol, the applicant proves control by placing a token at a specific HTTP path, publishing it in a DNS TXT record or answering a special TLS handshake. Before issuing, the CA must also check the domain’s CAA record, which can restrict which CAs are allowed to issue for that name.
After validation, the CA signs the certificate with an intermediate CA key and submits it to public Certificate Transparency logs. Major browsers reject publicly trusted TLS certificates that lack proof of logging, which means every issued certificate becomes visible to domain owners and researchers.
The following table summarizes the main domain validation methods used today.
| Method | What the applicant proves | Best suited for | Limitation |
|---|---|---|---|
| HTTP-01 | A token is served at a well-known path on port 80 | Single web servers with public HTTP access | Cannot issue wildcard certificates |
| DNS-01 | A token is published in a DNS TXT record | Wildcards and servers not reachable from the Internet | Requires API access to the DNS zone |
| TLS-ALPN-01 | A special certificate is presented on port 443 | Setups where only port 443 is open | Limited support in some server software |
| Email to domain contact | A link sent to an approved address is followed | Manual issuance by commercial CAs | Slow and exposed to mailbox compromise |
Root, intermediate and issuing CAs
A CA operates as a hierarchy of keys rather than a single key, so that the most valuable key is used as rarely as possible. The root key stays offline in a hardware security module and signs only intermediate certificates during formal key ceremonies.
Intermediate CAs sign end-entity certificates in daily operation. If an intermediate key is compromised, the root can revoke it and sign a new one, while the root certificate already distributed in billions of devices stays valid.
| Level | Signed by | Typical validity | Where the key lives |
|---|---|---|---|
| Root CA | Itself (self-signed) | About 15 to 25 years | Offline hardware security module |
| Intermediate CA | Root CA | Several years | Online hardware security module with strict access |
| End-entity certificate | Intermediate CA | At most 200 days for public TLS since March 2026 | The server operated by the subscriber |
Root certificates become trusted only after admission to a root store, such as those maintained by browser and operating system vendors. Admission requires annual audits under WebTrust or ETSI criteria and compliance with the CA/Browser Forum Baseline Requirements, which define validation rules, key sizes and maximum certificate lifetimes.
Validation levels and certificate types
Certificate Authorities sell or issue certificates at three validation levels, which differ in what the CA checks, not in the strength of encryption. A domain-validated certificate and an extended-validation certificate protect traffic equally well.
| Level | What the CA verifies | Issuance time | Practical value |
|---|---|---|---|
| Domain validation (DV) | Control of the domain only | Seconds to minutes, fully automated | Standard choice for almost all websites |
| Organization validation (OV) | Domain control plus the legal existence of the organization | Days | Organization name appears in certificate details |
| Extended validation (EV) | Stricter checks of legal, physical and operational existence | Days to weeks | Little visible benefit since browsers removed the special address bar indicator |
Besides public TLS certificates, CAs issue code-signing, S/MIME email and client authentication certificates. Many organizations also run a private CA for internal services and devices; its root is trusted only on machines where the organization installs it, and it falls outside public root store rules.
Revocation, lifetimes and automation
A certificate can be withdrawn before it expires through revocation, published either in certificate revocation lists or through OCSP responses. In practice, browsers handle revocation checks inconsistently, and several large CAs have moved back to CRLs, so short certificate lifetimes have become the main defense against misused certificates.
The CA/Browser Forum has therefore scheduled a stepwise reduction of maximum TLS certificate validity: from 398 days to 200 days in March 2026, 100 days in March 2027 and 47 days in March 2029. At these lifetimes, manual renewal is no longer realistic, and automated issuance through ACME becomes a requirement rather than a convenience.
Failure modes and the limits of CA trust
The Web PKI has a structural weakness: any trusted CA can issue a certificate for any domain, so the system is only as strong as its least careful member. Several controls now limit this risk, but none removes it completely.
- CA compromise: the 2011 breach of DigiNotar led to fraudulent certificates for major domains and to the CA’s complete removal from root stores.
- Misissuance: weak validation or software bugs produce certificates for the wrong party; Certificate Transparency makes such errors detectable.
- Distrust by browsers: root programs can and do remove CAs with repeated compliance failures, which invalidates their customers’ certificates for browser users.
- Subscriber key theft: a stolen server private key lets an attacker impersonate the site until the certificate expires or is revoked, regardless of how good the CA is.
Domain owners can reduce exposure by publishing CAA records that name the CAs they use and by monitoring Certificate Transparency logs for unexpected certificates issued for their domains.
A non-technical view
A Certificate Authority works like a passport office for websites. Before it issues a certificate, it checks that the applicant really controls the website name. Your browser carries a short list of passport offices it trusts, and when a site shows its certificate, the browser checks that one of those offices signed it.
If the signature checks out, the padlock appears and the connection is encrypted with the site’s genuine key. If not, the browser warns you. The whole system works only because these offices are trusted and closely audited.
A concrete example
A regional hospital runs a patient portal and about 40 internal web services. Its public portal certificate used to be renewed by hand once a year, and twice the renewal was forgotten, which locked patients out with browser warnings for several hours.
The IT team moves the portal to automated ACME issuance with DNS-01 validation, adds a CAA record that allows only its chosen public CA and sets up Certificate Transparency monitoring for its domains. Renewal now runs every 60 days without human involvement, which keeps it well inside the 200-day limit. For the internal services, the hospital builds a private CA with an offline root and distributes the root certificate to managed devices.
Six months later, monitoring flags a newly logged certificate for a lookalike domain registered by a third party, and the team reports it as a phishing site within a day. Since the switch, there has not been a single expiry outage. Automation and monitoring turned certificate management into a routine process.