tls starters, one concept per page
Twenty-eight steps for people who ship HTTPS every day and have never looked underneath: the padlock's three promises, TLS as a handshake over a record layer, the one-round-trip TLS 1.3 handshake and why everything after ServerHello is encrypted, cipher suites as AEAD-only lists, forward secrecy from ephemeral keys, the chain of signatures up to a root your OS already trusts, SAN and the multiple names on one cert, Let's Encrypt's free Domain Validation certs and the ACME challenges that prove you own the domain, the ninety-day lifetime and the every-sixty-days renewal loop, wildcard DNS-01, certificate transparency, SNI, HSTS, and 0-RTT's replay trade, one concept per page.
A diagram, the classic trap, and one thing to go try this week. That's a page.
tls starters, one concept per page
Twenty-eight steps for people who ship HTTPS every day and have never looked underneath: the padlock's three promises, TLS as a handshake over a record layer, the one-round-trip TLS 1.3 handshake and why everything after ServerHello is encrypted, cipher suites as AEAD-only lists, forward secrecy from ephemeral keys, the chain of signatures up to a root your OS already trusts, SAN and the multiple names on one cert, Let's Encrypt's free Domain Validation certs and the ACME challenges that prove you own the domain, the ninety-day lifetime and the every-sixty-days renewal loop, wildcard DNS-01, certificate transparency, SNI, HSTS, and 0-RTT's replay trade, one concept per page.
Set in Space Grotesk, Inter and JetBrains Mono (SIL Open Font License).
TLS behaviour checked against RFC 8446 (TLS 1.3) and RFC 6797 (HSTS), and against the Let's Encrypt FAQ and Integration Guide at letsencrypt.org, all fetched and read during this build. Protocol facts, lifetimes and directives are named as those documents name them. Teaching conventions (one concept a page) are named as conventions. This book quotes no verbatim passages and is an independent guide not affiliated with or endorsed by the IETF, ISRG or Let's Encrypt.
General information only. Not professional advice; verify against your own TLS stack and the current documentation.
Your purchase is for personal use only. You do not have redistribution rights: please do not share, resell, or republish this book or its pages.
© 2026 Steve Hodgkiss. All rights reserved. Personal use only; no redistribution rights.
Edition 1.0 · stevehodgkiss.net
Contents
The primary goal of TLS is to provide a secure channel between two communicating peers. Specifically the secure channel should provide authentication, confidentiality and integrity, and these properties should hold even in the face of an attacker with complete control of the network. Per RFC 8446 section 1.
Three promises
Let's say someone tells you HTTPS is "encryption". That's one third of it.
TLS makes three promises. Authentication: the server is always proved, the client optionally. Confidentiality: only the endpoints see the data. Integrity: tampering is detected. And all three hold even against an attacker who controls the network, which is the bit people forget on café wifi.
Not "secure". Three specific promises, kept together.
Next time you see a padlock, name the three promises out loud. If you can't name them, the padlock was decoration.
The full TLS 1.3 handshake proceeds in three phases: key exchange establishes shared keying material and selects parameters, everything after this phase is encrypted; server parameters establish other handshake parameters; authentication authenticates the server and optionally the client and provides key confirmation and handshake integrity via the Finished MAC over the transcript. Per RFC 8446 section 2.
The handshake in one page
Let's say the handshake is a long list of messages. It's three moves with names.
Key exchange: trade halves, agree parameters; everything after is encrypted. Server parameters: the fine print, like whether the client must authenticate too. Authentication: certificate, signature over the transcript, and the Finished MAC that seals the whole conversation against tampering.
Agree, set, prove. One page, one trip.
Draw the three phases on paper from memory this week. If you can't, reread this page; everything else in the book hangs off it.
Certificate verification chains upward: the end-entity certificate is verified by checking its signature against the public key of the issuer's certificate, and this is repeated for each certificate up to the root, which is already trusted, being present in the operating system or browser trust store. Per standard X.509 path validation as used by TLS clients.
The chain of trust
Let's say the browser calls the issuer to check your cert. It never calls anyone; the trust is already installed.
Your cert is signed by an intermediate, itself signed by a root. The root sits in your OS trust store, shipped with it. Verification just walks the chain upward, checking signature after signature, and stops at a key it already believes. Miss the intermediate when you deploy and phones fail while your laptop works.
Trust isn't asked for. It's pre-installed, and the chain walks up to it.
In your browser's cert viewer this week, walk one real chain: leaf, intermediate, root. Note which root your OS shipped.
Let's Encrypt
Getting certs without buying them: a nonprofit CA that only does Domain Validation, proves by ACME challenge, lives with ninety-day certs on purpose, renews on a loop, and signs wildcards over DNS.
- 01The ACME challenge
- 02Ninety days
- 03The renewal loop
To issue a certificate, Let's Encrypt validates control of the domain from multiple network perspectives using the ACME protocol challenge types, including the http-01 challenge which requires serving a token under the well-known acme-challenge path on port 80, and the dns-01 challenge which requires creating a TXT record. Per the Let's Encrypt FAQ and Integration Guide.
The ACME challenge
Let's say the CA needs your company registration. It needs one of two proofs, both robotic.
http-01: serve a token at a fixed path on your site. dns-01: publish a TXT record. Either proves you control the domain, and validation runs from multiple network perspectives to resist spoofing. No human in the loop, which is exactly why it's free.
One file or one record. That's the whole identity check.
Look at your certbot renewal config this week and find which challenge type your certs use. Most people have never looked.
Let's Encrypt default certificates are valid for 90 days; there is no way to adjust these lifetimes and there are no exceptions. The recommended practice is renewing 90 day certificates every 60 days. Subscribers can opt in to short-lived certificates valid for six days, renewed every three days. Per the Let's Encrypt FAQ.
Ninety days
Let's say the short lifetime is a limitation. It's a design decision, and it's non-negotiable: no exceptions, no extensions.
Ninety days caps the blast radius of a bad issuance and forces automation. Renew at 60 days, a full month of slack. There's even an opt-in six-day cert, renewed every three. Shorter lifetimes are where the whole industry went, on purpose.
The expiry date is a feature. Automation is the price of it.
Check the expiry date on one of your certs this week and count the days. If it's over 90, it isn't Let's Encrypt.
Let's Encrypt asks that ACME clients perform routine renewals at random times to avoid spikes in traffic at set times of the day. Renewal failure should not be treated as fatal; graceful retry logic should use an exponential backoff pattern maxing out at once per day per certificate. Per the Let's Encrypt FAQ and Integration Guide.
The renewal loop
Let's say renewal is a cron line at midnight. Everyone's cron at midnight is the CA's traffic spike.
Renew at a randomised time, twice per lifetime. When a renewal fails, don't panic or hammer: back off 1 minute, 10 minutes, 100 minutes, then daily. A renewal that quietly stops retrying is how sites die on a Friday.
A loop with jitter and patience. That's the entire ops.
Check your certbot systemd timer's randomised delay this week. If it's zero, you're part of the spike.
HTTP Strict Transport Security is a mechanism enabling web sites to declare themselves accessible only via secure connections. The policy is declared via the Strict-Transport-Security HTTP response header field, with a max-age directive and an optional includeSubDomains directive; the user agent then refuses to interact with the host over plain HTTP for the given period. Per RFC 6797.
HSTS
Let's say the redirect to HTTPS is enough. The very first plain request is the hole.
HSTS is one response header, Strict-Transport-Security, that tells the browser to remember: this host is HTTPS only, for max-age seconds, optionally including subdomains. After that the browser won't even try plain HTTP, so the sslstrip-style first-hop attack has nothing to strip.
The redirect answers attacks. HSTS makes the question impossible.
Send a curl -I to three sites you use this week and grep for Strict-Transport-Security. Note who trusts you to remember.