# What Happens During a TLS Handshake?

> Follow the TLS handshake from ClientHello through certificate validation and encrypted application traffic.

Canonical: https://sentryxmonitor.com/learn/networking/tls-handshake/
Last updated: 2026-08-08

Networking and protocol operations

A TLS handshake lets a client and server agree on cryptographic parameters, authenticate the server certificate, derive shared traffic keys, and confirm that subsequent application data can be encrypted and integrity-protected.

Reviewed 2026-08-08 Read-only educational guidance

## Key points

- The client proposes versions and cryptographic options.

- The server presents identity evidence through its certificate chain.

- Application data follows only after key establishment.

## How does it work?

In TLS 1.3 the client sends a ClientHello with supported versions, groups, and key material. The server selects parameters, returns a ServerHello and certificate messages, and both sides derive keys from the handshake transcript.

## What can go wrong?

Failures occur when versions or algorithms do not overlap, certificates are expired or untrusted, hostname validation fails, intermediates are missing, or middleboxes interfere.

## How can teams detect the problem?

Test supported versions, negotiated cipher, certificate chain, hostname, validity period, OCSP behavior where relevant, and handshake latency.

## How can teams fix or reduce the problem?

Use modern TLS libraries, automate certificate deployment, serve complete chains, remove obsolete protocols, and monitor from realistic client locations.

## What does a technical example look like?

```
ClientHello -> ServerHello -> EncryptedExtensions -> Certificate -> CertificateVerify -> Finished -> encrypted HTTP
```

The example uses reserved documentation domains and addresses. Apply the same reasoning to systems you own or are authorized to assess.

## Authoritative technical references

- [RFC 8446: The Transport Layer Security Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446.html)

## How does continuous monitoring help?

A point-in-time check explains the observed state now. [Continuous monitoring](https://sentryxmonitor.com/services/uptime-monitoring/) establishes an expected baseline, repeats the relevant check, and records meaningful state changes so an owner can investigate before a small configuration drift becomes a prolonged security or availability problem. See [Networking](https://sentryxmonitor.com/learn/networking/) for the surrounding technical context.

## Where does Sentryx Monitor fit?

Sentryx Monitor provides [read-only outside-in discovery](https://sentryxmonitor.com/services/external-attack-surface-monitoring/) and monitoring for public hosts, DNS, HTTPS, TLS certificates, baseline security headers, email-security records, and selected network services. It supports evidence and operational follow-up, but it does not replace authorized penetration testing, authenticated vulnerability assessment, or owner validation.

## Continue learning

- [Internet Networking for Security and Monitoring](https://sentryxmonitor.com/learn/networking/) - The parent networking guide.

- [What Is TCP Port Monitoring?](https://sentryxmonitor.com/learn/networking/tcp-port-monitoring/) - Learn how TCP port monitoring checks service reachability and where it differs from application monitoring.

- [Common Internet-Facing Ports Explained](https://sentryxmonitor.com/learn/networking/internet-facing-ports/) - Understand common public TCP and UDP ports and when exposure deserves review.

- [What Does Port 443 Do?](https://sentryxmonitor.com/learn/networking/port-443/) - Understand how port 443 carries HTTPS traffic and how DNS, TCP, TLS, and HTTP participate.

## Related
- [Home](https://sentryxmonitor.com/)