TLS: What Is Actually Verified When a Connection Is Established

TLS gives you three things: the traffic is encrypted, it cannot be modified undetected, and the server is who the certificate says it is.

For a separate people-operations application of the same measurement discipline, see stealth monitoring software.

The third is the one with the interesting details, because it depends on a chain of trust with several places to go wrong — and on the client actually performing checks it is free to skip.

What the client checks

Chain of signatures. The server presents a certificate signed by an intermediate, signed by another, up to a root the client already trusts. Each signature is verified. The root is not sent — it must already be in the client's trust store.

Name. The requested hostname must match a name in the certificate's Subject Alternative Name extension. The Common Name field is deprecated for this purpose and modern clients ignore it, which surprises people maintaining older certificates.

Validity dates. Not before, not after. This check is why an expired certificate causes a total outage rather than a warning.

Revocation, sometimes. Discussed below, because this is the weakest part.

Key usage. The certificate must be permitted for server authentication.

If any fails, the connection is refused — provided the client is verifying. A client configured to skip verification performs none of these and will connect to anything.

What it does not tell you

Worth being explicit, because the assumptions are common.

Not that the server is trustworthy. It confirms the operator demonstrated control of the domain to a certificate authority. A phishing site has a valid certificate; that is not a failure of TLS.

Not that the certificate authority verified the organisation. Domain-validated certificates confirm control of the domain and nothing else, and they are the overwhelming majority.

Not that the connection is secure end to end. A load balancer or proxy that terminates TLS decrypts everything. The connection is encrypted to that point, and what happens after is a separate question.

Not that the client is who they claim. Mutual TLS adds that; ordinary TLS does not.

Not that the data is safe at rest. Different problem entirely.

Revocation barely works

The weakest link, and it is worth knowing rather than assuming it is handled.

Certificate revocation lists are lists of revoked certificates, published periodically. They grow large, they are fetched infrequently, and they are frequently not fetched at all.

OCSP queries the authority about one certificate. It adds a network round trip to the handshake, it leaks browsing information to the authority, and — critically — most clients soft-fail: if the OCSP responder is unreachable, they connect anyway. An attacker who can present a revoked certificate can usually also block the OCSP query.

OCSP stapling has the server fetch and attach a signed status, removing the round trip and the privacy issue. Better, and it depends on the server being configured for it, and stapling itself is now being deprecated by some authorities.

The practical consequence: revocation is not a reliable defence. The industry's answer has been shorter certificate lifetimes — a revoked certificate matters less if it expires in weeks. Lifetimes have been falling steadily, and this is the direction to plan for.

What this means for you: automate renewal. A certificate with a short lifetime renewed by hand will eventually expire on a weekend.

Where it actually breaks

Expiry. Still the most common cause of TLS outages. Automate renewal, and monitor expiry independently of the renewal system — the failure mode is renewal silently stopping, and only an external check catches that.

Missing intermediate certificate. The server must send the intermediates; only the root is assumed present. A server sending only its leaf certificate works in browsers that cache intermediates from elsewhere and fails in other clients. This is why "it works in Chrome but our API client fails" is nearly always the diagnosis. Test with a tool that does not cache.

Clock skew. A client with a wrong clock rejects valid certificates or accepts expired ones. See clocks in distributed systems.

Trust store not updated. An old system without a newer root cannot validate certificates chaining to it. Common on embedded devices and container images that are never rebuilt.

Hostname mismatch after a change. Adding a new domain to an existing service without adding it to the certificate.

Verification disabled. Someone hit a certificate error during development, disabled verification, and it shipped. This is the most consequential item in this list and it is invisible — everything works.

Mutual TLS

Both sides present certificates. Used for service-to-service authentication, and it moves the problem rather than removing it.

What you gain: the server knows which client is connecting, cryptographically, without shared secrets in configuration.

What you take on: issuing certificates to every client, rotating them, revoking them, and handling the case where a client's certificate expires. Client certificate expiry is now an outage of its own, and it is easy to overlook because it is not the one being monitored.

Service meshes automate this, which is much of their value proposition and much of their complexity.

Configuration worth checking

TLS 1.2 minimum, 1.3 preferred. Older versions have known weaknesses and are being removed from clients.

Disable renegotiation and compression.

Enable OCSP stapling where your authority still supports it.

HSTS for browser-facing services, so clients refuse to downgrade to plain HTTP.

Certificate transparency monitoring. All publicly trusted certificates are logged, and monitoring the logs for your domains tells you if someone issues a certificate for a name you own. This is one of the few controls that detects a compromised authority, and setting it up takes an afternoon.

Test with an external scanner. Configuration drifts, and a scan catches a downgrade someone made to fix a compatibility problem two years ago.

The checklist

• [ ] Renewal automated
• [ ] Expiry monitored independently of the renewal system
• [ ] Full chain served, verified with a client that does not cache intermediates
• [ ] Verification enabled everywhere — grep for the flags that disable it
• [ ] Minimum TLS 1.2
• [ ] Trust stores updated, including in container base images
• [ ] Client certificate expiry monitored, if using mutual TLS
• [ ] Certificate transparency monitoring for your domains

The summary

TLS verifies a signature chain, a name and a date. It does not verify that anyone is trustworthy.

Revocation is unreliable, and shorter certificate lifetimes are the industry's answer — so automation is not optional.

Missing intermediates explain most "works in the browser, fails in our client" reports.

Disabled verification is the most dangerous misconfiguration in this area, precisely because nothing about it looks wrong.