What does a certificate authority actually verify?

For common domain-validated certificates, the CA only confirms that the applicant controls the domain (e.g., by responding to a challenge). It does not vouch for the organization's legitimacy. Higher-assurance certificates involve more identity checks, but most web certificates only attest to domain control.

What happens if a certificate authority is compromised?

An attacker could issue fraudulent certificates for any site, enabling impersonation. Defenses include revoking and distrusting the CA, Certificate Transparency logs that surface unauthorized certificates, and short certificate lifetimes that limit the window of misuse.

Public-Key Infrastructure

Public-key infrastructure (PKI) is the system of certificate authorities, digital certificates, and policies that binds public keys to verified identities, letting parties who have never met trust each other's keys.

Definition

A public-key infrastructure is the set of roles, policies, hardware, and software needed to create, distribute, store, validate, and revoke digital certificates that bind public keys to identities.

Scope

This topic covers the components and operation of PKI: X.509 certificates, certificate authorities and chains of trust, certificate issuance and validation, revocation (CRLs, OCSP), and transparency mechanisms. It addresses the trust model underlying the web PKI and its alternatives (web of trust). It excludes the digital-signature algorithms that certificates use and the secure-channel protocols (TLS) that consume certificates, both treated separately.

Core questions

How does a relying party gain confidence that a public key belongs to a particular identity?
How do certificate chains and root authorities establish hierarchical trust?
How are certificates validated, and how is revocation handled when keys are compromised?
What failure modes (CA compromise, mis-issuance) threaten the trust model?
How do mechanisms like Certificate Transparency improve accountability?

Key concepts

X.509 certificate
certificate authority (CA)
chain of trust and root store
certificate signing request
certificate revocation (CRL, OCSP)
Certificate Transparency
web of trust
CA compromise and mis-issuance
certificate pinning

Key theories

Hierarchical chain of trust: Trust is rooted in a small set of self-signed root certificate authorities pre-installed in clients; these sign intermediate CAs, which sign end-entity certificates, so a client can verify any certificate by validating the chain up to a trusted root.
Revocation and transparency: Because keys can be compromised or certificates mis-issued, PKI provides revocation (certificate revocation lists and OCSP) and, increasingly, public audit logs (Certificate Transparency) so that mis-issued certificates can be detected and distrusted.

Mechanisms

An applicant generates a key pair and submits a certificate signing request; the CA verifies the applicant's identity or domain control and issues an X.509 certificate binding the public key to that identity, signed with the CA's private key. A relying party validates a certificate by checking the signature chain to a trusted root, the validity period, the name, and revocation status (via CRL or OCSP). Certificate Transparency logs all issued certificates publicly so domain owners can detect unauthorized issuance.

Clinical relevance

The web PKI is what makes the padlock in browsers meaningful: every HTTPS connection relies on a CA-issued certificate to authenticate the server. Automated, free issuance (Let's Encrypt) drove near-universal HTTPS adoption. PKI also underpins code signing, secure email, document signing, and enterprise device identity. CA failures (the 2011 DigiNotar breach) have global impact, which is why transparency and revocation matter.

Evidence & guidelines

X.509 certificates and revocation are profiled in RFC 5280; Certificate Transparency in RFC 6962; OCSP in RFC 6960. The CA/Browser Forum Baseline Requirements govern publicly trusted CAs. The ACME protocol (RFC 8555) automates issuance. Best practice favors short-lived certificates, automated renewal, and reliance on Certificate Transparency monitoring.

History

The certificate concept was proposed in Loren Kohnfelder's 1978 MIT thesis. X.509 emerged from the X.500 directory effort in the late 1980s and became the basis of the web PKI as SSL/TLS spread in the 1990s. Repeated CA compromises and mis-issuance (Comodo and DigiNotar in 2011) exposed the fragility of unconditional CA trust, prompting Certificate Transparency and stricter CA governance, while Let's Encrypt (2015) democratized certificate issuance.

Key figures

Loren Kohnfelder
Whitfield Diffie
Ross Anderson
Ben Laurie

Seminal works

stallings2017
rfc5280
anderson2020

Frequently asked questions

What does a certificate authority actually verify?: For common domain-validated certificates, the CA only confirms that the applicant controls the domain (e.g., by responding to a challenge). It does not vouch for the organization's legitimacy. Higher-assurance certificates involve more identity checks, but most web certificates only attest to domain control.
What happens if a certificate authority is compromised?: An attacker could issue fraudulent certificates for any site, enabling impersonation. Defenses include revoking and distrusting the CA, Certificate Transparency logs that surface unauthorized certificates, and short certificate lifetimes that limit the window of misuse.