Let’s Encrypt 64-Day Certificates: Renewal Automation Checklist for Windows Admins

The timeline​

Let's Encrypt's own announcement, dated October 7, 2026, sets out the schedule. Several outlets that covered it agree on the details.

• October 14, 2026: Let's Encrypt's staging environment starts issuing 64-day certificates so you can test.
• February 10, 2027: Issued and renewed certificates get a maximum validity of 64 days.
• May 11, 2027: The last 90-day certificate is expected to expire. Let's Encrypt says it does not intend to revoke valid certificates as part of the change.
• February 16, 2028: The default is planned to drop again, to 45 days.

The schedule also changes domain validation reuse. The reuse period for authorizations falls from 30 days to 10 days. In 2028 it is to be cut again, to 7 hours. Let's Encrypt says most operators need to do nothing about this unless their ACME client is built to rely on reused validation. It also says the change won't affect ACME endpoints, issuance chains or rate limits.

Why do this? Let's Encrypt says shorter lifetimes limit the damage from mis-issued certificates and compromised keys. They also push people toward automation. Its documentation notes that industry rules will cap certificate lifetimes at 47 days starting March 15, 2029. That is why its planned default lands at 45 days.

What actually breaks​

The certificates themselves are fine. The problem is renewal arithmetic that is hard-coded into scripts.

Let's Encrypt's guidance has two parts:

• If your client supports ACME Renewal Information (ARI), you should be all set. ARI lets the certificate authority tell your client when to renew.
• If your renewals are hard-coded to a number of days from expiry, change them to renew at about two-thirds of the lifetime. Let's Encrypt suggests searching cron jobs, wrapper scripts and runbooks for the numbers 83, 80 or 60.

The numbers show why this matters:

A four-day cushion is small if your DNS provider's API has a bad week. Treat 60-day-style schedules as bugs now, before 45-day certificates arrive.

A homelab test of three clients​

Rice-Jones checked how three clients in his lab decide when to renew, then tested each against the staging environment. These are his firsthand results. Let's Encrypt and the vendors have not independently confirmed them.

Caddy​

His Caddy container (version 2.11.4, per his account) already worked for him with no changes. He reports that Caddy renews at two-thirds of a certificate's lifetime and has supported ARI since version 2.8. Caddy's documentation confirms that Automatic HTTPS handles issuance and renewal. It also recommends pointing test configurations at a staging endpoint, because otherwise you are likely to hit rate limits. The version-specific claims come from the author, not from that documentation.

His first test failed to prove anything. A hostname under the same subdomain was already covered by his existing wildcard certificate. Caddy kept serving the wildcard and never contacted Let's Encrypt. Moving the test site to a name the wildcard doesn't cover produced a staging certificate issued October 25 and expiring December 28, which is 64 days.

If your staging test seems to succeed with no log activity, check whether an existing certificate already covers the name.

Proxmox VE​

Proxmox has a built-in ACME client. The author used the Cloudflare DNS plugin with a 30-second validation delay and the DNS-01 challenge, so no inbound port needed opening. The staging certificate also came back at 64 days.

Proxmox's administration guide says a certificate configured through the GUI or pvenode is renewed by pve-daily-update.service when it expires or is within 30 days of expiry. The author's reading is that the next renewal in late December still yields a 90-day production certificate. The one after that, in late February, should be his first 64-day production certificate.

The guide also warns that if you use custom directories with short-lived certificates, you may want to disable the random delay on pve-daily-update.timer. Otherwise a reboot could cause a missed renewal.

His one stumble was pasting an example email address into the account registration. Let's Encrypt rejected it with "contact email has forbidden domain".

Synology DSM with acme.sh​

The author says DSM's built-in Let's Encrypt option didn't offer DNS challenge support on DSM 7.3.2, going by an acme.sh guide for Synology. That is a configuration-specific finding. Synology documents DNS-01 support for its own DDNS service, which isn't the same as arbitrary DNS providers. So check your own DSM version and DNS provider before assuming either way.

His workaround was acme.sh with its Synology deploy hook. The acme.sh project README says it follows a CA's ARI suggested window when one is available. In his log, ARI suggested a window starting around day 42, later than his own pinned 30-day threshold. acme.sh kept the earlier date. That is the behavior to expect: ARI can pull a renewal earlier but not push it later than what you configured.

Two practical details from his run:

• DSM refused to run the installer from /tmp with "Permission denied", but passing the script to sh worked.
• The deploy hook reported "Success" but didn't make DSM use the new certificate, because he'd given it its own name. He selected it once by hand in DSM.

A renewal that succeeds in acme.sh but never reaches the service is a silent failure. Let's Encrypt's advice to automate reload and deployment applies here.

Gotchas that look like certificate problems​

Most of his lost time had nothing to do with certificates. These are worth knowing about on any network.

• Wrong DNS server. His new hostname resolved correctly against his internal Technitium DNS server. His Windows PC was getting answers from public name servers because the adapter pointed at the router. The router wasn't forwarding lab lookups. Fixing the adapter's DNS setting fixed it, and also explained several lab entries he had been keeping in his Windows hosts file.
• The padlock lies. The certificate viewer showed Caddy's wildcard because he was still using the old proxied address. Checking the NAS directly with OpenSSL showed Synology's self-signed certificate. Test the endpoint you actually use.
• Chrome remembers clicked-through warnings. After the right certificate was in place, Chrome still said the connection wasn't secure while also saying the certificate was valid. DevTools explained that he had recently allowed content loaded with certificate errors. Restarting the browser cleared it. This is one person's experience, not documented behavior for every Chrome build.

Monitoring is the part people skip​

Automation that fails quietly is how certificates expire. The author wrote a daily script that checks all three certificates. It posts to a Home Assistant webhook if one has under 14 days left, is still a staging certificate, or fails verification. His reasoning is that his clients renew with 21 to 35 days left on a 64-day certificate. Under 14 days therefore means at least a week of failed retries. The threshold is his own design, not a Let's Encrypt requirement. Let's Encrypt does recommend alerting for renewal failures.

Checklist for Windows and IT admins​

1. List every certificate consumer, not just the reverse proxy. That means NAS boxes, hypervisors, management consoles, internal web apps and appliances.
2. Search scripts, scheduled tasks, cron jobs and runbooks for 60, 80 and 83. Replace fixed offsets with about two-thirds of the lifetime, or use an ARI-capable client. Check your client's documentation to see whether it supports ARI.
3. Test against the staging environment now. Staging certificates are deliberately untrusted, so you are testing issuance and deployment, not browser trust. ACME accounts are separate per environment.
4. Confirm that a renewal triggers a deployment or service reload, then check the certificate the service actually presents.
5. Add expiry and verification alerts.
6. Check whether your provider is Let's Encrypt. Other certificate authorities set their own lifetimes within industry rules, so don't assume February 2027 applies to them.

Bottom line​

For clients that already follow ARI or renew at a fraction of the lifetime, the move to 64 days is mostly invisible. The risk sits in old scripts, deployment steps that never reload a service, and alerting that doesn't exist. This homelab run found that most of the pain came from DNS, caching and deployment rather than the certificates. With a 45-day default planned for 2028 and a 47-day industry cap in 2029, the sensible time to fix these is during the staging window.