Certificates and PKI

The security foundation of TLS: X.509 certificate chains, ACME automated issuance, OCSP/CRL revocation checks, and Certificate Transparency public auditing. PKI is not perfect (any CA can issue certificates for any domain); CT and key pinning are patches to this trust model.

Overview

The trust foundation of TLS is X.509 certificates and PKI (Public Key Infrastructure). Browsers and operating systems have approximately 150 Root CA certificates pre-installed—these CAs can issue certificates for any domain, creating a single point of failure for the entire HTTPS trust system. Let's Encrypt (2016) automated certificate issuance and made it completely free via the ACME protocol, boosting HTTPS deployment rates from 40% to over 90%. Certificate Transparency (2013) mandates that all certificates be recorded in public logs, making malicious issuance detectable. OCSP Stapling enables revocation checks while protecting privacy.

X.509 Certificates

Certificate:
  tbsCertificate (to-be-signed):
    Version: v3 (2)
    Serial Number: Random (CA anti-replay)
    Signature Algorithm: sha256WithRSAEncryption or ecdsa-with-SHA256
    Issuer: C=US, O=Let's Encrypt, CN=R3  ← Who signed it
    Validity:
      Not Before: 2024-01-01T00:00:00Z
      Not After:  2024-03-31T23:59:59Z (max 90 days for LE)
    Subject: CN=grafana.liz6.com  ← Who the certificate belongs to
    Subject Public Key Info:
      Algorithm: id-ecPublicKey (or rsaEncryption)
      Public Key: (256-bit EC point or 2048-bit RSA modulus)
    Extensions:
      SAN (Subject Alternative Name): grafana.liz6.com, *.liz6.com ← Critical!
      Basic Constraints: CA=FALSE ← Not a CA (cannot issue sub-certificates)
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      CRL Distribution Points: http://r3.i.lencr.org/
      Authority Information Access:
        OCSP: http://r3.o.lencr.org/
        CA Issuers: http://r3.i.lencr.org/
      Certificate Policies
      CT Precertificate SCTs (Signed Certificate Timestamps)
  Signature Algorithm
  Signature Value

Importance of SAN

Browsers have completely ignored the CN (Common Name). All domain validation is based on the SAN. If the certificate does not include the accessed domain → browser error: ERR_CERT_COMMON_NAME_INVALID:

SAN: DNS:grafana.liz6.com, DNS:*.liz6.com
→ Matches grafana.liz6.com ✓, chat.liz6.com ✓, grafana.liz6.com:8443 ✗ (SAN does not include port)
→ Wildcard: *.liz6.com matches single-level subdomains (chat.liz6.com) but not multi-level ones (sub.chat.liz6.com)

Chain of Trust

Root CA (ISRG Root X1):
  Subject = Issuer = Self (self-signed)
  Basic Constraints: CA=TRUE
  → Pre-installed in OS/Browser trust store /etc/ssl/certs/

Intermediate CA (R3):
  Subject: R3, Issuer: ISRG Root X1 → Issued by Root
  Basic Constraints: CA=TRUE, pathLenConstraint=0 (cannot issue further CAs)

Leaf (grafana.liz6.com):
  Subject: grafana.liz6.com, Issuer: R3 → Issued by Intermediate
  Basic Constraints: CA=FALSE

Verification: Bottom-up: leaf → R3 → Root → trust anchor (in trust store)

ACME

Clients (certbot/acme.sh) automatically obtain certificates via the ACME v2 protocol:

1. Create account: POST /acme/new-acct → account URL
2. Submit order: POST /acme/new-order { identifiers: [grafana, *.liz6.com] }
   → order object + authorizations + challenges
3. Complete challenges:
   HTTP-01: http://domain/.well-known/acme-challenge/<token>
            → CA verifies GET returns key authorization = token + "." + thumbprint
   DNS-01:  Place TXT _acme-challenge.domain = key authorization
            → CA verifies DNS (can issue wildcards!)
   TLS-ALPN-01: Return key authorization in ALPN
4. Wait for validation → CA verifies challenge
5. Finalize: POST CSR → CA issues certificate
6. Download: certificate chain (PEM, ~3-5KB)

OCSP and Revocation

OCSP (Online Certificate Status Protocol):
  Client: Asks CA "What is the status of this serial number certificate?"
  CA: "good" / "revoked" / "unknown"
  Issue: CA knows which website you are visiting → Privacy + Latency (additional TLS connection)

OCSP Stapling (RFC 6066, TLS Certificate Status Request extension):
  Server: Periodically fetches OCSP response (signed) from CA → Caches it locally
  TLS Handshake: Includes OCSP response in CertificateStatus message
  Client: Verifies OCSP response signature → No need to request OCSP separately
  → Privacy + Latency optimization

CRL (Certificate Revocation List):
  Periodically published list of revoked certificates (all revoked certs within the entire CA scope)
  Drawbacks: Large (can be MBs), delayed updates (typically 24h)
  OCSP is more real-time (but stapling is needed for privacy)

Certificate Transparency

Problem: Malicious CA (or compromised CA) issues unauthorized certificates → Man-in-the-middle attacks

CT (RFC 6962):
  All certificates are submitted to public CT logs:
    → SCT (Signed Certificate Timestamp): "Receipt" from the log to the certificate
    → Browser verification: Certificate must contain at least 2 SCTs (from different log operators)
  → Monitor: Anyone can monitor CT logs → Detect unauthorized issuance

  Your certificates: crt.sh/?domain=liz6.com → View all certificate history for liz6.com

References

• RFC: 5280, 8555, 6960, 6962, 7633 (CT for code signing)
• Tools: openssl x509 -text -in cert.pem, crt.sh, certbot certificates

Keywords: X.509, SAN, chain of trust, ACME, Let's Encrypt, DNS-01, OCSP stapling, CRL, SCT, CT logs