Certificate Authorities

A Certificate Authority is the trusted third party whose signature turns an anonymous public key into a certificate a browser will accept. The whole system rests on a small set of root keys held by organizations you have never met, and understanding how that trust flows, and how it fails, is essential to reasoning about the security of every HTTPS connection. This page walks a real chain, builds a lab CA, and confronts the uncomfortable state of revocation.

Why This Matters

CAs are the trust anchors of the web. A compromised or misbehaving CA can issue a certificate for any domain, which is exactly what happened with DigiNotar in 2011: attackers issued fraudulent Google certificates and intercepted traffic for hundreds of thousands of Iranian users. DigiNotar was removed from every root store and went bankrupt. Knowing how the chain is built and validated is how you reason about that blast radius.

Root, Intermediate, and Leaf

Verification walks a chain from the leaf certificate a server presents, up through one or more intermediate CAs, to a root that your trust store already trusts. Each certificate is signed by the one above it; the root signs itself.

Certificate	Signed by	Trusted because
Leaf	Intermediate	Its signature chains to a trusted root
Intermediate	Root	Its signature chains to a trusted root
Root	Itself	It is present in the OS/browser root store

Roots are kept offline precisely because their compromise is catastrophic. Intermediates do the day-to-day signing, so a compromised intermediate can be revoked without redistributing a new root to billions of devices.

Walking a Real Chain

Ask a server for its full chain and inspect each link.

cd ~/crypto-lab
openssl s_client -connect github.com:443 -servername github.com -showcerts </dev/null 2>/dev/null \
  | grep -E "s:|i:"

Expected output:

 0 s:CN=github.com
   i:C=US, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
 1 s:C=US, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
   i:C=GB, O=Sectigo Limited, CN=Sectigo ECC Certification Authority

Each s: (subject) is signed by the next i: (issuer). The chain stops when the issuer is a root already in your trust store.

Building Your Own Mini-CA

For internal services you run your own CA. step-cli makes this a two-command lab.

cd ~/crypto-lab
step ca init --name "Lab CA" --dns localhost --address 127.0.0.1:9000 \
  --provisioner admin@lab.local --deployment-type standalone
step certificate create svc.lab.local svc.crt svc.key \
  --profile leaf --ca ~/.step/certs/intermediate_ca.crt \
  --ca-key ~/.step/secrets/intermediate_ca_key --no-password --insecure
step certificate verify svc.crt --roots ~/.step/certs/root_ca.crt

Expected output:

✔ Would you like to change the default configuration? No
✔ Root certificate: /root/.step/certs/root_ca.crt
✔ CA config: /root/.step/config/ca.json
Your PKI is ready to go.

The plain openssl route is openssl req -x509 to make a CA key, then openssl x509 -req -CA ca.crt -CAkey ca.key to sign leaf CSRs; step just automates the plumbing. This lab CA is what the sibling Mutual TLS page uses to issue both server and client certificates.

Certificate Transparency

Because a rogue CA can mis-issue silently, every publicly trusted certificate must now be logged to append-only Certificate Transparency (CT) logs, and browsers reject certificates lacking CT proof. Domain owners can monitor these logs to detect unauthorized issuance for their names. This shifts the model from “prevent mis-issuance” to “make it publicly detectable.”

Revocation’s Sad State

When a private key leaks, the certificate should be revoked, but revocation has always been the weak link.

Mechanism	How it works	Problem
CRL	CA publishes a list of revoked serials	Lists grow huge; clients rarely fetch them
OCSP	Client asks CA if a cert is still valid	Privacy leak; soft-fail means attackers just block it
OCSP stapling	Server attaches a fresh OCSP response	Better, but not universally deployed
Short lifetimes	90-day certs expire before revocation matters	The pragmatic winner today

The industry answer has been to shorten certificate lifetimes so a revoked certificate simply expires soon anyway. See the sibling X.509 Certificates page for the fields involved and TLS Handshake for where chain validation happens.

Practical Guidance

1. Keep your root CA key offline; only intermediates should ever touch a network-connected signing service.
2. Always serve the full chain minus the root; clients supply the root from their own store, and shipping it wastes bytes.
3. Monitor Certificate Transparency logs for your domains so you learn about mis-issuance before an attacker uses it.
4. Do not rely on OCSP or CRLs for security; prefer short-lived certificates with automated renewal.
5. For internal PKI, run a real CA tool such as step ca rather than hand-rolling openssl scripts, so issuance, renewal, and revocation are consistent.