TLS, HTTPS, and Why Certificates Expire

Every so often, a perfectly healthy website greets its visitors with a full-screen browser warning — 'Your connection is not private' — because a certificate quietly expired over the weekend. It happens to tiny blogs, and it happens to companies with entire teams whose job is preventing it. The mechanics behind that warning are worth understanding, because they explain not just how to avoid the incident, but what that padlock in the address bar has been promising your visitors all along — and what it hasn't.

What HTTPS actually promises

HTTPS is ordinary HTTP wrapped in TLS (Transport Layer Security — the successor to SSL, whose name survives mainly in marketing copy and product pages). TLS makes three distinct promises about the connection between a visitor's browser and your server:

  • Encryption: nobody positioned between the browser and the server — the coffee-shop Wi-Fi, the ISP, anyone on the network path — can read the traffic. Passwords, form contents, session cookies all travel opaque.
  • Integrity: nobody can modify the traffic in transit. Without this, a network middleman can inject ads, rewrite download links, or alter prices. This promise is underrated; historically, traffic injection by shady networks was a real business model.
  • Authentication: the browser can verify it's talking to the actual example.com, not an impostor answering on its behalf. This is the promise certificates exist to make, and the one the rest of this post is about.

Worth stating what HTTPS does not promise: that the site is trustworthy, safe, or honest. A phishing site with a valid certificate gets the same padlock you do — the padlock means 'your conversation with this site is private,' not 'this site is good.' Browsers de-emphasized the padlock icon in recent years partly because users over-read it.

How a certificate proves anything

Encryption without identity is useless — an encrypted conversation with an attacker is still a conversation with an attacker. So before any encryption starts, the server presents a certificate: a signed statement saying 'the holder of this cryptographic key is authorized for the name example.com.'

The signature comes from a Certificate Authority (CA) — Let's Encrypt, DigiCert, Sectigo, a handful of others. Your browser and operating system ship with a short list of CAs they trust; a certificate signed (via a chain of intermediates) by one of those roots is accepted. The whole system rests on a simple procedure: before signing, the CA makes you prove you control the domain. For most certificates today that's an automated challenge — place this token at a specific URL on your site, or publish this DNS record — completed in seconds. Control the domain, get the certificate. It's identity verification at the only level the web can check mechanically.

Two practical notes that follow from this design. First, since domain-validated certificates from Let's Encrypt cost nothing and automate cleanly, paying for a basic TLS certificate today mostly buys you a logo and a manual renewal chore — the encryption is identical. (Extended-validation certificates, which once turned the address bar green with a company name, lost that UI years ago; their practical value today is close to nil for a typical site.) Second, the trust chain explains a whole category of confusing errors: a server that sends its own certificate but not the intermediate produces the maddening 'works in Chrome, fails in some Android app' pattern, because some clients fetch missing intermediates and some don't. If your certificate is valid but odd clients reject it, check the chain — the SSL Labs server test diagnoses this in one run.

Why certificates expire on purpose

Expiry feels like a subscription-renewal racket, but it's a deliberate security mechanism — arguably three mechanisms:

  1. Limiting the damage of stolen keys. If a server's private key leaks — a compromised server, an exposed backup, a departing contractor's laptop — anyone holding it can impersonate the site for as long as the certificate remains valid. Revocation, the official remedy, works poorly in practice: browsers check revocation status inconsistently or not at all, a known weakness of the whole system. Expiry is the backstop that actually functions. Shorter lifetime, shorter maximum impersonation window.
  2. Keeping facts fresh. A certificate asserts 'this key holder controls this domain' — a fact that was verified once, on issuance day. Domains change hands, companies dissolve, hosting migrates. Expiry forces periodic re-verification, so the assertion never drifts too far from reality.
  3. Keeping the ecosystem upgradable. When the industry deprecates a weak algorithm or tightens rules, short-lived certificates mean the old ones age out in months rather than lingering for a decade.

This logic is why lifetimes keep shrinking: from multi-year certificates a decade ago, to roughly 13 months as today's maximum for publicly trusted certificates, with Let's Encrypt issuing 90-day certificates as standard and the industry on an announced path toward substantially shorter still. Read the direction of travel: lifetimes are heading toward 'too short to renew by hand.' That's intentional. The endgame is a world where renewal is automated everywhere and expiry incidents are extinct. The transition period — now — is where the incidents live.

Anatomy of an expiry incident

How does a certificate expire on a site whose owner cares? The failure modes are surprisingly consistent:

  • The renewal reminder went to a dead mailbox. The certificate was bought by a contractor long ago; the reminder email goes to their address, or to an inbox nobody reads. The classic for manually purchased certificates.
  • Automation existed and silently broke. A renewal cron job died in a server migration; the ACME challenge path got blocked by a new firewall rule, a redirect-all-HTTP rule, or a CDN configuration; a DNS API token used for challenges expired (a certificate renewal failing because a different credential expired — the incident-report writers' favorite).
  • The forgotten hostname. The main site renews fine; the certificate on mail.example.com, the staging subdomain, or the old API endpoint expires — discovered by whichever integration breaks first.
  • The renewal happened, the reload didn't. The new certificate sits on disk while the web server keeps serving the old one from memory, because nothing told it to reload. Expiry occurs with a valid replacement three feet away.

Note the pattern: almost none of these are 'nobody set anything up.' They're 'the setup rotted and nothing was watching.' Which dictates the fix.

Making expiry a non-event

The goal state: certificates renew, get deployed, and get verified with no human in the loop — and a human gets loudly notified only when that fails. Four layers, in priority order:

  1. Let the platform own it if it can. Managed hosting, and CDN/proxy layers like Cloudflare or a load balancer with managed certificates, handle issuance and renewal as a platform feature. If you're on such a platform, your whole job is layer four (monitoring) plus knowing which hostnames the platform does not cover.
  2. Otherwise, automate with ACME. The ACME protocol (what Let's Encrypt speaks) is supported by every serious web server and by tools like certbot; modern servers such as Caddy renew certificates natively with zero configuration. Ensure the renewal hook reloads the web server — that's the step ad-hoc setups forget.
  3. Prefer DNS challenges for anything non-standard. Wildcards, internal hosts, servers behind strict firewalls — DNS-based validation sidesteps the 'challenge path got blocked' failure family. It requires an API credential for your DNS provider, which then becomes a credential you must also keep alive; note it somewhere findable.
  4. Monitor from the outside. The non-negotiable layer, because it catches every failure mode above regardless of cause. An external check that alerts when any of your hostnames' certificates has, say, under 14 days remaining — via an uptime service with TLS checks, or any of the free certificate-expiry monitors. Fourteen days is enough time to fix broken automation calmly. Monitor every hostname that serves TLS, not just www: mail, api, staging, the lot. Bonus: Certificate Transparency logs (searchable via crt.sh) list every certificate ever publicly issued for your domain — a five-minute audit that reliably surfaces forgotten subdomains.

Loose ends that bite: redirects and mixed content

Two adjacent issues round out site-owner TLS literacy. First, serve exactly one canonical origin. All HTTP traffic should redirect permanently to HTTPS, and you should pick one host (www or bare domain) as canonical — for both security and SEO deduplication. Adding an HSTS header tells browsers to skip the insecure hop entirely on return visits, closing the small window where a downgrade attack could live; enable it once your HTTPS setup is stable (and treat the preload variant with respect — it's effectively irreversible on the scale of months).

Second, mixed content — an HTTPS page loading images or scripts over plain HTTP — is the usual aftermath of an old migration: hardcoded http:// URLs in content, themes, or a database that was never search-and-replaced. Browsers block the dangerous cases and mark the rest, costing you the padlock. The fix is mechanical (find the http:// references; on WordPress, a proper search-replace tool that handles serialized data), and a Content-Security-Policy of upgrade-insecure-requests papers over stragglers while you clean up.

The short version

TLS gives your visitors privacy, integrity, and proof they're talking to you; certificates are the identity layer, and they expire on purpose, because expiry is the only revocation mechanism that reliably works. The industry is driving lifetimes down until manual renewal becomes impossible, so get ahead of it: put issuance on a platform or ACME automation, make sure renewals actually reload the server, and — the one habit that covers every failure mode — monitor expiry from the outside on every hostname you own. Do that, and the full-screen browser warning becomes something that only ever happens to other people's weekends.

Photo: Leeloo The First on Pexels