Every HTTPS connection on the internet begins with a TLS handshake, and every TLS handshake presents a certificate. In 2026 the topic is deceptively simple on the outside — Let's Encrypt issues millions of free certs an hour, ACME clients renew everything automatically, and browsers show a padlock and move on. Under the hood, though, a lot of moving parts have to line up. This guide walks through what TLS certificates actually are, how the chain of trust works, why the industry is racing toward 90-day (and eventually shorter) lifetimes, and the deployment patterns that separate a robust HTTPS setup from one that breaks for 8% of your visitors on obscure devices.

What a certificate proves

A TLS certificate binds a public key to a set of identities — a Subject Alternative Name (SAN) list of hostnames, and, historically, an X.500 subject DN. When a browser connects to yourdomain.com, the server presents its certificate. The browser checks three things: (1) the hostname is in the cert's SAN list, (2) the cert is signed by a chain that reaches a trusted root, and (3) the cert is currently valid and not revoked. If any check fails, you get the red interstitial page users mostly ignore.

The cert does not prove who owns the business behind the hostname. That was the ambition of EV (Extended Validation) certs and green address bars a decade ago. Browsers have since concluded that users can't tell the difference and dropped the special UI, so DV (Domain Validation) is now the default for basically everything.

Chain of trust in one paragraph

Your certificate ("leaf") is signed by an intermediate CA. The intermediate is signed by a root CA that ships pre-installed in every browser and operating system trust store. The chain your server sends is the ordered path from leaf up through intermediates (but never the root — the root is already in the client's trust store). When a client validates, it walks the chain, verifies each signature, and checks that the top of the chain is a root it trusts. Every mainstream TLS server sends the intermediates automatically today, but historically the #1 cause of "works on Chrome, breaks on Safari" bugs was a server sending only the leaf and expecting the client to figure the intermediates out.

How you get a certificate

The modern path is ACME (Automatic Certificate Management Environment, RFC 8555). Roughly:

1. Your ACME client (Certbot, acme.sh, Caddy, cert-manager) generates a keypair.
2. It asks the CA (Let's Encrypt, ZeroSSL, Google Trust Services, Buypass) to issue a cert for the requested SANs.
3. The CA challenges you to prove control: either a specific file at http://yourdomain/.well-known/acme-challenge/... (HTTP-01), or a specific TXT record at _acme-challenge.yourdomain.com (DNS-01).
4. You publish the challenge, the CA verifies it, and issues the cert.
5. Ninety-ish days later, the client renews automatically.

DNS-01 is more flexible — it can prove control of a domain without opening any ports, and it's the only way to get wildcard certificates. HTTP-01 is simpler for a single hostname.

Why lifetimes are shrinking

In 2015 public certs could last five years. In 2020 the CA/Browser Forum capped it at 398 days. Since 2024 the practical maximum for a fresh Let's Encrypt cert is 90 days, and Google has publicly proposed dropping to 47. The reason is uncomfortable but correct: revocation doesn't really work on the modern web. If a private key leaks, revocation lists and OCSP are slow enough that a compromised cert stays useful to attackers for days. Short lifetimes are the pragmatic replacement — a leaked key becomes worthless quickly on its own.

Practically: if you're not on automated renewal in 2026, you are living on borrowed time. Set up ACME once and forget about renewals forever.

The pieces that people forget

• CAA records. A DNS TXT-ish record that lists which CAs are permitted to issue for your domain. example.com. IN CAA 0 issue "letsencrypt.org". All public CAs must check CAA before issuing. Publishing one blocks a large class of mis-issuance attacks. Use our CAA Lookup.
• HSTS. The Strict-Transport-Security response header tells browsers "always use HTTPS for this hostname, for N seconds." Eliminates the SSL-strip attack window entirely.
• HSTS Preload. Submit your domain to the Chromium preload list and browsers will refuse HTTP even on first visit. Nearly unremovable — only preload after you're sure every subdomain is HTTPS.
• Certificate Transparency. Every public cert issued is logged to append-only CT logs. You can (and should) monitor CT for unexpected issuance on your domains — free at crt.sh or our CT Search.
• OCSP stapling. Your server includes a fresh CA-signed "still valid" attestation in the TLS handshake so clients don't have to make a separate OCSP call. Reduces handshake latency and improves privacy.
• TLS versions. Disable TLS 1.0 and 1.1 (both have been deprecated for years). TLS 1.3 should be your default; TLS 1.2 stays enabled for compatibility.

Deployment patterns that don't break

• Terminate at a CDN. Cloudflare, Fastly, CloudFront all handle certificates for you, do OCSP stapling, and use hardware-secured keys. The simplest robust option for most sites.
• Caddy as your server. Automatic HTTPS with sane defaults. If your workload fits, Caddy solves 90% of TLS operations without any config beyond the hostname.
• cert-manager in Kubernetes. The standard operator pattern. Wildcard cert per environment, DNS-01 with your DNS provider's plugin, distributed across ingress controllers.
• Traditional web server + Certbot. Still works fine for a single-node setup. Set up a systemd timer to renew twice daily; Certbot only actually renews when the cert is close to expiry.

Testing your setup

Ship, then verify from outside. Our SSL Checker reports chain completeness, expiry, protocol versions, cipher order, HSTS, and OCSP stapling in a single view. Pair it with the Security Headers checker for the full HTTPS posture. If you want deep dives, SSL Labs' free scanner is still the gold standard for grading.

Related tools: SSL Checker · CAA Lookup · CT Log Search · Security Headers · HTTPS / SVCB Lookup