How TLS Certificates Work, and Why They Are About to Get Much Shorter

A TLS certificate is a small signed document. It says: this public key belongs to the operator of these hostnames, and we, a certificate authority, checked that on this date; believe it until this other date. That is all. It does not say the site is honest, safe, or well run. It binds a name to a key for a window of time.

When your browser connects to a site, the server presents its certificate. The browser checks four things: the name in the certificate matches the hostname you typed, today falls inside the validity window, the signature chains back to a root it already trusts, and the certificate has not been revoked. Then the two sides use the key to agree on encryption for the rest of the connection. The certificate is the identity step; everything after it is arithmetic.

No browser trusts your certificate directly. It trusts a short list of root certificates, shipped inside the browser or operating system by four root programs: Mozilla, Google Chrome, Apple, and Microsoft. Roots are kept offline and used rarely. Each root signs a handful of intermediate certificates, and the intermediates do the daily work of signing leaf certificates, the ones on actual servers.

This is why a certificate authority (CA) can be removed from the internet. When a CA misissues badly enough, the root programs distrust its root, and every certificate below it stops working in the next browser update. It has happened to large CAs more than once. The threat of distrust is the real enforcement mechanism behind every rule in this article.

Before signing, the CA has to prove you control the name. For the common domain-validated (DV) certificate, that proof is one of three automated challenges defined by the ACME protocol (RFC 8555):

• HTTP-01: put a specific file at a specific URL on port 80.
• DNS-01: publish a specific TXT record under _acme-challenge.yourdomain. The only challenge that can prove a wildcard.
• TLS-ALPN-01: answer a special TLS handshake on port 443.

The CA fetches the proof from several places on the internet at once, so that an attacker who can poison one network path cannot pass the check. It also reads your domain's CAA record, a DNS record that says which CAs may issue for the name. If your CAA record names Let's Encrypt and someone asks DigiCert for a certificate, DigiCert must refuse. You can check a CAA record with our DNS lookup.

Organisation-validated (OV) and extended-validation (EV) certificates add a human check of the company behind the domain. Browsers stopped showing any visual difference for them years ago; the padlock looks identical. For a website, they buy you nothing a visitor can see.

Since 2018 no browser will accept a certificate unless the CA has first published it to at least two independent, append-only public logs. This is Certificate Transparency (CT). The CA sends a precertificate to the logs, each log answers with a signed timestamp, and the CA embeds those timestamps in the final certificate. A certificate without them is simply rejected.

The logs are run by Google, Cloudflare, Let's Encrypt, DigiCert, Sectigo and a few others, and anyone may read them. A service called crt.sh, run by Sectigo, indexes all of them into one searchable database. That is the record dns.pizza/hands reads: every public certificate ever issued for a domain and its subdomains, with the day each was issued and the day it expires.

CT was built so that misissuance cannot hide. It has a side effect that matters here: the renewal habits of every domain on the internet are on the public record. A hostname whose certificates arrive every 60 days like clockwork is renewed by software. One whose certificates last 398 days, with a gap and a scramble at the end, is renewed by a person.

If a private key leaks, the certificate should be revoked. Two mechanisms exist. A CRL is a list of revoked serial numbers the browser would have to download. OCSP let the browser ask the CA live, but that told the CA which sites you visit, and if the CA was slow the browser just went ahead anyway. Chrome never checked OCSP for ordinary sites; Let's Encrypt switched its OCSP service off in 2025.

In practice, then, a leaked key stays usable until the certificate expires. Revocation does not protect you; expiry does. That single fact is why the whole industry is now shortening lifetimes.

The rules are set by the CA/Browser Forum, where the CAs and the four root programs vote. In April 2025 the Forum passed ballot SC-081, and every public CA is now bound to it. The maximum life of a certificate falls in three steps:

The third column is easy to miss and matters as much as the second. Today a CA may prove you control a domain once and reuse that proof for over a year. From 2029 the proof itself goes stale after ten days. Every renewal will need a fresh challenge, which means the automation has to be able to answer one at any time, not just have a valid certificate on file.

Why 47? It is one month at its longest (31 days), plus half of a 30-day month to allow renewal at the midpoint, plus one day of slack. The number was chosen so that a monthly rhythm still fits. Let's Encrypt already went further on its own: its default is 90 days, and in 2025 it began offering six-day certificates.

Nothing changes on one date. Certificates already issued keep their original expiry. The change arrives the next time each one is renewed: the new one is shorter, so the one after that comes sooner, and the one after that sooner still. A yearly chore becomes twice a year, then four times, then eight. With a ten-day validation window in 2029, it is no longer something a person can be relied on to do at all. Miss one, and the site shows a full-page browser warning to every visitor.

The rhythm in that picture is exactly what dns.pizza/hands reads. It looks at every certificate issued for a domain and its subdomains in the last two years and sorts each hostname into four buckets: renewed by software (short certificates on a steady beat), renewed by a person (long certificates, uneven gaps), unclear (too few issuances to tell), and lapsed (the newest certificate has already expired). No login, nothing to install; the record is public.

• Find the hostnames that still depend on a person. Run your domain through Hands. The lapsed and hand-renewed lists are the ones that will break first.
• Move them to ACME. Any modern web server, load balancer, or CDN can renew automatically; certbot, Caddy, Traefik, and every major cloud do it by default. Managed certificates at Cloudflare, Vercel, AWS or Google renew without you ever seeing them.
• Use DNS-01 where you can. It works for internal hosts, wildcards, and anything not on port 80. It needs an API token for your DNS provider, which is a good reason to keep DNS somewhere with a real API.
• Set a CAA record. Name the CA you use. It costs nothing and stops issuance from anyone else.
• Watch expiry from outside. Automation fails quietly. Our SSL checker reads what a visitor sees, and a monitor will tell you before the padlock does.

• A certificate binds a hostname to a key for a window of time, signed by a CA your browser already trusts through a root-to-intermediate-to-leaf chain.
• Issuance is an automated proof of control (HTTP, DNS, or TLS challenge), gated by your CAA record.
• Every issuance is published to Certificate Transparency logs. That is how we can read any domain's renewal habits.
• Revocation never worked, so expiry is the real safety net, and the industry is shortening it: 200 days in 2026, 100 in 2027, 47 in 2029, with only a ten-day validation window.
• Hand renewal stops being viable. See which of your hostnames still need a person at dns.pizza/hands.