Shorter SSL Lifetimes: Why Redirects Break First

SSL certificates expire. When they do, every HTTPS redirect on that domain stops working without warning.

You acquired three domains in 2022. Your registrar set up forwarding to your main site. HTTPS worked. You moved on.

Sometime in October 2026, the SSL certificates on those domains will expire. The forwarding will stop working for HTTPS visitors. They will see a browser security warning instead of a redirect. No one will notice until a customer asks why old-brand.com looks broken.

This is not a hypothetical. The maximum lifetime of a public SSL/TLS certificate dropped from 398 days to 200 days on March 15, 2026. It drops to 100 days in 2027 and 47 days by 2029. For websites, that is a renewal headache. For domain redirects, it is a quieter problem: the certificate you forgot about now expires twice as fast.

Key Takeaways

• The CA/Browser Forum approved a phased reduction of SSL/TLS certificate lifetimes, from 398 days to 47 days, with the final phase taking effect in March 2029.
• The first phase (200-day maximum) is already in effect since March 15, 2026. Certificates issued before that date keep their original validity.
• Every domain you redirect over HTTPS needs a valid certificate on the source domain. Shorter lifetimes mean the gap between "working fine" and "security warning" shrinks from over a year to six weeks.
• Let's Encrypt is separately reducing its default lifetime from 90 to 45 days, and now offers opt-in 6-day certificates for fully automated environments.
• Registrar domain forwarding typically does not support automated certificate renewal. If you redirect domains through your registrar, this is where things break first.

The Certificate Lifetime Timeline

In April 2025, the CA/Browser Forum approved Ballot SC-081v3. The ballot was proposed by Apple and endorsed by major browser vendors and certificate authorities including Google Chrome, Mozilla, and DigiCert. It sets a fixed schedule for reducing the maximum validity of publicly trusted SSL/TLS certificates:

March 15, 2026 (now in effect): Maximum certificate lifetime drops from 398 days to 200 days. Domain validation can be reused for up to 200 days.

March 15, 2027: Maximum lifetime drops to 100 days. Domain validation reuse shrinks to 100 days.

March 15, 2029: Maximum lifetime drops to 47 days. Domain validation reuse drops to just 10 days.

One important detail: certificates issued before a cutoff date keep their original validity. A 397-day certificate issued in February 2026 will still be valid until March 2027. The shorter lifetimes only apply to certificates issued after each phase takes effect.

The pace adds up. Here is what the renewal load looks like at different scales:

With automation, these numbers are invisible. Without it, each one is a potential outage.

Separately from the CA/Browser Forum timeline, Let's Encrypt announced in December 2025 that its default certificate lifetime will decrease from 90 to 45 days over the coming years. And as of January 2026, Let's Encrypt offers opt-in short-lived certificates that are valid for 160 hours, just over six days. These are designed for environments where every deployment includes a fresh certificate. They eliminate the need for revocation infrastructure entirely, because the certificate expires before revocation would typically take effect.

We manage certificates for thousands of redirect domains. The ones that break are never the ones people are watching. It is always the domain someone set up two years ago and forgot about. Shorter lifetimes do not change that pattern, they just shrink the window before it becomes a problem.

Michel Bardelmeijer, Tech Lead at redirect.pizza

The Forgotten Certificate Layer

When your main website's certificate approaches expiry, you get emails. Your hosting dashboard shows a warning. Your monitoring pings you. There are multiple layers of reminders between you and an outage.

Redirected domains have none of that. The source domain, the old URL that visitors type or that search engines have indexed, also needs a valid certificate because the browser completes a TLS handshake before the 301 redirect can execute. If that handshake fails, the redirect never fires. The 301 is still configured on the server or service. The browser just never gets far enough to receive it.

What the visitor sees instead: a full-page "Your connection is not private" warning in Chrome (or the equivalent in other browsers), with a red padlock and no obvious way forward. Most people close the tab. That is the moment where inbound links, referral traffic, and whatever SEO value the old domain carried stop working.

This is not a new requirement. But at 398-day certificate lifetimes, a forgotten redirect domain had a comfortable margin. You could set it up, walk away, and it would work for over a year. At 47 days, the same domain fails six weeks after its last certificate renewal. If you check quarterly, you are already too late.

For a detailed explanation of why HTTPS redirects require certificates on the source domain and how the TLS handshake interacts with redirect logic, see Why HTTPS Redirects Break (And How DNS-Level Fixes It).

Where Manual Renewal Actually Breaks

Not every redirect setup is equally vulnerable. Here is how the three common approaches compare:

Registrar domain forwarding is the most exposed setup. Most registrars offer a "forward this domain" option. Some support HTTPS forwarding. Very few support automated certificate renewal through ACME or any other protocol. When the certificate expires, HTTPS forwarding breaks silently. The registrar is unlikely to notify you, because forwarding is a checkbox feature to them, not a managed service. And since the domain is one you stopped actively thinking about, the expiry notification (if there is one) lands in an inbox no one reads.

Server-managed redirects with certbot or another ACME client handle renewal automatically. This is the most resilient self-hosted setup, as long as the automation keeps running. The standard certbot configuration renews when fewer than 30 days remain, regardless of the certificate's total lifetime. That buffer does not shrink with shorter certificates. What changes is the frequency: certbot goes from renewing every ~60 days (for a 90-day cert) to every ~17 days (for a 47-day cert). More cycles means more chances for a silent failure, like a server that rebooted and lost its cron job, a disk that filled up, or a DNS record that drifted after an infrastructure change. The automation works well when it works, but if it stops, you have less calendar time before the next expiry.

DNS-based redirect services handle certificate provisioning and renewal as part of the service infrastructure. Each source domain gets its own certificate, typically from Let's Encrypt or ZeroSSL, and renewal happens automatically regardless of certificate lifetime. The operational burden stays with the service, not with you.

For a broader comparison of DNS-level and server-based redirect approaches, see the complete guide to URL redirects.

Preparing Your Redirects for Shorter Certificate Lifetimes

If you redirect more than a handful of domains, the shift to shorter certificates is worth auditing before you find out the hard way. The goal is to know, for each domain you redirect, who is responsible for keeping the certificate alive.

Step 1: List every domain you redirect. This sounds obvious, but the domains most likely to break are the ones you forgot you had. Check your registrar accounts, DNS configurations, and server configs. Include apex domains, www variants, old brand names, campaign domains, and legacy acquisitions. If you merged companies or rebranded in the past five years, there are domains on this list you have not thought about since the migration.

Step 2: Note how each domain's certificate is managed. For each domain, record three things: who provisions the certificate (your registrar, your server, or a redirect service), whether renewal is automated, and when the current certificate expires.

To check a certificate's expiration date from the command line:

openssl s_client -connect old-domain.com:443 \
  -servername old-domain.com 2>/dev/null \
  | openssl x509 -noout -dates

You can also visit the domain in a browser and click the padlock icon for certificate details.

Step 3: Identify your highest-risk domains. Registrar-managed forwarding without automated renewal is the highest-risk category. If the domain carries inbound links, SEO value, or real user traffic, an expired certificate means that value evaporates behind a browser warning. Prioritize these for migration to an automated setup.

Step 4: Set up certificate expiry monitoring. Even with automation, monitoring is a safety net. Tools like Uptime Robot, Better Stack, and Oh Dear can track certificate expiry across multiple domains and alert you days before they become a problem. Think of it as a smoke detector: you hope it never goes off, but you would not skip installing one.

The 47-day deadline is still three years away. But the 200-day limit is already in effect, and 100-day certificates arrive in March 2027.

The first wave of 200-day certificates will start expiring in October 2026. That is when the domains nobody is watching will start breaking.

Frequently Asked Questions

Related Guides

• Why HTTPS Redirects Break (And How DNS-Level Fixes It)
• How to Redirect with HTTPS
• Domain Forwarding: What It Is, How It Works, and When to Use It
• Domain Redirects: When and How to Redirect an Entire Domain

Automate Your Redirect Certificates

redirect.pizza handles SSL certificates automatically for every domain you redirect, with built-in redundancy across Let's Encrypt and ZeroSSL. No manual renewals, no expiry surprises. Set up your first redirect in under 3 minutes.