SSL/TLS: Certificates, CA & PKI

X.509 Certificate Structure

A certificate contains:
  Subject:          CN=example.com, O=Example Inc, C=US
  Subject Alt Names (SAN): DNS:example.com, DNS:www.example.com, IP:93.184.216.34
  Issuer:           CN=Let's Encrypt R3, O=Let's Encrypt, C=US
  Serial Number:    unique per CA
  Valid From/To:    2024-01-01 to 2024-04-01 (Let's Encrypt: 90 days)
  Public Key:       RSA 2048 or ECDSA P-256
  Signature:        CA signs hash of certificate with its private key
  Key Usage:        Digital Signature, Key Encipherment
  Extended Key Usage: TLS Web Server Authentication

Common Name (CN) is legacy — modern validation uses SAN.
Wildcard: *.example.com — covers one subdomain level (not sub.sub.example.com).

Certificate Types

• DV (Domain Validation): CA verifies you control the domain (DNS or HTTP challenge). Automated, free (Let's Encrypt). Shows padlock in browser.

• OV (Organization Validation): CA verifies organization identity via document check. Company name in cert details.

• EV (Extended Validation): rigorous legal verification. Green bar in old browsers (modern browsers removed the distinction).

• Wildcard: *.example.com — covers all subdomains at one level. Useful but limits automation.

• Multi-SAN: one cert covers multiple domains (example.com, api.example.com, shop.example.com). Let's Encrypt supports up to 100 SANs.

• Self-signed: signed by own private key (no CA). Fine for internal/dev; browsers show security warning.

Trust Chain

Browser validates certificate chain:

  Root CA certificate     ← pre-installed in OS/browser trust store
      ↓ signs
  Intermediate CA cert    ← server must serve this in the chain
      ↓ signs
  Leaf (server) cert      ← presented for your domain

Why intermediates?
  Root CA private keys are kept offline in HSMs (air-gapped vaults).
  Intermediates do day-to-day signing. If an intermediate is compromised,
  root CA revokes it without replacing every root trust store.

Certificate chain validation:
  1. Browser downloads leaf cert from server
  2. Checks signature using issuer's public key
  3. Walks up to root — each cert signed by parent
  4. Finds root in its trust store
  5. Checks: not expired, not revoked (OCSP/CRL), SAN matches hostname

Missing intermediate = handshake failure on some clients (mobile Safari notorious for this).
Use: https://whatsmychaincert.com to check your chain.

Certificate Revocation

• CRL (Certificate Revocation List): CA publishes list of revoked serial numbers. Clients download periodically. Stale and large.

• OCSP (Online Certificate Status Protocol): real-time query to CA for revocation status. Adds latency; CA sees every connection.

• OCSP Stapling: server fetches OCSP response and includes it in TLS handshake. Client doesn't need to contact CA. Better privacy and performance.

• OCSP Must-Staple: cert extension requiring stapled OCSP. Browser rejects cert if staple missing. Strongest revocation.

• Soft fail: browsers ignore revocation check failures silently (performance/privacy tradeoff). Hard fail is impractical at scale.

• Certificate Transparency (CT): all certificates logged to public append-only logs. Browsers require SCT (Signed Certificate Timestamp) proof. Catches mis-issuance.