Why Certificates Expire

SSL certificates don't last forever. They expire after a few months to a year, and this isn't a bug—it's one of the Internet's better security designs. The certificate that expires is doing you a favor: it's refusing to let yesterday's security assumptions protect today's traffic.

Why Expiration Exists

Imagine certificates that never expired. A private key stolen in 2015 would still be exploitable in 2025. A certificate issued with SHA-1 (now broken) would still be trusted. A domain that changed hands three owners ago would still have valid certificates floating around from the original owner.

Expiration prevents all of this. It creates a forcing function—a deadline that requires action.

When a certificate expires, several things must happen for renewal: someone must prove they still control the domain, the CA must issue a fresh certificate with current cryptographic standards, and the server must be configured with the new certificate. Each renewal is a checkpoint that validates the entire chain of trust.

If a private key is compromised, the damage is time-limited. The attacker can only use it until expiration. This matters because key compromise often goes undetected for months or years—the Heartbleed vulnerability existed for two years before discovery, and countless private keys were likely stolen during that window.

The Shrinking Window

Certificate lifetimes have steadily decreased:

• 1990s-2000s: Five years or longer
• 2011: Reduced to three years maximum
• 2017: Reduced to roughly two years (825 days)
• 2020: Reduced to 398 days (about 13 months)
• Today's discussion: 90 days or less

This isn't arbitrary tightening. Each reduction reflected hard-won lessons about security.

The 2020 change to 398 days happened when Apple announced Safari would reject longer certificates. The other browsers followed within months. One company's decision effectively set global policy—because when your certificates don't work in Safari, they don't work.

Let's Encrypt has issued 90-day certificates since 2015, proving that very short lifetimes work well when renewal is automated. Their success demonstrated that the "inconvenience" of short lifetimes was really an automation problem, not a security tradeoff.

Why Shorter Is Better

Shorter lifetimes compound security benefits:

Compromise becomes time-limited. A stolen key is valuable for weeks, not years. By the time an attacker figures out how to exploit it, the certificate may already be expired.

Cryptographic migration accelerates. When vulnerabilities are discovered in algorithms or protocols, shorter lifetimes mean faster ecosystem-wide updates. With 13-month certificates, everyone revisits their cryptographic choices at least annually.

Revocation matters less. Certificate revocation has always been unreliable—browsers don't consistently check revocation status due to performance and privacy concerns. With short-lived certificates, you can often just wait for expiration rather than relying on revocation mechanisms that may not work.

Operational hygiene improves. Organizations that renew certificates regularly maintain the knowledge, tooling, and processes to do it correctly. Organizations that renewed every five years often discovered, at the worst possible moment, that nobody remembered how.

The Automation Revolution

As lifetimes shrank, manual renewal became impractical. Renewing hundreds of certificates every 90 days by hand would be a full-time job—and humans doing repetitive tasks make mistakes.

This drove the development of ACME (Automatic Certificate Management Environment), the protocol Let's Encrypt pioneered. ACME allows complete automation of certificate issuance and renewal. Your servers obtain new certificates before old ones expire, automatically, without human intervention.

The industry made a collective decision: certificate renewal is too important to leave to humans. We automated it not because we're lazy, but because we're honest about our limitations. Automation doesn't forget, doesn't fat-finger commands, doesn't go on vacation the week before expiration.

With automation, certificate lifetime becomes invisible. You only notice if automation fails—which is exactly when you should notice.

What Expiration Looks Like

When a certificate expires, browsers display security warnings as severe as those for self-signed certificates or hostname mismatches. The connection is blocked. Users must explicitly bypass the warning to proceed.

An expired certificate tells the browser nothing useful. Is the site still legitimate? Is the private key still secure? Has domain ownership changed? The expiration might be mere oversight, or it might indicate an abandoned or compromised site. The browser can't tell the difference, so it assumes the worst.

Certificates contain two timestamps: "Not Before" and "Not After." Browsers check whether the current time falls within this window during every TLS handshake. This makes accurate system time critical—if your computer's clock is wrong, valid certificates may appear expired, or expired certificates may appear valid.

Renewal Is Really Replacement

Certificate "renewal" is somewhat misleading. You don't actually renew the same certificate—you get a completely new one.

Even if you reuse the same private key (which is discouraged), the certificate itself is a new file with a new serial number, new issuance date, and new expiration date. The CA signs it fresh.

This is why renewal requires validation. The CA must verify you still control the domain, just as they did for the original issuance. Renewal is proof-of-life for your domain ownership.

Best practice is to renew before expiration, creating an overlap period where both certificates are valid. Let's Encrypt recommends renewing at 30 days before expiration for their 90-day certificates. This gives ample time to detect and fix renewal failures before they become outages.

Where This Is Going

The trend toward shorter lifetimes continues. Standards bodies are seriously discussing 90-day maximums or less.

The logical endpoint: certificates as session tokens, obtained automatically at deployment time and rotated frequently. If certificates last days instead of months, key compromise becomes nearly meaningless—keys change before attackers can exploit them.

The counterarguments are practical: very short lifetimes increase renewal traffic, create more opportunities for automation failures, and may not work for all scenarios (embedded devices with limited connectivity, for instance).

But the direction is clear. Certificates will get shorter, not longer. Automation will become not just recommended but required. And the security of the Internet will improve, one forced renewal at a time.