The TLS Handshake and Certificate Chains

#Context

curl -sv https://example.com -o /dev/null 2>&1 \
  | grep -E '^\* (SSL|TLS|ALPN)'
# * TLSv1.3 (OUT), TLS handshake, Client hello (1):
# * TLSv1.3 (IN), TLS handshake, Server hello (2):
# * TLSv1.3 (IN), TLS handshake, Certificate (11):
# * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
# * ALPN: server accepted h2

Certificate

A signed statement binding a public key to names (the domains in its SAN, Subject Alternative Name, field) for a limited time.

CA (certificate authority)

An organisation whose signature browsers and operating systems trust. Its root certificate ships in the device trust store.

ECDHE

Elliptic-curve Diffie-Hellman, ephemeral: both sides generate a throwaway key pair per connection and derive the same secret without ever sending it.

Forward secrecy

Recording traffic today and stealing the server key tomorrow still does not decrypt it, because the session keys came from ephemeral keys that no longer exist.

SNI (Server Name Indication)

The hostname the client puts in its first message so one IP address can serve many certificates.

ALPN (Application-Layer Protocol Negotiation)

The handshake field where client and server agree on HTTP/2 or HTTP/1.1, so no extra round trip is needed.

#Why it matters

#The TLS 1.3 handshake, message by message

1. 1
   ClientHello. Supported versions and cipher suites, a random nonce, an ECDHE public key (key_share, usually X25519), the hostname in SNI, and the protocols it speaks in ALPN (h2, http/1.1). SNI travels in plaintext unless the client uses ECH (Encrypted Client Hello).
2. 2
   ServerHello. The server picks the version and cipher suite and sends its own key_share. Both sides now compute the same Diffie-Hellman secret and derive handshake keys from it; nothing secret crossed the wire.
3. 3
   Encrypted server flight. EncryptedExtensions carries the ALPN choice; Certificate carries the leaf and intermediates; CertificateVerify is a signature over the whole handshake so far, made with the private key behind the certificate, which is what proves the server owns it; Finished is a MAC (message authentication code) over the transcript, so any tampering is detected.
4. 4
   Client Finished. The client validates the certificate chain and the signature, sends its own Finished, and can attach the first HTTP request in the same packet. Both sides switch to application keys.

#How the client decides to trust the server

1. 1
   Signatures. Each certificate's signature verifies with the public key of the one above it, ending at a root in the local trust store.
2. 2
   Name. The hostname the client asked for must match a SAN entry on the leaf; *.example.com covers one label, not a.b.example.com. The old Common Name field is ignored by modern clients.
3. 3
   Dates. Now must be between notBefore and notAfter, which is why a device with a wrong clock fails every handshake. Lifetimes keep shrinking: the CA/Browser Forum voted in 2025 to cut the maximum from 398 days to 200 in 2026 and to 47 days by 2029, so manual renewal stops being viable.
4. 4
   Revocation. A revoked certificate should be rejected. OCSP (Online Certificate Status Protocol) asked the CA per connection, which was slow and leaked browsing; OCSP stapling has the server attach a fresh signed status instead. In practice browsers lean on pushed revocation lists, and Let's Encrypt shut down its OCSP service in 2025.
5. 5
   Certificate Transparency. Since 2018 Chrome only trusts publicly issued certificates that were logged in public append-only logs, so a CA mis-issuing a certificate for your domain is visible to anyone monitoring the logs.

Mutual TLS

server {
    listen 443 ssl;
    ssl_certificate        /etc/tls/server-fullchain.pem;  # leaf + chain
    ssl_certificate_key    /etc/tls/server.key;
    ssl_protocols          TLSv1.2 TLSv1.3;

    # mTLS: require a client certificate signed by our internal CA
    ssl_client_certificate /etc/tls/internal-ca.pem;
    ssl_verify_client      on;

    location / {
        # pass the verified identity to the app
        proxy_set_header X-Client-DN $ssl_client_s_dn;
        proxy_pass http://app;
    }
}

#Resumption, 0-RTT and the replay problem

# full handshake details, with SNI (omit -servername and many hosts
# return the wrong certificate)
openssl s_client -connect api.example.com:443 \
  -servername api.example.com -tls1_3 </dev/null

# the chain the server actually sends (look for a missing intermediate)
openssl s_client -connect api.example.com:443 \
  -servername api.example.com -showcerts </dev/null

# expiry date of the live certificate
openssl s_client -connect api.example.com:443 \
  -servername api.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate -ext subjectAltName

#Pitfalls

• Serving the leaf without its intermediate

  Browsers often still connect because they cache intermediates or fetch them via the AIA (Authority Information Access) extension, so the site looks fine. Then curl, a mobile app or a server-side client fails with "unable to get local issuer certificate". Always deploy the full chain file and test with openssl s_client -showcerts, not a browser.

• Renewing by hand

  A yearly calendar reminder fails eventually, and certificate lifetimes are shrinking toward 47 days. Automate issuance and renewal with ACME (Automatic Certificate Management Environment) clients or your platform's managed certificates, and alert on days-to-expiry from an external probe, because the renewal job itself can silently break.

• Disabling verification to make an error go away

  rejectUnauthorized: false, verify=False or curl -k keep the encryption but drop authentication, so any machine in the path can present its own certificate and read everything. Fix the trust store or the chain instead; for internal CAs, add the CA explicitly to the client.

• Terminating TLS and forgetting the hop behind it

  A load balancer or CDN that terminates TLS forwards plain HTTP unless you configure otherwise. Inside a shared network or across regions that traffic is readable. Re-encrypt to the backend, or use mTLS between services, and make the app trust the forwarded protocol header only from the proxy.

• Enabling 0-RTT for everything

  Early data saves a round trip for returning visitors but can be replayed. If a CDN or server turns it on globally, a captured non-idempotent request can run twice. Limit it to safe methods or reject early data with 425 on endpoints that change state.

#Interview questions