Gyaan

Certificates & PKI

intermediate certificates pki x509 ca tls https

A TLS certificate is a small file that proves “this public key really belongs to bank.com.” PKI (Public Key Infrastructure) is the whole system of trust that backs that proof up.

In simple language: when our browser connects to a site over HTTPS, the site shows a certificate like an ID card. The browser checks if the ID was signed by someone it trusts (a Certificate Authority).

X.509 — The Cert Format

Almost every TLS certificate in the world uses the X.509 standard. Inside a cert we find:

  • Subject — who the cert is for (CN=bank.com)
  • Issuer — who signed it (a CA like Let’s Encrypt)
  • Public key — the site’s public key
  • SANs (Subject Alternative Names) — extra domains the cert covers (*.bank.com, www.bank.com)
  • Validity period — Not Before / Not After dates
  • Signature — the CA’s signature over all of the above
  • Serial number, fingerprint — unique identifiers
# Inspect a certificate from a live server
openssl s_client -connect bank.com:443 -servername bank.com < /dev/null \
  | openssl x509 -text -noout

# Check just the dates and SANs
openssl x509 -in cert.pem -text -noout | grep -E "DNS:|Not"

CN vs SAN

The old way was to put one domain in the Common Name (CN). Modern browsers (Chrome since 2017) ignore CN and only look at the SAN field. So a cert without SAN entries is rejected, even if CN matches.

Always use SANs. CN is mostly cosmetic now.

The Chain of Trust

Browsers don’t trust every CA in the world directly. Instead they trust a small set of root CAs baked into the OS / browser trust store. Real certs are issued by intermediate CAs, which are signed by roots.

Root CA (in browser trust store)
   |
   v signs
Intermediate CA
   |
   v signs
bank.com leaf certificate

When the server sends its cert during the TLS handshake, it sends the leaf + intermediate chain. The browser climbs the chain until it hits a root it already trusts. If every signature checks out, the cert is valid.

Root CAs

Roots live in the OS or browser trust store. On macOS:

# List trusted root CAs
security find-certificate -a /System/Library/Keychains/SystemRootCertificates.keychain

If a root is compromised or misbehaves (Symantec, DigiNotar), browsers can revoke trust by removing it from the store.

Self-Signed vs CA-Signed

  • Self-signed: we generate our own cert and sign it ourselves. Browsers show a big scary warning because no public CA vouches for it. Fine for local dev (localhost), not for production.
  • CA-signed: signed by a public CA. Browsers trust it silently.
# Generate a self-signed cert for local dev
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
  -sha256 -days 365 -nodes -subj "/CN=localhost"

Let’s Encrypt

Let’s Encrypt is a free, automated, public CA. It uses the ACME protocol — a script proves we control the domain (HTTP-01 or DNS-01 challenge), and a cert is issued in seconds. Certs are valid for 90 days, so we set up auto-renewal.

# Get a cert with certbot
sudo certbot --nginx -d example.com -d www.example.com

This single tool is why HTTPS went from “expensive” to “default” in the late 2010s.

Revocation — OCSP and CRL

What if a private key leaks? The cert needs to be revoked before it expires.

  • CRL (Certificate Revocation List): a big list of revoked serial numbers. Browser downloads it and checks. Old, bandwidth-heavy.
  • OCSP (Online Certificate Status Protocol): browser asks the CA “is this cert still valid?” in real time. Faster, but adds a round trip and leaks browsing history to the CA.
  • OCSP Stapling: the server periodically fetches the OCSP response and staples it to the TLS handshake. Browser doesn’t need to call the CA. Best of both worlds.

In practice, modern browsers also use CRLite / CRLSets — pre-built lists pushed via browser updates.

Common Gotcha

Certs expire. A lot of outages come from “we forgot to renew the cert.” Always automate renewal (certbot, cert-manager on Kubernetes, ACM on AWS) and set up monitoring/alerts on Not After dates.

Interview Tip

When asked “how does HTTPS know it’s the real site?” — walk through: cert → signed by intermediate → signed by root → root is in browser trust store. That’s the chain of trust. Bonus points for mentioning SAN, OCSP stapling, and Let’s Encrypt.

References