The browser opens a TCP connection and sends a Client Hello — unencrypted, because no keys have been exchanged yet. It contains: a list of TLS versions the client supports, a list of cipher suites it can use (e.g. TLS_AES_256_GCM_SHA384), a 32-byte client random value, and optionally a Session ID for resumption. The client random is a unique value generated for this connection — it feeds into the final key derivation.
The server replies with a Server Hello, also unencrypted. It selects the highest mutually supported TLS version, picks one cipher suite from the client's list, and sends its own 32-byte server random. The cipher suite chosen here is binding — it determines the key exchange algorithm, the symmetric encryption algorithm, and the MAC/hash function for the entire session. A bad server may negotiate TLS 1.0 and a weak cipher if the client allows it.
The server sends its X.509 certificate (and any intermediate CA certs in the chain). The browser performs several checks: Is the cert signed by a trusted root CA? Has it expired? Does the hostname match the certificate's Subject or Subject Alternative Names? Is the cert revoked (OCSP check)? If any check fails, the browser shows a warning and (by default) blocks the connection. The cert also contains the server's public key, which is critical for the next step.
In TLS 1.3, key exchange uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). Both the client and server independently generate an ephemeral key pair. They exchange public keys. Through the math of Diffie-Hellman, both sides arrive at the same shared secret — without ever transmitting that secret across the network. The server signs its key exchange parameters using its certificate's private key, proving it is who the cert says it is. The shared secret + client random + server random are fed into a key derivation function to produce the session keys.
Both sides independently derive the same symmetric session keys from the shared secret. There are actually multiple keys: one for encrypting client-to-server traffic, one for encrypting server-to-client traffic, and matching MAC keys. These keys are ephemeral — new every session, discarded when the session ends. From this point on, asymmetric cryptography is done. All data will use fast symmetric encryption (AES-GCM or ChaCha20-Poly1305 in modern TLS).
The client sends a Finished message — the first encrypted message in the handshake. It contains a cryptographic hash of every handshake message exchanged so far. The server decrypts it and verifies the hash. If the hash doesn't match, the handshake aborts. This step proves that the handshake messages were not tampered with in transit and that both sides derived the same keys.
The server sends its own encrypted Finished message with a hash of the handshake transcript. The client verifies it. Both sides have now proven: they share identical session keys, and no one tampered with the handshake. The TLS channel is established. In TLS 1.3, this entire handshake takes 1 round-trip (1-RTT). Session resumption can reduce it to 0-RTT.
HTTP requests and responses now flow inside TLS records. Each record has: a Content-Type field, TLS version, record length, and the encrypted payload followed by an authentication tag (AEAD — Authenticated Encryption with Associated Data). The auth tag guarantees both confidentiality AND integrity. Any tampering with the ciphertext causes the tag verification to fail and the record is rejected — the connection cannot be silently corrupted.
Asymmetric crypto (ECDH, RSA) solves key distribution — two parties who've never met can agree on a secret. But it's computationally expensive. Symmetric crypto (AES-GCM, ChaCha20) is orders of magnitude faster. TLS uses asymmetric for the handshake to establish a shared secret, then switches to symmetric for all data. Best of both worlds.
With ECDHE, session keys are generated fresh for every connection and discarded afterward. Even if an attacker records all your encrypted traffic today and steals your server's private key tomorrow, they cannot decrypt past sessions. TLS 1.3 mandates PFS — all non-PFS cipher suites (RSA key exchange) were removed. If your server still supports TLS 1.2 without ECDHE, it's a problem.
Your browser ships with ~130 trusted root CAs. Your server's cert is signed by an intermediate CA, which is signed by a root CA. The browser walks this chain verifying each signature. If the root isn't trusted, or any cert in the chain is expired or revoked, the chain breaks. Check your chain with: openssl s_client -connect example.com:443 -showcerts
| Field | Description | Example |
|---|---|---|
Subject |
The entity the cert was issued to. In modern certs the CN is less important than the SANs below. | CN=example.com, O=Example Corp, C=US |
Subject Alt Names |
The definitive list of hostnames this cert is valid for. Browsers match against SANs, not CN. A single cert can cover many domains (multi-SAN / wildcard). | DNS:example.com, DNS:www.example.com, DNS:*.example.com |
Issuer |
The CA that signed this certificate. Usually an intermediate CA, not the root. | CN=R11, O=Let's Encrypt, C=US |
Valid From / To |
The validity window. After the "Not After" date, all browsers reject the cert. Let's Encrypt certs are 90 days — automate renewal or they'll expire on you. | 2026-01-01 → 2026-04-01 |
Public Key |
The server's public key. Used by the client during key exchange to verify the server's signature on the ECDH parameters. | EC 256-bit (prime256v1) or RSA 2048/4096 |
Signature |
The CA's cryptographic signature over the certificate's fields. The browser verifies this with the CA's public key to confirm the cert wasn't forged. | SHA256withRSA or ecdsa-with-SHA256 |
Serial Number |
A unique identifier within the CA's namespace. Used in CRL (Certificate Revocation List) and OCSP to check if this specific cert has been revoked. | 0x03A1B7F2C... |
Key Usage / EKU |
Constrains what the key can be used for. Extended Key Usage (EKU) specifies TLS Web Server Authentication, Code Signing, etc. Mismatches cause errors. | Digital Signature; TLS Web Server Authentication |
Basic Constraints |
Whether this cert is a CA cert (can sign other certs) or an end-entity cert. End-entity certs have CA:FALSE — if a site cert claimed CA:TRUE, it could forge certs for any domain. | CA:FALSE (end-entity) or CA:TRUE (CA cert) |
An attacker on the network intercepts an HTTP request before TLS is established and responds as if they are the server — serving HTTP content while maintaining an HTTPS connection to the real server. The user sees no padlock. Mitigation: HSTS (HTTP Strict Transport Security) with a long max-age tells the browser to never connect via plain HTTP. The HSTS Preload list bakes this in before the first visit.
A CA (or a compromised sub-CA) issues a valid cert for a domain they don't control. Anyone holding that cert can MITM connections for that domain with no browser warning. Certificate Transparency (CT) requires all CAs to log every issued cert to public append-only logs. Tools like crt.sh let you monitor all certs issued for your domain. CAA DNS records restrict which CAs are permitted to issue for your domain.
POODLE (2014) forced connections down to SSLv3, then exploited its CBC padding. BEAST (2011) exploited TLS 1.0 CBC. The mitigations: TLS 1.3 removed all legacy cipher suites and version negotiation that allowed downgrades. Audit your server: nmap --script ssl-enum-ciphers -p 443 example.com — if you see TLS 1.0, TLS 1.1, or SSLv3, disable them.
Expired certs produce browser warnings that users learn to click through — training them to ignore security signals. Self-signed certs provide encryption but no authentication: you can't verify who you're talking to, making MITM trivially undetectable. Automate cert renewal with Let's Encrypt + certbot or acme.sh. Monitor expiry with Uptime Robot, Zabbix, or a simple cron job.
The Server Name Indication (SNI) extension in the Client Hello tells the server which hostname the client wants — so the server can pick the right cert. This extension is sent in plaintext, before encryption. Even on HTTPS, a network observer sees which domain you're connecting to. DNS-over-HTTPS hides the DNS lookup, but SNI leaks the hostname at the TLS layer. Encrypted Client Hello (ECH) in TLS 1.3 aims to encrypt the SNI — browser support is growing.