rgoussu.dev
rgoussu@goussu: ~/library/security
❯ ~/library/security cat tls-https-and-certificates.md

TLS/HTTPS & certificate management

# How SSL/TLS actually works — the handshake, the certificate/PKI trust architecture, and operating certificates in practice.

Conceptsaved 2026-08-08updated 2026-08-09 #tls#https#certificates#pki#security#networking

Overview

HTTPS is HTTP inside a TLS tunnel, and TLS answers two distinct questions: is the traffic private and untampered (cryptography) and am I really talking to who I think (the certificate/PKI trust architecture). Engineers mostly meet the second one — expired certificates remain one of the most reliable ways to take down production. Understanding the handshake, the chain of trust, and the management lifecycle turns certificates from recurring incidents into routine automation. ("SSL" survives as the colloquial name; the actual protocols are TLS 1.2 and 1.3 — SSL and TLS 1.0/1.1 are dead.)

Key points

  • The TLS 1.3 handshake in one pass: ClientHello (supported versions/ciphers + key share) → ServerHello (chosen cipher + key share) → server sends its certificate chain and proves possession of the private key → both sides derive session keys via ephemeral Diffie-Hellman (ECDHE) → symmetric encryption (AES-GCM / ChaCha20-Poly1305) takes over. Asymmetric crypto authenticates and exchanges keys; symmetric crypto carries the data.
  • Forward secrecy: because session keys are ephemeral, a later compromise of the server's private key cannot decrypt recorded past traffic — the reason static-RSA key exchange was removed in 1.3.
  • What a certificate is: an X.509 document binding a public key to an identity (Subject/SANs — hostname validation uses SANs, not CN), signed by an issuer, with a validity window, key-usage constraints, and revocation pointers. It is identity, not encryption: the certificate contains nothing secret.
  • The trust architecture (PKI): root CAs (offline, in OS/browser trust stores) sign intermediate CAs, which sign leaf certificates — verification walks the chain from leaf to a trusted root, checking signatures, validity dates, name match, and constraints. A missing intermediate in the served chain is the classic "works in Chrome, fails in curl/Java" bug. Certificate Transparency logs make mis-issuance publicly auditable.
  • Validation levels & issuance: DV (prove domain control — what Let's Encrypt does via ACME's HTTP-01/DNS-01 challenges), OV/EV (organization vetting; largely cosmetic since browsers dropped the UI). ACME made 90-day, auto-renewed DV certs the norm — short lifetimes are a feature: they force automation and bound compromise windows.
  • Revocation is the weak spot: CRLs and OCSP both have failure modes (soft-fail checking is near-universal); OCSP stapling and short-lived certs are the practical answers.
  • Managing certificates in practice: automate renewal (cert-manager in Kubernetes, certbot, cloud-managed certs) and alert on expiry anyway; keep private keys out of images and repos (secrets management); know your termination point (edge/LB vs. end-to-end) and what re-encryption happens behind it; internal PKI (private CA — Vault, step-ca, cloud CAs) for service-to-service mTLS, where both sides present certificates — identity for machines, foundation of zero-trust/service-mesh setups (SPIFFE as the emerging standard).
  • Debugging kit: openssl s_client -connect host:443 -showcerts (read the chain), openssl x509 -text (read one cert), curl -v, and the browser's certificate viewer; most TLS incidents are chain, name, or clock problems.
  • To explore: TLS termination vs. passthrough trade-offs, HSTS and certificate pinning (and why pinning is now discouraged), post-quantum key exchange rollout.

The handshake in sequence — asymmetric crypto authenticates and exchanges keys, then symmetric crypto carries the data:

sequenceDiagram
    participant C as Client
    participant S as Server
    C->>S: ClientHello (supported versions, ciphers, key share)
    S-->>C: ServerHello (chosen cipher, key share)
    S-->>C: Certificate chain + proof of private-key possession
    Note over C,S: Both sides derive session keys via ephemeral Diffie-Hellman (ECDHE)
    Note over C,S: Symmetric encryption (AES-GCM / ChaCha20-Poly1305) takes over
    C->>S: Application data over the symmetric channel
    S-->>C: Application data over the symmetric channel

And the chain of trust — signatures flow down, verification walks back up:

flowchart TD
    Root["Root CA - offline, in OS/browser trust stores"] -- signs --> Int["Intermediate CA"]
    Int -- signs --> Leaf["Leaf certificate"]
    Leaf -. "verification walks the chain: signatures, validity dates, name match, constraints" .-> Root

Practice

  • badssl.com (source) — click through dozens of broken and valid TLS configs in the browser; learn what every chain, name, and clock failure looks like.
  • Qualys SSL Labs test (source) — grade a real server's TLS and read the findings: cipher suites, chain issues, forward secrecy, protocol versions.
  • Certbot on your own domain (source) — issue a real DV certificate over ACME and automate renewal — the 90-day norm made routine.
  • Stand up your own CA + mTLS (exercise) — run a private CA, issue leaf certs, and require both sides to present one between two services.

Related