← Blog

47-day certificates: what the CA/Browser Forum schedule actually changes

2026-07-20

この記事には日本語版があります: 日本語で読む →

Public TLS certificates are on a fixed schedule to become much shorter-lived. The maximum validity used to be 398 days; since March 2026 it’s 200, from March 2027 it drops to 100, and from March 2029 to 47. The decision was made in April 2025, when CA/Browser Forum ballot SC-081v3 — proposed by Apple and endorsed by Sectigo, Google Chrome, and Mozilla — passed with 25 certificate authorities in favor and none against.

The arithmetic is straightforward: a once-a-year renewal becomes roughly eight per year (365 ÷ 47 ≈ 7.8, and in practice you renew earlier than the deadline). Every renewal is a chance for something to fail quietly, so operational risk scales the same way.

The full schedule

It’s not only certificate validity that shrinks. Most summaries skip the second column:

Effective dateMax certificate validityDomain-validation reuse
Until March 14, 2026398 days398 days
From March 15, 2026 (in effect now)200 days200 days
From March 15, 2027100 days100 days
From March 15, 202947 days10 days

The second column has more impact than it might seem. When you prove control of a domain today, the CA can reuse that proof for later issuances. From March 2029 the proof is only reusable for 10 days, which means domain control gets re-verified at essentially every issuance. Manually placing a DNS record or uploading a challenge file every six weeks isn’t a workable process; validation itself has to be automated, not just renewal. (Identity information for OV certificates is on its own schedule, dropping from 825 to 398 days of reuse.)

Why the industry is doing this

Revocation is the official answer to a compromised key or a misissued certificate, and in practice it works poorly at browser scale — CRLs and OCSP checks are best-effort. A short lifetime is the blunt but reliable alternative: whatever goes wrong, it ages out quickly. Shorter certificates also let the ecosystem move faster on algorithm and policy changes. You don’t have to like the reasoning, but the vote was 25–0 among CAs and unanimous among browsers. This is happening on the dates above.

What breaks at each step

At 200 days, in effect now, an annual renewal schedule is already obsolete. Renewing twice a year by hand still works, but it doubles the exposure to the classic failures: notices going to someone who left, the one certificate outside the automation, a renewal that succeeded while the deployment silently didn’t.

At 100 days, from March 2027, renewal becomes a quarterly routine. Manual handling stops being an occasional event and becomes routine work, which is when mistakes start creeping in.

At 47 days with 10-day validation reuse, from March 2029, manual operation is effectively over. Anything that can’t renew itself (network appliances, load balancers with hand-installed certificates, the internal tool nobody has touched in years) turns into a scheduled outage unless it’s replaced or put behind something that automates renewal for it.

A migration checklist

  1. Inventory everything. Scan externally for every endpoint serving TLS (subdomains, mail servers, APIs), then add internal and embedded certificates. The surprises usually come from certificates nobody remembered existed
  2. Automate issuance. ACME wherever possible, platform-managed certificates (CDN, load balancer, PaaS) where it isn’t. For devices that can do neither, plan a replacement or put a terminating proxy in front of them
  3. Automate deployment too. Obtaining a certificate isn’t the same as serving it; reloads, distribution to instances, and CDN rotation need the same automation as issuance
  4. Monitor from outside the pipeline. A renewal job logging success tells you nothing about what’s actually served to users. Check externally, alert in stages, and deliver alerts to a team channel rather than a person
  5. Treat the milestones as engineering deadlines. March 2027 and March 2029 belong in the infrastructure roadmap, not in one person’s calendar

Where Certly fits

Certly covers the monitoring side: it checks the certificate your servers actually serve, from outside, and sends staged alerts at 30, 14, 7, and 1 days before expiry to email, Slack, Discord, or webhooks. The value of an independent check doesn’t change as lifetimes shrink — if anything, more renewals mean more moments where the pipeline can quietly fail. The free checker shows your current certificate’s remaining days without signup.

Sources