A change freeze does not freeze your certificates

A change freeze stops your own deploys. It does not stop your certificate authority, the CA/Browser Forum, your registrar, your CDN or the automation that renews your certificates. Those parties work on their own calendars, and some of their changes for this season are already dated.

This post is for teams that run their own TLS, DNS and origin and are planning a Black Friday or end-of-year freeze. For each thing that keeps moving, you get a primary source with a date, a check to run before the freeze starts, and what the failure looks like from outside.

Your certificates will renew during the freeze

Start with the arithmetic. Let’s Encrypt recommends renewing at about two thirds of the certificate lifetime, which for a 90-day certificate means roughly every 60 days. Clover, a payments platform, ran its 2025 code freeze from November 10, 2025 to January 4, 2026, which is 56 days. A job that fires every 60 days lands inside a 56-day window for most start dates, so most of your Let’s Encrypt certificates will renew at least once while the freeze is on.

Here is our own certificate, checked at the time of writing:

$ echo | openssl s_client -connect webpixie.io:443 -servername webpixie.io 2>/dev/null \
    | openssl x509 -noout -startdate -enddate
notBefore=Aug 14 07:41:32 2026 GMT
notAfter=Nov 12 07:41:31 2026 GMT

Renewing at two thirds puts the next certificate in mid-October and the one after it around mid-December. The second one falls inside almost any holiday freeze.

Pausing renewals is the wrong fix

The tempting response is to add certificate automation to the freeze. That trades a small risk for a certain one. A paused renewal still expires, and the expiry date does not care that it is Cyber Monday. A revocation (covered below) can also force a new certificate on a 24-hour deadline, and the freeze will not stop it.

The better approach is to verify every renewal path before the freeze starts, then watch the results from outside while it runs. Some items below have a good pre-freeze check. Some have none, and for those, detection is all you get.

What keeps changing while you are frozen

CA validation rules: the December 15, 2026 step

Section 3.2.2.9 of the CA/Browser Forum Baseline Requirements (version 2.3.1) phases in multi-perspective issuance corroboration. Each public CA must confirm your domain validation from several remote network locations before issuing. The next step lands in the middle of the holiday season:

Effective 2026-12-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives. The CA MUST ensure that the requirements defined in Quorum Requirements Table are satisfied, and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries.

The quorum table allows one non-corroborating perspective when a CA uses 2 to 5 remote perspectives, and two when it uses 6 or more. At five, if your firewall, geo-block or DNS rate limit stops two of them, issuance fails.

This has already happened once at a smaller scale. In February 2024 Let’s Encrypt announced it was adding two remote perspectives, moving to "1 from the primary datacenter and 4 from remote perspectives (previously 2)", and wrote "We expect little to no impact to users." Production switched on March 27, 2024. By April 19 the community forum had a post titled "Unexpected renewal failures since April 2024? Please read this!". The cause was firewalls that only allowed certain countries, while the new perspectives connected from Sweden and Singapore. The forum’s geoblocking FAQ says the validation locations "can and will continue to change", and the April post notes that Let’s Encrypt has consistently said it will not announce which IP addresses perform these checks.

From the client side, the failure names the secondary step. This is from a January 2026 forum thread:

Detail: During secondary validation: DNS problem: SERVFAIL looking up A for wiki.toud.pw - the domain's nameservers may be malfunctioning; DNS problem: query timed out looking up AAAA for wiki.toud.pw

In that thread, a volunteer suggested the poster’s DDoS protection was tripping on the burst of queries from several perspectives at once, and warned that "you may start running into it with other CAs as well in the future" as the minimum rises. The poster reported the error persisted with protection disabled, so the cause was never confirmed. The workaround that got a certificate issued was switching to the DNS-01 challenge.

Before the freeze: list every rule you added for peak traffic that touches /.well-known/acme-challenge/ or your authoritative DNS: country blocks, WAF rules, per-source rate limits. Then run a renewal against staging with the rules in place. certbot renew --dry-run does this; per the certbot documentation, "--dry-run uses the Let’s Encrypt staging server". In 2024 the new perspectives reached staging about two weeks before production, so staging is the earliest place a change like this may show up.

From outside: nothing breaks on the day. The old certificate keeps serving until it expires, which is why the expiry warning is the backstop.

Revocation deadlines

Section 4.9.1.1 of the same requirements sets the revocation clock. For a set of listed reasons, including evidence that domain validation "should not be relied upon", the CA "SHALL revoke a Certificate within 24 hours". For another set, including misissuance, it "SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days". There is no holiday exception.

DigiCert hit this in 2024. Its incident report (first published July 29, 2024) says a missing underscore prefix in some CNAME-based validations affected about 0.4% of applicable domain validations, and that "certificates with an issue in their domain validation must be revoked within 24 hours, without exception." Customers had to replace certificates by August 9, 2024, 20:30 UTC. That was summer. Nothing in the requirements would have moved the deadline if it had been the last week of November.

Before the freeze: write the exception into the freeze policy. Name who can reissue and deploy a certificate for each hostname within 24 hours, and test that path once now, including any manual install on a load balancer or appliance.

From outside: a revoked certificate is only visible to a check that queries OCSP or CRL. An expiry-only check will not see it.

Browser trust decisions

Root programs act on their own schedule. Google’s Entrust distrust announcement said Chrome 131 and later would stop trusting certificates chaining to listed Entrust roots whose earliest SCT is dated after November 11, 2024, 11:59:59 PM UTC, with blocking action beginning November 12, 2024. That was 17 days before Black Friday 2024. For an Entrust customer, an automated renewal that ran inside a freeze after that date would have produced a certificate Chrome 131 does not trust by default; Google said those users "will see a full page interstitial".

We have not found an equivalent root store action dated between November 2026 and January 2027 at the time of writing. Before the freeze: confirm which CA issued each certificate you serve (a certificate inventory from CT logs is the quickest way) and read your root programs’ announcements for those CAs.

Your registrar

ICANN’s Expired Registration Recovery Policy requires at least two reminders for gTLD domains, "approximately one month prior to expiration" and "approximately one week prior", which ICANN counts as compliant between 26 and 35 days and between 4 and 10 days before expiry. For a domain expiring on December 25, that puts the one-month reminder between November 20 and 29, around Black Friday, and the one-week reminder in the middle of the freeze. After expiry, the registrar must interrupt the existing DNS resolution path for a period before deletion. The notes published with the policy say that restoring it after a late renewal may be slow if "the post-expiration renewal occurred on a holiday or other non-business day."

Auto-renew does not settle this. The common failure is a card that expired or was declined, which our domain expiry monitoring guide covers in detail.

Before the freeze: list every domain that expires before the freeze ends plus 35 days, and renew those manually now. From outside: NXDOMAIN or a registrar parking page instead of your site.

Your CDN and cloud providers

Providers keep shipping changes during your peak, including urgent security work that does not wait for your calendar. Two recent examples from Cloudflare’s own postmortems:

• November 18, 2025, 11:20 to 17:06 UTC: a database permissions change made a Bot Management "feature file" double in size, past a limit in the proxy software. Ten days before Black Friday 2025 (Cloudflare postmortem).
• December 5, 2025, 08:47 to 09:12 UTC: during work to protect customers against the React vulnerability CVE-2025-55182, Cloudflare turned off an internal WAF testing tool through its global configuration system, which "does not perform gradual rollouts". The FL1 proxy returned HTTP 500s for traffic accounting for about 28% of all HTTP traffic Cloudflare served (Cloudflare postmortem).

Provider automation runs regardless of your calendar too. On December 7, 2021, AWS reported that "an automated activity to scale capacity" triggered a connection surge in us-east-1. Route 53 APIs were impaired from 7:30 AM to 2:30 PM PST, "preventing customers from making changes to their DNS entries", while existing records kept answering. If your emergency plan is a DNS change, check whether it depends on the same provider’s control plane.

Some vendors do freeze. Clover paused its APIs, SDKs and platform services for the whole 2025 window above, and still opened a November 22 to December 7 window for app updates covering "critical issues or security vulnerabilities". You cannot tell from your side which of your providers freeze and which do not.

Before the freeze: there is no check that prevents a provider incident. Decide the failover in advance and make sure it works without the provider’s API. From outside: 5xx responses generated by the CDN rather than your origin; the Cloudflare 5xx error code guide helps tell them apart.

Your own alerting

A warning that nobody reads is the oldest failure in this list. GitHub’s November 2020 availability report says the certificate for *.githubassets.com expired on November 2 for 32 minutes, and "There was an auto-generated issue indicating the certificate was within 30 days of expiration, but it was not addressed in time." PageKite’s December 2011 outage report blames a front-end certificate that expired a couple of days before the others, overlooked while "being somewhat distracted by the holidays".

Before the freeze: route expiry and renewal-failure alerts to the on-call rotation that will actually be staffed during the holidays, not to a shared inbox. If your client uses ACME Renewal Information, the CA suggests the renewal window, so plan for renewals on dates you did not choose.

The change that lands right after the freeze

On October 7, 2026, Let’s Encrypt announced 64-day certificates. The details:

• Staging switches to 64-day certificates on October 14, 2026.
• Production switches on February 10, 2027; Let’s Encrypt expects the last 90-day certificate to expire on May 11, 2027.
• Authorization reuse drops from 30 days to 10 days on the same date, per the earlier schedule.
• Clients that support ARI "should be all set".

Hardcoded schedules are the risk. Let’s Encrypt suggests searching for "common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks". As an illustration, a job that renews 60 days after issuance leaves only 4 days of margin on a 64-day certificate. This change lands about five weeks after a freeze that ends in early January, so the time to find those numbers is before the freeze, not in the first week back. The Let’s Encrypt rate limits post and our certificate expiration guide cover the wider lifetime schedule.

grep -rnwE '83|80|60' /etc/cron* /etc/systemd/system ~/bin 2>/dev/null | grep -iE 'cert|renew|acme'

What to watch from outside during the freeze

Most of the failures above are invisible from inside your deploy pipeline because nothing in it changed. An outside check sees the certificate, domain and response that visitors see. Here is how the items map:

WebPixie’s SSL monitoring validates the served certificate and chain daily, flags a revoked certificate as critical, and warns 15 days before expiry. Domain monitoring checks WHOIS or RDAP daily and warns from 30 days out. Neither stops a CA or a registrar from changing anything; they tell you while there is still time to act.

Freezes protect you from your own changes. Everything else needs checks before the freeze and someone watching during it, given the cost of downtime during sales season.