Your change freeze can't outlast a 47-day certificate

Every change freeze policy I've read was written by someone who had never thought about certificates. That's not an insult. It's a date stamp. When a TLS certificate lived for 398 days, it renewed once a year, and you scheduled that renewal for whenever suited you. October, usually. Safely ahead of the retail code freeze and the hospital's go-live blackout, nowhere near quarter-end. Certificates never made it into the freeze policy because they never had to. An annual chore is easy to route around.

That trick stopped working in March 2026. It's going to stop working badly in March 2029.

The arithmetic nobody ran

Under SC-081v3, the CA/Browser Forum's maximum TLS certificate lifetime is already down to 200 days as of March 15, 2026. It drops to 100 days on March 15, 2027, and to 47 days on March 15, 2029, with domain validation reuse falling to 10 days at that final step. These aren't proposals. The ballot passed unanimously among CAs and browsers, and the first step has been live for months.

Now run the numbers against a freeze calendar.

At 398 days you get one issuance a year, and any freeze window can be dodged by renewing before it starts. That's why nobody wrote a policy.

At 200 days you get roughly two. A six-week freeze now has a real chance of swallowing a renewal, and a long retail freeze (November 1 through mid-January is common, call it 75 days) is more likely to contain one than not. This is the year that gets interesting, because the freeze season starting in a few months is the first one running entirely on 200-day certificates.

At 47 days, probability stops being the point. Ride a 47-day certificate to the last possible day and you get about eight issuances a year. But nobody rides to the last day, and no sane automation should. Let's Encrypt's ARI implementation, now standardized as RFC 9773, suggests a renewal window opening roughly two-thirds of the way through validity. On a 47-day cert that's around day 31. Renew on the recommended schedule and you're issuing eleven or twelve times a year, per certificate. Multiply by your inventory. If the answer is 400, you're looking at something like 4,500 issuances a year, and every one of them has to happen without a human in the loop.

Then overlay the freeze. A 75-day retail freeze is longer than the entire lifetime of a 47-day certificate. Not longer than the renewal margin. Longer than the certificate itself. There is no "renew everything the day before the freeze starts" strategy available, because the certificate you issue on October 31 is dead before Christmas.

A modest six-week freeze doesn't save you either. Forty-two days of freeze against 47 days of validity leaves five days of margin, and that assumes the pre-freeze renewal ran perfectly across every certificate, first try, no DNS propagation delay, no CAA lookup failure. Five days isn't margin. Five days is the slack that evaporates the moment the freeze gets extended because a Black Friday incident is still open.

Why pre-renewal doesn't save you

The instinct is to force everything to renew right before the freeze. Wrong instinct, and it breaks in two separate places.

The first is issuance. Certbot's force-renewal flag, and its equivalents in lego, acme.sh, and cert-manager, will happily cut a fresh certificate regardless of remaining lifetime, and every one of those counts against your CA's rate limits. Let's Encrypt caps duplicate certificates, meaning the same exact set of identifiers, at five per week, and caps certificates per registered domain at 50 per week by default. Sweep a few hundred certificates through a forced pre-freeze renewal and you'll burn the registered-domain limit on your busiest apex before you finish. What comes back is a flat rejection with a retry-after, not a queue. You'll find this out at 6pm on the Friday the freeze starts.

Forcing also fights ARI head-on. The whole point of the renewal info extension is that the CA tells your client when to renew. Clients that honor it (cert-manager, Caddy, recent certbot) spread renewals across the suggested window to avoid thundering herds and to give the CA a lever for emergency mass revocation. Override that with a calendar-driven stampede and you give up the coordination, spend rate limit budget, and still end up holding a certificate that expires mid-freeze. You've paid to move the outage a few days.

The second failure is the half people forget. Issuing a certificate is not deploying one. Say you do get fresh certs cut before the freeze. If the freeze blocks load balancer configuration changes, or the pipeline that pushes secrets, or the Terraform apply that updates the listener, or the config-management run that reloads nginx, the new certificate sits in a vault while the old one on the listener expires right on schedule. I've worked in environments where certificate issuance was fully automated and certificate distribution was a Jira ticket. That team was automated in exactly the half that doesn't page you.

One more trap, and it's the quiet one: some of your certificates already ignore your freeze entirely. AWS ACM renews managed certificates and re-associates them with CloudFront, ALB, and API Gateway without asking your CAB. Azure Key Vault does the same under an auto-rotation policy. Fine, right up until you notice that the freeze policy "protecting" your imported certs has no opinion whatsoever about the managed ones. Your inventory is split in two: things that renew during a freeze whether you like it or not, and things that quietly don't. Nobody wrote that split down. It just happened.

Rewrite the policy: freeze the tooling, not the rotation

The fix isn't technical. It's change management, and it has to be settled before the freeze starts, with the people who own the policy.

Get automated certificate renewal classified as a standard change. In ITIL terms that means pre-authorized: low risk, well understood, documented procedure, no per-instance CAB approval. Which is exactly what an ACME renewal is. The move that matters is making the automation the approved control rather than the individual renewal. You're not asking the CAB to approve 4,500 changes a year. You're asking them to approve one pipeline, once, with defined behavior, and to treat its output as pre-authorized. Renewal during a freeze becomes a non-event, the same way log rotation and OS patch pulls are non-events.

Then be specific about what stays frozen, because "certificates are exempt" is too broad and any CAB worth its name will reject it. Correctly. Lock these:

• CA changes. Switching issuers, adding a new ACME directory, rotating account keys. Different chain, different trust assumptions.
• Key algorithm or key size. Moving RSA to ECDSA, or changing curve. Old clients and old middleboxes have opinions about this, and December is a bad month to hear them.
• Chain and bundle reconfiguration. Which intermediates you serve, cross-sign selection, OCSP stapling. This is where the classic works-in-my-browser, fails-in-the-Java-client outage lives.
• New domains and new SANs. A new identifier means new validation, new CAA evaluation, real new risk.
• ACME client and automation upgrades. Certbot version bumps, cert-manager upgrades, changes to renewal thresholds. Freeze the tooling.

Rotation on the existing path, with the existing issuer and the existing key policy, is boring by design. Boring is what standard changes are for.

The pre-freeze checklist

Once the policy is right, the operational work is small, and all of it happens before the window opens.

Inventory what expires inside the window. Produce the list of every certificate whose expiry lands between the freeze start and the freeze end plus a week of buffer. Each one needs a verified automatic renewal path or a written exception. Sounds trivial. It's the hardest step by a mile, because the question spans AWS, Azure, GCP, whatever's baked into your appliances, and the cert on the vendor endpoint that someone's integration quietly depends on.

Verify the path end to end while people are still around. Not just whether the ACME client runs. Issuance, distribution, and service reload, all three observed, on at least one certificate per distinct renewal path. A dry run in the second week of November is cheap. The same discovery on December 27 is not.

Keep a break-glass path with a named owner. Manual issuance, documented, credentials that actually work, and a person on the on-call rotation who has done it at least once. "The team knows how" is not a procedure.

And do not turn off the monitoring. I've watched teams suppress certificate alerts going into a freeze because "we can't act on them anyway." A freeze is exactly when renewal failure goes unnoticed: fewer deploys means fewer accidental discoveries, and whoever would have caught it is on PTO. Silent renewal failure plus 47-day lifetimes is a four-week fuse.

That's the point where continuous inventory stops being a nice-to-have. "Which certificates expire between December 15 and January 8, across all three cloud accounts and the external endpoints" is a question no cloud console answers, because no cloud console knows about the other two. It's a large part of why I built CertPulse: one expiry view across ACM, Key Vault, GCP Certificate Manager, and whatever you're probing from outside, so the pre-freeze list takes ten minutes instead of a week of spreadsheet archaeology.

The freeze season starting this November is the last one where the old assumptions mostly hold. Next year's runs on 100-day certificates. Rewrite the policy now, while it's still a planning exercise and not an incident review.