What Is an SSL Handshake? TLS Handshake Explained

An SSL handshake is the setup phase that turns an ordinary network connection into an encrypted, authenticated one. The name is historical: SSL is the old protocol family, while modern HTTPS and other secure protocols use TLS. When someone says "SSL handshake" in 2026, they usually mean a TLS handshake.

The handshake happens before the browser sends the HTTP request body, before a DNS-over-TLS resolver sends a DNS query, and before an SMTP server sends mail over STARTTLS. It answers five questions:

1. Which TLS version will both sides use?
2. Which cryptographic algorithms and application protocol will they use?
3. Is the server really allowed to represent this hostname?
4. Can both sides derive the same shared encryption keys?
5. Has anyone tampered with the setup messages?

Once those checks pass, both sides switch to encrypted application data.

Where the Handshake Fits

For a normal first-time HTTPS visit, the path looks like this:

Browser
  -> DNS lookup for example.com
  -> TCP connection to the chosen IP address
  -> TLS handshake
  -> HTTP request and response over encrypted TLS

With HTTP/3, the transport changes because QUIC runs over UDP and includes TLS 1.3 inside the QUIC connection setup. The security goals are the same: authenticate the endpoint and derive fresh encryption keys before application data is exchanged.

HTTPS records can let a browser learn HTTP/3, ALPN, IP hints, and Encrypted Client Hello configuration from DNS before it connects. CAA records control which public CAs may issue the server certificate. TLSA records can publish certificate or public-key fingerprints for DANE-validating clients. Those DNS records do not replace the handshake, but they shape the trust and connection metadata around it.

TLS 1.3 Handshake Step by Step

TLS 1.3, defined in RFC 8446, simplified the handshake compared with TLS 1.2 and removed older negotiation paths. A typical full TLS 1.3 handshake looks like this:

The exact message flow can vary with session resumption, client certificates, HelloRetryRequest, or QUIC, but the main ideas stay consistent: negotiate parameters, authenticate the peer, derive keys, and protect the transcript.

ClientHello

The ClientHello is the client's opening offer. It usually contains:

• Supported TLS versions
• Supported cipher suites
• Supported elliptic-curve groups
• A key share for key exchange
• The hostname through SNI (Server Name Indication)
• Supported application protocols through ALPN
• Optional extension data, such as ECH-related configuration in supporting deployments

SNI matters because many servers host multiple domains on one IP address. Without SNI, the server may not know which certificate to present. If SNI is missing or wrong, the client may see a certificate for another hostname and fail the handshake.

ALPN matters because it lets the client and server choose the application protocol inside TLS: for example h2 for HTTP/2 or http/1.1 for HTTP/1.1. HTTPS and SVCB records can advertise ALPN preferences before the connection starts, but the negotiated ALPN result still happens in the TLS handshake.

ServerHello

The ServerHello is the server's choice. The server selects one TLS version and one cipher suite from the client's offered set, and it sends its own key share. With modern ECDHE-based key exchange, neither side sends the final session key directly. Instead, each side combines its private key material with the other side's public key share and independently calculates the same shared secret.

That property is why modern TLS provides forward secrecy. If the server's certificate private key is compromised later, old captured TLS sessions should still remain protected, because the temporary key exchange material from those sessions is not recoverable from the certificate key alone.

Certificate Validation

The server then proves its identity with a certificate chain. The client checks:

• The leaf certificate covers the hostname requested through SNI
• The certificate is within its validity period
• The certificate has the right key usage for TLS server authentication
• The chain connects through intermediates to a trusted root CA
• The certificate has not been revoked, where revocation checking is available
• The server can prove possession of the certificate private key

For the chain details, see What Is an SSL Certificate Chain. For the certificate itself, see SSL and TLS Certificates Explained.

DNS can affect certificate trust before this point. CAA records publish which CAs are authorized to issue for your domain. ACME DNS-01 challenges let a CA verify domain control by checking a temporary TXT record. TLSA records, when protected by DNSSEC, let DANE-aware clients compare the presented certificate or public key with DNS-published data.

Finished Messages

The Finished messages are integrity checks over the handshake transcript. Each side sends a value derived from the negotiated secrets and every handshake message seen so far. If an attacker changed the version, cipher suite, certificate, key share, or extension data in transit, the Finished check would fail.

After both Finished messages validate, the client and server use application traffic keys. From this point on, HTTP headers and bodies, DNS messages inside DoT, or SMTP data after STARTTLS are encrypted and integrity-protected.

TLS 1.2 vs TLS 1.3

TLS 1.2 is still common, but TLS 1.3 is simpler and faster.

TLS 1.0 and TLS 1.1 are deprecated by RFC 8996. Public services should support TLS 1.2 and TLS 1.3, with TLS 1.3 preferred where clients and servers support it.

Common SSL Handshake Failures

Expired Certificate

If the leaf certificate or an intermediate certificate is expired, clients refuse the connection.

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

Check notAfter. If the date has passed, renew the certificate and reload the service.

Hostname Mismatch

The certificate must cover the exact hostname the client requested. A certificate for www.example.com does not automatically cover api.example.com, and a wildcard like *.example.com does not cover a.b.example.com.

openssl s_client -connect 203.0.113.10:443 -servername api.example.com -showcerts

If the wrong certificate appears, check SNI configuration, virtual hosts, load balancer listener rules, and whether DNS points to the expected endpoint.

Missing Intermediate Certificate

Servers must usually send the leaf certificate plus intermediate certificates. If the server sends only the leaf, some clients cannot build a trusted chain.

openssl s_client -connect example.com:443 -servername example.com -showcerts

Look for the full chain and Verify return code: 0 (ok). If intermediates are missing, deploy the CA-provided fullchain.pem or equivalent bundle.

Unsupported TLS Version

Old clients may not support modern server settings. Old servers may not support modern client requirements. A public service should not keep obsolete protocols enabled just for compatibility; use a separate legacy endpoint if you truly need one.

# Test TLS 1.3
openssl s_client -connect example.com:443 -servername example.com -tls1_3
 
# Test TLS 1.2
openssl s_client -connect example.com:443 -servername example.com -tls1_2

Cipher Suite Mismatch

A cipher mismatch happens when client and server have no shared cipher suite. This is less common with TLS 1.3 because the cipher suite model is narrower, but it still happens with strict TLS 1.2 configurations, old Java runtimes, old appliances, and FIPS-only environments.

SNI Misconfiguration

If your server hosts multiple domains on one IP address, SNI chooses which certificate to present. A common failure is testing only the IP address or omitting -servername with OpenSSL:

# Often wrong for virtual hosts
openssl s_client -connect example.com:443
 
# Correct for SNI-aware testing
openssl s_client -connect example.com:443 -servername example.com

ALPN or Protocol Problems

The TLS handshake can succeed while the selected application protocol is wrong. For example, a client may expect HTTP/2 but the server only negotiates HTTP/1.1.

openssl s_client -connect example.com:443 -servername example.com -alpn h2,http/1.1

For web services, HTTPS records can advertise h3, h2, and related connection hints before the connection starts. The server still has to support the advertised protocol during the actual connection.

Quick Debug Checklist

1. Confirm DNS points to the expected service:

   Copy

   dig A example.com +short
   dig AAAA example.com +short
   dig HTTPS example.com +short

2. Inspect the live handshake:

   Copy

   openssl s_client -connect example.com:443 -servername example.com -showcerts

3. Check the HTTP client's view:

   Copy

   curl -vI https://example.com

4. Check certificate issuance policy:

   Copy

   dig CAA example.com +short

5. If you use DANE, check TLSA and DNSSEC:

   Copy

   dig +dnssec TLSA _443._tcp.example.com

How DNS Records Support TLS

TLS handshakes do not live inside DNS, but DNS is part of the operating model around TLS:

This is where DNScale fits: it does not terminate your website's TLS connection, but it manages the DNS records that influence certificate issuance, DNS-based validation, DANE, HTTPS service hints, and the endpoint clients reach before the handshake begins.

Related Guides

• SSL and TLS Certificates Explained - certificate basics
• What Is an SSL Certificate Chain - how CA trust chains validate during the handshake
• What Is an HTTPS Record - ALPN, HTTP/3, ECH, and connection hints in DNS
• DNS CAA Record Explained - control certificate issuance through DNS
• DNS TLSA Record Explained - DANE certificate pinning through DNSSEC
• Let's Encrypt DNS-01 Challenges with DNScale - automate certificate issuance with DNS
• DNS over TLS Explained - DNS queries inside a TLS connection
• DNSSEC - DNS authenticity for DANE and signed records

References

• RFC 8446 - TLS 1.3
• RFC 6066 - TLS Extensions, including SNI
• RFC 7301 - ALPN
• RFC 8996 - Deprecating TLS 1.0 and TLS 1.1
• RFC 9460 - SVCB and HTTPS DNS records

Conclusion

The SSL handshake is the negotiation that makes encrypted connections possible. In modern infrastructure, that means a TLS handshake: the client and server agree on protocol settings, authenticate the certificate, derive fresh session keys, and verify that the setup was not tampered with. DNS does not perform the handshake, but DNS determines where clients connect and can publish the records that make certificate issuance, DANE validation, HTTPS hints, and secure automation work reliably.