47-day cert lifetimes: what changes for your ACME automation

In 2024 the CA/Browser Forum voted on Ballot SC-081v3, sponsored by Apple and Google. The plan ramps cert lifetimes down on a schedule: 200 days in March 2026, 100 days in March 2027, 47 days in March 2029. By the end of the decade, every public cert will renew roughly every six weeks.

If you're already on Let's Encrypt or another ACME-automated CA, you've been renewing every 60-90 days for years. The change is mechanically minor for you. For everyone else, it's a structural rewire. Here's what to know.

Why the change

Long-lived certs are a revocation problem. When a key is compromised, the CA needs to revoke. CRLs and OCSP both have known reliability problems. Browsers have been pushing short-lived certs as the answer for a decade — at 47 days, the practical revocation window is short enough that "just wait for it to expire" beats most revocation mechanisms.

Apple proposed 7 days originally. They lost; 47 was the compromise. Many in the community expect another ramp toward 7-10 days within a decade.

What you need to fix

1. Renewal cadence

Your cron / systemd timer should run at least twice a day at 47-day lifetimes. Industry default for ACME clients (certbot, dehydrated, lego, acme.sh) is already 12-hour cadence. If you set yours to weekly to "save load", change it.

# /etc/systemd/system/certbot.timer
[Timer]
OnCalendar=*-*-* 03,15:00:00
RandomizedDelaySec=1h

2. Monitoring

Alert when a cert is < 14 days from expiry — that gives you a week to react if renewal fails (network issue, CA outage, rate limit). UnveilScan flags this as MEDIUM / INFO depending on remaining days. From scratch:

$ openssl x509 -enddate -noout -in /etc/letsencrypt/live/example.com/cert.pem
notAfter=Jun 27 12:00:00 2026 GMT

Pipe it into Prometheus / your monitoring of choice. Don't rely on the CA emailing you — Let's Encrypt stopped sending expiry warnings in 2025.

3. Reuse keys carefully (or don't)

certbot --reuse-key stops generating a new keypair on every renewal, reducing CT log noise. Trade-off: a key stolen six months ago still works on next month's cert. At 47-day lifetimes, the reuse-key savings are minimal; modern CAs handle the key churn fine. Default to fresh keys at every renewal.

4. CT log monitoring

At 8x/year cadence, your domain emits ~8x more rows in CT logs. If you watch crt.sh for "unauthorised cert issued for our domain" alerts, your existing dashboards may now show many more legitimate rows. Tag your own renewals so you can filter.

5. Multi-CA fallback

Adding a backup CA in your CAA + ACME setup. If Let's Encrypt has a multi-day outage (which has happened), you used to have months of cert validity to ride it out. At 47 days, you have weeks. A second CA pre-configured cuts the risk:

# CAA — both CAs allowed
example.com.  IN  CAA  0  issue  "letsencrypt.org"
example.com.  IN  CAA  0  issue  "pki.goog"

6. Pinning is fully dead

HTTP Public Key Pinning (HPKP) was already deprecated. At 47 days, pinning specific leaf certs is impossible. Pinning intermediate or root certs becomes the only option, and even those rotate. Most browsers no longer honour Public-Key-Pins at all. Don't even try.

The optimistic angle

Short-lived certs make many "we forgot to renew" outage classes mechanically impossible (at the cost of being more sensitive to any renewal pipeline failure). Once your automation is solid, certs become invisible — they just rotate. The ones who suffer are organisations using manual renewal processes, which is exactly the population the ballot was designed to push off the long-lived path.

The transition deadline is March 2029. Three years to fix your pipeline.