DEV Community: Alexander

The Hidden Cost of Expired SSL Certificates

Alexander — Sat, 11 Apr 2026 16:39:24 +0000

An expired certificate is not just a browser warning. It is a trust, revenue, and operations problem that usually appears at the worst possible moment.

That is why shorter certificate lifetimes matter so much. As the industry moves from 398 days to 200, then 100, then 47, weak certificate processes stop being an occasional annoyance and become a repeated business risk.

What the outage really costs

1. Lost trust

When users see "Your connection is not private," they do not think, "The ops team will fix this in ten minutes." They think the site is unsafe. Even a short incident can damage confidence more than a normal outage because the warning looks like a security failure.

2. Lost revenue

Certificate failures waste more than uptime. They waste demand.

If traffic is coming from ads, launches, email campaigns, or organic search, you are still paying to send users to a broken destination. A certificate incident can turn active acquisition spend into immediate loss.

3. SEO drag

Google has used HTTPS as a ranking signal for years. But the bigger SEO problem is usually indirect:

users bounce
important pages become unusable
crawlers may hit unstable availability
conversion data gets distorted during the incident

So the damage is not usually "Google punished us." It is "our site became less trustworthy and less usable."

4. Engineering time

A preventable certificate incident often pulls in multiple people across infra, DNS, networking, and app teams.

Someone has to find the owner, renew the certificate, deploy it correctly, verify the live endpoint, and explain what happened. A problem that should never have happened can easily burn hours of senior engineering time.

Why this keeps happening

The pattern is usually the same:

renewal exists, but deployment failed
reminders exist, but ownership is unclear
automation exists, but only for part of the lifecycle
monitoring did not detect that the live endpoint still served the old certificate

That is why expired certificates are not just a renewal problem. They are a lifecycle problem.

What teams should do instead

If you want to reduce the real cost of certificate failures, focus on three basics:

Automate the full path: validation, issuance, deployment, and verification.
Monitor the live endpoint independently so broken renewals are caught early.
Make ownership explicit for every public certificate.

That combination matters more than buying a bigger reminder system.

The business case gets stronger every year

At 398 days, teams can sometimes survive on habit and heroics.

At 200 days, those habits start breaking.

At 47 days, the same weak process becomes a recurring management problem.

How to Prepare for 47-Day SSL Certificates

Alexander — Sat, 11 Apr 2026 16:38:35 +0000

Forty-seven day certificates are not just "more renewals." They force teams to fix ownership, validation, deployment, and monitoring.

By March 15, 2029, public TLS certificates will max out at 47 days, and domain validation reuse will shrink to 10 days. Any process that still depends on personal reminders, manual DNS work, or ad hoc deployment will become fragile fast.

What breaks first

Most teams do not fail because issuing the certificate is impossible. They fail because one of the surrounding steps is weak:

nobody clearly owns the certificate
validation still depends on manual DNS or email
issuance is automated, but deployment is not
the live endpoint is never checked after renewal
one legacy system still uses a fully manual process

That is why preparation should focus on the full lifecycle, not just the CA portal.

A practical preparation plan

1. Build an inventory

For every public certificate, document:

hostname or service
deployment location
certificate type: DV, OV, or EV
renewal method
deployment method
owner

If you cannot answer those questions quickly, you are not ready for short lifetimes.

2. Classify every renewal path

Use three buckets:

fully automated
partially automated
fully manual

The goal is to remove as many manual paths as possible before 2029.

3. Automate validation

This is where many teams will struggle. When domain validation reuse drops to 10 days, slow human approval chains become dangerous.

In most environments, that means:

prefer DNS-based automation where possible
standardize on ACME where supported
keep DNS ownership clean and documented
reduce one-off certificate requests outside standard workflows

4. Automate deployment, not just issuance

"We already renew automatically" is not enough if the new certificate never reaches the live edge.

You want a full loop:

request or renew
validate
issue
deploy
reload safely
verify the live endpoint

If the process stops at step 3, it is not fully automated.

5. Add independent monitoring

Even good automation breaks. DNS records change, permissions expire, webhooks fail, and legacy systems get forgotten.

Monitoring should tell you two things:

which certificates are approaching expiry
whether the public endpoint is serving the expected certificate

That second check is the one teams often miss.

6. Handle awkward systems early

The real risk is usually not the clean modern stack. It is the old load balancer, vendor panel, customer-managed environment, or appliance that nobody wants to touch.

List those systems now and give them a migration or exception plan.

A short readiness checklist

Before the 47-day era arrives, make sure you can say yes to these:

every public certificate has an owner
renewal paths are documented
validation is automated where possible
deployment is automated for critical systems
alerts fire before expiry
live endpoints are verified after renewal
legacy exceptions are known and tracked

Use 200 days as a rehearsal

Do not wait for 2029. The 200-day and 100-day steps are rehearsal phases. They give you time to clean up bad habits before certificate management turns into a constant source of incidents.

SSL Certificate Validity Is Dropping to 200 Days in 2026

Alexander — Sat, 11 Apr 2026 16:36:51 +0000

The old "renew it once a year and forget it" model for public TLS certificates is going away.

On April 11, 2025, the CA/Browser Forum approved Ballot SC-081v3. The first deadline is March 15, 2026, when the maximum validity of publicly trusted TLS certificates drops from 398 days to 200 days. Then it drops again to 100 days in 2027 and 47 days in 2029.

The new timeline

Until March 15, 2026: maximum validity is 398 days
From March 15, 2026: 200 days
From March 15, 2027: 100 days
From March 15, 2029: 47 days

Domain validation reuse is shrinking too:

Until March 15, 2026: 398 days
From March 15, 2026: 200 days
From March 15, 2027: 100 days
From March 15, 2029: 10 days

This matters because the change affects both renewal frequency and how often certificate authorities can rely on older validation data.

Who pushed for this?

The proposal came from Apple and passed with support from the major browser vendors and most certificate authorities. That is a strong signal that this is a long-term ecosystem shift, not a temporary experiment.

Apple had already pushed the industry toward shorter lifetimes before, including the move to 398-day certificates in 2020. SC-081v3 continues the same direction: shorter trust windows, fresher validation data, and less reliance on slow manual certificate handling.

Why the industry is doing this

The logic behind the change is straightforward.

Certificate data gets stale

Certificates reflect a point in time. Over the course of a year, domains can change hands, teams can change ownership, and infrastructure can move.

Compromised keys should age out faster

If a private key is exposed, a shorter lifetime limits how long it remains useful. Revocation still matters, but shorter validity reduces the damage window.

Mis-issuance becomes less dangerous

When a certificate is issued based on outdated or incorrect information, shorter lifetimes reduce how long that mistake stays trusted.

Automation is no longer optional

The CA/B Forum is effectively telling the industry that certificate lifecycle management must become more automated, more observable, and easier to rotate.

What 200 days changes in practice

Two hundred days still sounds manageable, but it changes the rhythm of operations:

renewals move from an occasional task to a recurring process
weak spreadsheets and calendar reminders become riskier
legacy systems with manual deployment start standing out
failed automation hurts faster because recovery windows are shorter

For small teams, the problem is usually visibility. For larger teams, it is process drift: some certificates are automated, some are half-automated, and some still depend on one person remembering what to do.

What to do before March 2026

You do not need a huge PKI project. You do need a clean baseline.

Inventory every public certificate and assign an owner.
Split certificates into automated, partially automated, and manual.
Verify deployment, not just issuance.
Add alerts before expiry, such as 30, 14, 7, 3, and 1 day.
Flag systems that will struggle at 100 days and 47 days.

The key insight is this: 200 days is not the end state. It is the transition phase. If your process still depends on memory, tickets, and luck in 2026, it will be painful by 2029.