What TLS protects, and where it fits

TLS (Transport Layer Security) sits between the transport layer and the application layer in the common HTTPS over TCP case. The application sends data to TLS. TLS encrypts and authenticates it. TCP carries the ciphertext.

Version 1.3 was published as RFC 8446 in 2018 and revised as RFC 9846, July 2026. The revision obsoletes RFC 8446 and keeps the protocol version at 1.3, so nothing on the wire changes name: it is a tightened specification of the same protocol, not TLS 1.4. Two changes are worth knowing because they close doors that implementations had left open. RFC 9846 forbids reusing a KeyShare across handshakes, which removes a class of implementation shortcut that quietly weakened forward secrecy, and it bans negotiating TLS 1.0 and TLS 1.1 outright rather than leaving their exclusion to policy. Cite RFC 9846 as the current specification and treat a document that still cites 8446 alone as out of date.

In HTTP/3, TLS 1.3 is integrated into the QUIC handshake. The cryptographic handshake is not separate from the transport handshake. This means QUIC achieves an encrypted connection in fewer round trips than TCP plus TLS 1.3 separately.

TLS provides three properties once the handshake completes. Confidentiality: the data is encrypted and not readable by observers. Integrity: data cannot be modified in transit without detection. Authentication: one or both peers prove their identity via certificates. The most common case authenticates the server only. mTLS (mutual TLS) authenticates both peers.

TLS also has a metadata boundary. TLS 1.3 encrypts the certificate after the early handshake, but many deployments still expose the intended hostname in SNI. Encrypted Client Hello, defined in RFC 9849, can hide the real ClientHello and SNI when the client, DNS, and server deployment all support it.

Those three properties are promises the protocol makes once the handshake has finished. What the handshake itself costs, and how few round trips it now takes to get there, is the difference between a page that feels instant and one that does not.

TLS 1.3 reduced the handshake to one round trip (1-RTT). The client sends a ClientHello with supported cipher suites and key share data. The server responds with a ServerHello, its key share, a certificate, and a certificate verify message in a single flight. After the client validates the certificate and verifies the server's signature, the handshake is complete and application data can flow.

TLS 1.2 required two round trips for a full handshake. The reduction to 1-RTT in TLS 1.3 was achieved partly by removing insecure cipher suites that required additional negotiation messages and by making key exchange part of the initial hello.

For repeat connections, TLS 1.3 supports 0-RTT (zero round-trip) resumption using a pre-shared session ticket. The client can send application data in the first message, before the handshake completes. This is fast but has a replay caveat: 0-RTT data is vulnerable to replay attacks, so it should only be used for requests that are safe to replay (GET requests, not POST requests with side effects).

One flight of that handshake carries the server's certificate, and the client cannot use any of the keys it has just derived until it has decided whether that certificate really belongs to the name it asked for. That decision is where most of the errors people meet in production come from.

A TLS certificate binds a public key to an identity (a hostname) and is signed by a certificate authority (CA). When a client receives a server's certificate, it validates the certificate chain: the certificate was signed by an intermediate CA, which was signed by a root CA that the client's trust store considers authoritative.

Validation checks include: the hostname in the certificate matches the hostname in the request (Subject Alternative Names), the certificate has not expired, the certificate has not been revoked (checked via CRL or OCSP), and the cryptographic signature is valid.

Certificate Transparency (CT) adds public, append-only audit logs for certificate issuance. RFC 6962 defined the original experimental CT design; RFC 9162 defines Certificate Transparency Version 2.0. Browser and certificate authority policies are what turn CT from a logging mechanism into a deployment requirement for public web certificates. CT allows domain owners and security researchers to detect misissued certificates.

Validation of this kind settles who you are talking to right now. It says nothing about what happens to the traffic if the private key behind that certificate is stolen next year, which is a separate property with a separate mechanism.

Forward secrecy (more precisely, forward secrecy is sometimes called perfect forward secrecy or PFS) means that the compromise of long-term keys does not expose past session recordings. TLS 1.3 requires forward secrecy. Every handshake uses ephemeral key exchange (ECDHE, elliptic curve Diffie-Hellman ephemeral), meaning a fresh key pair is generated for each session and discarded afterwards.

TLS 1.2 allowed non-forward-secret cipher suites using RSA key exchange. If an attacker recorded encrypted TLS 1.2 traffic and later obtained the server's private key, they could decrypt all recorded sessions. TLS 1.3 removes this risk by mandating ephemeral key exchange.

mTLS (mutual TLS) is TLS where both the client and server present certificates. The server validates the client certificate, not just the server certificate. This is used for service-to-service authentication in internal systems and API authentication where you want cryptographic proof of caller identity.

Both sides of an mTLS deployment hold certificates, and so does every public web server in the module so far. How long each of those certificates stays valid is no longer the annual figure most runbooks still assume.

The CA/Browser Forum approved ballot SC-081v3 on 11 April 2025, which sets a published schedule for cutting the maximum validity of a publicly trusted TLS certificate. From 15 March 2026 the maximum is 200 days. From March 2027 it drops to 100 days. From March 2029 it drops to 47 days. The same ballot shortens how long the domain validation data behind an issuance may be reused, so the verification work shrinks on the same curve as the certificate.

A 47-day certificate cannot be managed the way a one-year certificate was. Renewal stops being an annual calendar entry that a named person owns and becomes a process that runs every few weeks, on every host and every load balancer, including the ones nobody remembers. Any manual step in that process becomes an outage waiting for a holiday.

ACME, specified in RFC 8555, is the protocol that makes the schedule survivable. A client proves control of the domain, the CA issues, and the same exchange handles renewal and revocation without a human filling in a form. Under the new lifetimes it stops being an efficiency and becomes the baseline: an estate that cannot issue and install a certificate unattended is an estate that will start expiring certificates in production.

The practical checks follow from the dates. Know which certificates in your estate are publicly trusted, because private internal CAs are outside this schedule and can keep longer lifetimes. Know which of the public ones are still renewed by hand. Know that a certificate issued the day before a threshold keeps its full issued lifetime, so the change arrives on your estate gradually rather than all at once, which is exactly how it catches teams out.