TLS and HTTPS: certificates and the handshake

What the handshake proves, how a certificate chain is verified, what SNI and ALPN do, why TLS 1.3 is one round trip, and what a browser checks before showing a lock.

The handshake in outline

TLS 1.2                          TLS 1.3
ClientHello                      ClientHello + key share
                                  (guess at the group)
ServerHello, Certificate,        ServerHello, key share,
ServerKeyExchange,               Certificate, Finished
ServerHelloDone
ClientKeyExchange,
ChangeCipherSpec, Finished
ChangeCipherSpec, Finished

2 round trips before data         1 round trip before data

• The handshake authenticates the server and agrees a shared secret; the certificate is what makes the authentication meaningful.
• TLS 1.3 removed RSA key transport, static DH and renegotiation, which removed a long list of known pitfalls.
• Session resumption with a pre-shared key allows 0-RTT data, which is replayable — use it only for idempotent requests.
• The client verifies the server; the server may ask for a client certificate, which is common in machine-to-machine APIs.

# inspect a live handshake
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# what the server offers
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -i "protocol\|cipher"

What a certificate actually asserts

verification steps a client performs

1  build a chain from the leaf to a trusted root
2  verify every signature in the chain
3  check the current time against validity
4  check the requested name against the SANs
5  check that no certificate in the chain is revoked
6  check that revocation data is fresh enough (or soft-fail)
7  confirm the server proves possession of the private key

A self-signed certificate fails step 1 unless it is explicitly added to the trust store. That is the whole difference between a browser warning and a working internal service.

SNI, ALPN and the checks a browser makes

• SNI sends the requested hostname in the handshake so one address can serve many certificates. Without it, virtual hosting over TLS would be impossible.
• ALPN negotiates the application protocol, which is how a client offers HTTP/2 and HTTP/1.1 in one connection setup.
• Certificate transparency requires public logs, so a mis-issued certificate for your domain becomes detectable.
• HSTS tells the browser to refuse plain HTTP for a domain for a set period, including subdomains if requested.
• A browser accepts the connection only after certificate validation and hostname matching succeed; the padlock says nothing about whether the site is trustworthy.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Expect-CT: max-age=86400, enforce

# roll HSTS out carefully: max-age=0 removes it, but clients that already
# cached a long max-age will keep enforcing it until it expires

FAQ

Related

DNS deep dive: zones, records and DNSSEC Network security: eavesdropping, MITM and DDoS

Last refreshed 2026-09-18.