Field Guide · Networking
TLS encrypts and authenticates traffic in transit. Most "HTTPS is broken" reports are certificate or handshake problems, not encryption being "off." This guide is troubleshooting-oriented: what TLS does and does not give you, how the handshake and the chain of trust work, why a wrong SNI or a missing intermediate produces confusing errors — and the current version and certificate-lifetime rules, which are exactly the parts that change and must be verified rather than remembered.
Two facts do most of the work in this guide. First, TLS secures the channel, not the endpoints or the site behind them: a valid certificate proves you are talking to the name you asked for, not that the name is honest. Second, the version rules and the certificate-lifetime rules are moving targets — this guide states the current position and flags it as the kind of thing to re-check, because it will change again.
TLS provides three things: confidentiality (the session is encrypted against on-path observers), integrity (tampering with the ciphertext is detected), and server authentication (the client verifies the server's identity via its certificate and the chain of trust; optionally, mutual TLS also authenticates the client).
What it does not give you matters just as much. It does not prove the server is trustworthy — only that it presented a certificate your trust store accepts for that name. It does not protect data before it enters or after it leaves the tunnel, at the endpoints. And "TLS is enabled" is not a security posture: name the threat (eavesdropping, impersonation, downgrade) and the residual risk (a compromised endpoint, a mis-issued certificate, a weak legacy version still permitted). A phishing site can serve perfectly valid TLS — the padlock attests to the channel, not the intent.
At a high level: the client and server agree on parameters, the server proves its identity, and both derive session keys. The client sends a hello listing supported versions and cipher options plus the SNI (the hostname it wants); the server selects parameters and presents its certificate, ideally with the intermediate(s); keys are established using ephemeral key exchange (which gives forward secrecy); and both switch to encrypted application data.
This is the part to verify rather than memorise — the position below is current as of this writing and will move again. As of now:
| Version | Reference | Status |
|---|---|---|
| TLS 1.3 | RFC 8446 (2018) | Preferred. ~1 round-trip handshake; forward secrecy mandatory; AEAD-only cipher suites; legacy key exchanges and hashes removed. |
| TLS 1.2 | RFC 5246 (2008) | Current minimum / fallback for legacy clients. Still widely supported. |
| TLS 1.1 / 1.0 | RFC 8996 (2021) | Formally deprecated and moved to Historic; disabled in major browsers since 2020. |
| SSL 2.0 / 3.0 | — | Long dead; never enable. |
NIST SP 800-52r2 (2019) sets TLS 1.2 as the minimum for U.S. federal systems and required support for TLS 1.3 by 1 January 2024; PCI DSS and others likewise mandate 1.2-or-higher. Practical policy today is "TLS 1.3 preferred, 1.2 as fallback, 1.0/1.1 disabled." One forward-looking note: TLS 1.2 cannot carry post-quantum key exchange, so the move to 1.3 is also the prerequisite for post-quantum readiness. Confirm the version and cipher policy against current framework revisions before configuring — this table is a snapshot, not a standard.
A certificate is trusted not on its own but because it chains up to a root your system already trusts. The root CA lives in the client's trust store; it signs intermediate CAs; an intermediate signs the server's leaf certificate. The client rebuilds and verifies that chain on every connection.
One IP address commonly hosts many names, each with its own certificate. The client indicates which name it wants using SNI (Server Name Indication), sent early in the ClientHello, in the clear. The server uses it to select which certificate to present.
Most TLS errors map to a small set of causes. Read the exact error, then check the matching row:
| Symptom | Most likely cause |
|---|---|
| Expired / "not yet valid" | The certificate's dates — or the client's clock is wrong. Check NTP on both ends before assuming the cert is at fault. |
| Name mismatch | The SAN doesn't cover the hostname, or the client sent the wrong SNI (or none). |
| Unknown issuer / untrusted | A missing intermediate in the chain, or the root isn't in the client's trust store. |
| Works in a browser, fails in a script | Different trust stores — the OS/browser store vs a language runtime's own store — and browsers often fetch a missing intermediate that a bare client won't. |
| Handshake fails before any data | No common version or cipher suite between client and server (e.g. a client offering only TLS 1.0 to a 1.2+-only server). |
| Intermittent, behind a load balancer | One node with an expired, mismatched, or differently-configured certificate. |
| Pinning failure / unexpected issuer inside a network | A TLS-inspecting middlebox re-signing traffic with its own CA — expected on many corporate networks, a red flag anywhere else. |
Certificate lifetimes are shrinking sharply, and this is the single change most likely to bite operations. The CA/Browser Forum's Ballot SC-081v3 (April 2025) phases the maximum public TLS certificate lifetime down on a fixed schedule, enforced by browsers refusing over-long certificates:
| From | Max TLS cert lifetime | Domain-validation reuse |
|---|---|---|
| previously | 398 days | 398 days |
| 15 Mar 2026 | 200 days | 200 days |
| 15 Mar 2027 | 100 days | 100 days |
| 15 Mar 2029 | 47 days | 10 days |
The 200-day cap is already in effect. The operational consequence is direct: manual renewal does not survive this schedule, so automation is effectively mandatory — the ACME protocol (RFC 8555) is the standard mechanism, and short-lived, auto-rotated certificates become the norm. The rest of the practical checklist follows from the mechanics in this guide:
Serve the full chain (leaf + intermediates), or you'll hit "unknown issuer" on strict clients. Automate renewal and still monitor expiry independently — automation that silently fails is worse than a calendar reminder. Keep clocks synced (NTP): skew breaks validity checks and looks like an expired cert. Remember there are multiple trust stores (OS, browser, each language runtime) — "trusted" is per-store. Expect TLS-inspecting middleboxes on corporate networks. And treat version and cipher policy as changeable — re-check it, don't hard-code it into your mental model. Inspection commands (openssl s_client -connect host:443 -servername host, curl -v, openssl x509 -noout -dates -text) are on the Diagnostic Command Card.
Gives confidentiality, integrity, and server authentication (optionally mutual). Does not prove the site is honest, does not protect the endpoints. A valid cert attests to the channel and the name, not the intent.
ClientHello (versions, ciphers, SNI) → server cert + intermediates → ephemeral keys (forward secrecy) → encrypted data. Fail before data = version/cipher/cert; fail after = the application.
root (trust store) → intermediate → leaf. Validate: SAN matches host, chain complete (serve intermediates!), dates + revocation, chains to a trusted root. Versions: 1.3 preferred, 1.2 minimum, 1.0/1.1 dead (verify current policy).
Name mismatch → SNI/SAN. Unknown issuer → missing intermediate. Expired → check NTP first. Browser-ok-script-fails → trust stores. Lifetimes are shrinking (200 → 100 → 47 days) — automate with ACME.
The handshake, the chain of trust, SNI, and the validation checks are stable, standard behaviour. The version status and lifetime rules were verified this session and are the parts that move: TLS 1.3 is RFC 8446, TLS 1.2 is RFC 5246, and TLS 1.0/1.1 were deprecated to Historic by RFC 8996 (2021); NIST SP 800-52r2 sets 1.2 as the minimum and required 1.3 support by January 2024; CA/Browser Forum Ballot SC-081v3 phases the maximum certificate lifetime 398 → 200 → 100 → 47 days through 2029, with ACME (RFC 8555) the automation standard. Re-verify all of these against current sources before configuring — they will change again. No unqualified assurance is intended: TLS mitigates on-path interception, server impersonation, and downgrade, and leaves standing a compromised endpoint, a mis-issued certificate from a trusted CA, and any legacy version you still permit. Pairs directly with DNS (the name DNS resolves is the name TLS then validates), and builds alongside Subnetting & CIDR and IP Routing; sits beneath "Networking — Follow the Packet"; commands are on the Diagnostic Command Card. Terms are in the Glossary; 00 · Start Here indexes the set.