Let's Encrypt 64-day certs: your Azure renewal audit

On 7 October 2026 Let's Encrypt announced the first reduction of its default certificate lifetime in the project's history: from 90 days to 64 days, effective 10 February 2027. The staging environment switches to 64-day issuance on 14 October 2026, which is this Wednesday. The announcement is short and the headline number looks harmless. The parts that bite are further down: domain authorization reuse drops from 30 days to 10 days on the same date, and the default drops again to 45 days with a seven-hour reuse window on 16 February 2028. If your Azure estate has a certbot cron on a VM, a cert-manager Issuer on AKS, or a Key Vault pipeline feeding Front Door and Application Gateway, you have hardcoded numbers somewhere that assume 90 days. This is the week to find them, because staging lets you test the real behaviour four months before production changes.

What changes, and on which dates

Let's Encrypt is stepping down in two moves rather than jumping straight to the 47-day maximum the CA/Browser Forum has mandated for March 2029. The 64-day step is deliberate: it is long enough that a fixed 60-day renewal schedule still works, which gives operators one more cycle to fix their automation before the 45-day step makes such schedules fail outright.

Two things do not change. Rate limits are unaffected, and the ACME endpoints and issuance chains stay the same. Subscribers who want shorter lifetimes earlier can already opt into the 45-day tlsserver profile (available since 13 May 2026) or the six-day shortlived profile. Nobody is forced to move early; everybody is moved on 10 February 2027.

"We use Azure-managed certificates, so this does not affect us"

Partly true, and worth separating. App Service managed certificates and Front Door managed certificates are issued by DigiCert, not Let's Encrypt, and Microsoft renews them for you. The 10 February 2027 date does nothing to those. Four places in a typical Azure estate do run Let's Encrypt, often without the platform team knowing:

• cert-manager on AKS. The default ClusterIssuer in most Helm charts and tutorials points at Let's Encrypt.
• certbot, acme.sh or win-acme on virtual machines. Usually installed years ago by whoever stood the box up, with a cron or scheduled task nobody has read since.
• Caddy and Traefik in Container Apps, VM scale sets or on-premises edge boxes, where automatic HTTPS defaults to Let's Encrypt.
• Key Vault Acmebot, the widely used open-source Azure Functions app that requests ACME certificates into Key Vault and binds them to App Service, Container Apps, Front Door, Application Gateway v2 and API Management.

The managed certificates are not exempt from the broader trend either. SC-081 binds every publicly trusted CA, including DigiCert. Microsoft's managed certificates will be at most 100 days long from March 2027 and 47 days from March 2029, and some of the renewal mechanics described below will have to change to keep up. The Let's Encrypt date is simply the first one on your calendar.

The two numbers that break

Fixed renewal schedules

Let's Encrypt's own guidance is to renew at roughly two thirds of the certificate's lifetime and to search your automation for the literals 83, 80 and 60 "in cron jobs, wrapper scripts and runbooks". A 60-day fixed schedule survives the 64-day step with four days to spare. It fails on the 45-day step. A "renew 30 days before expiry" rule, which was the certbot default until version 4.0.0, becomes "renew on day 15" at 45 days, and a renewal loop at six days. Relative rules do not have this problem:

The margin column is the operationally interesting one. Thirty days of slack today absorbs a broken DNS record, an expired API token or a two-week holiday. Fifteen days does not absorb a two-week holiday. Any renewal failure that currently gets noticed "eventually" needs an alert by 2028.

Authorization reuse

This one is less discussed and more dangerous. Today, once Let's Encrypt has validated that you control a domain, it reuses that authorization for 30 days. From 10 February 2027 that window is 10 days; from February 2028 it is seven hours. In practice this means every renewal will perform a fresh challenge. Setups that only work because the validation was cached stop working: a DNS-01 TXT record that someone created by hand once, an HTTP-01 path that is blocked by a WAF rule added after the first issuance, or a wildcard issued from a laptop and then copied into Key Vault. Every challenge path must be automated and must succeed every single time.

Azure audit, surface by surface

Virtual machines running certbot

Certbot changed its renewal logic in version 4.0.0: a certificate is now due when less than a third of its lifetime remains, instead of the old fixed 30 days. Version 4.1.0 added ACME Renewal Information (ARI, RFC 9773), which lets Let's Encrypt tell the client when to renew, including early renewal during a mass revocation. The distribution packages on older Ubuntu and Debian images are frequently behind both of those. Run certbot --version on every VM, and if the answer starts with 1, 2 or 3, move to the snap or pip install. Keep the twice-daily cron the documentation recommends; renew only acts when a certificate is due, so running it often is free.

Then read the wrapper scripts. Anything that computes "days until expiry" with openssl and compares to a literal is a fixed rule. Replace the literal with a percentage of the actual notAfter minus notBefore.

AKS with cert-manager

cert-manager's default is already relative: it renews at two thirds of the issued certificate's duration. The problem is the Certificate resources where someone set renewBefore: 720h (30 days) because a blog post said so. On a 64-day certificate that renews on day 34, which works. On a 45-day certificate it renews on day 15 and doubles your issuance volume. cert-manager's documentation warns that a renewBefore close to the duration causes a renewal loop, which is exactly what a 720h value does to a six-day shortlived certificate. Use renewBeforePercentage instead, or delete the field and accept the default. ARI arrived in cert-manager 1.21 as experimental support behind the ACMEUseARI feature gate; enable it in a non-production cluster first.

# Find absolute renewBefore values across the cluster
kubectl get certificates -A -o json \
  | jq -r '.items[] | select(.spec.renewBefore != null)
      | "\(.metadata.namespace)/\(.metadata.name) renewBefore=\(.spec.renewBefore)"'

# Prefer a relative rule
spec:
  renewBeforePercentage: 33   # renew when a third of the lifetime remains

Key Vault pipelines feeding Front Door, Application Gateway and App Service

This is the most common Azure pattern for Let's Encrypt and the one with the most moving parts. The certificate is requested into Key Vault, often by Key Vault Acmebot, and three downstream services pick up new versions on their own schedules. Microsoft documents those schedules: Front Door takes up to 72 hours to deploy a new version when the secret version is set to Latest, Application Gateway v2 polls Key Vault every four hours, and App Service syncs an imported Key Vault certificate within 24 hours.

Put those delays against the margin table. A 64-day certificate renewed on day 43 leaves 21 days, so a 72-hour Front Door pickup is comfortable. A 45-day certificate renewed on day 30 leaves 15 days, still comfortable. A six-day shortlived certificate leaves two or three days, and Front Door may take three of them. Do not use the shortlived profile for anything behind Front Door, and treat the 45-day step as the point at which a failed Acmebot run must page someone the same day. Acmebot itself already schedules renewals using ARI windows with an expiry-based fallback, so the tool is ready; the pager rule probably is not.

Two configuration details decide whether rotation is automatic at all. For Front Door, the custom domain's secret must reference version Latest; a pinned version means a human reselects it every renewal, which at 45 days is eight times a year per domain. For Application Gateway, use a versionless secret identifier (the URI without the trailing version segment); the documentation says so in bold and most Terraform modules written before 2024 get it wrong.

Azure-managed certificates and the 2029 problem

Front Door auto-rotates managed certificates only when the custom domain's CNAME points directly at the Front Door endpoint. If it points through a chain, uses an A record, or is an apex domain with CNAME flattening, the domain enters "Pending revalidation" 45 days before expiry and waits for you to create a new TXT record. That design assumes certificates live much longer than 45 days. When the maximum is 47 days in March 2029, "45 days before expiry" is two days after issuance, and Microsoft will have to redesign the flow. You cannot control that redesign. You can control which of your domains depend on it: list every Front Door custom domain whose CNAME does not resolve directly to the endpoint and fix the DNS now, while the consequence of a missed revalidation is still a 45-day warning rather than a two-day one.

Key Vault's own integrated CAs (DigiCert and GlobalSign) are on the same SC-081 clock, and today a Key Vault certificate policy expresses validity in whole months. Expect that to change before 2029; do not build new automation on the assumption that "validityInMonths: 12" will keep issuing.

Monitoring thresholds are hardcoded too

Application Insights standard availability tests include an SSL certificate validity check and a "proactive lifetime check" that fails the test a configurable number of days before expiry. If that number is 30, the test will be permanently red on a 45-day certificate renewed at day 30, and your team will learn to ignore it. Set the proactive check to something that fits the new cadence (seven days works for 45-day certificates renewed at two thirds) and alert on the renewal job's own failure rather than on the certificate's age. The same applies to Key Vault certificate contact notifications and to any Azure Monitor log alert that counts days to expiry: a threshold of 30 was a sensible fraction of 90 and is a nonsense fraction of 45.

Test against staging this week

From 14 October the Let's Encrypt staging environment issues 64-day certificates. Staging certificates are not browser-trusted, so run the test on a non-production hostname and look at the issued lifetime and the renewal time your tooling computes from it.

# certbot: request against staging and inspect the lifetime
certbot certonly --staging --dns-azure -d test.example.se
openssl x509 -in /etc/letsencrypt/live/test.example.se/cert.pem -noout -dates

# cert-manager: a staging ClusterIssuer alongside production
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: platform@example.se
    privateKeySecretRef:
      name: letsencrypt-staging-key
    solvers:
      - dns01:
          azureDNS:
            subscriptionID: 00000000-0000-0000-0000-000000000000
            resourceGroupName: rg-dns
            hostedZoneName: example.se
            managedIdentity:
              clientID: 00000000-0000-0000-0000-000000000000

Then check what your tooling does with a 64-day certificate: when cert-manager schedules the renewal (the Certificate status shows renewalTime), whether certbot's renewal configuration computes a sensible date, and whether any wrapper script or dashboard assumes 90. Repeat the exercise against the 45-day tlsserver profile, which production already issues on opt-in, to see the 2028 behaviour today.

The Swedish and EU angle

An expired certificate is an availability incident, and for a growing share of Swedish organisations that now has a legal dimension. The new cybersäkerhetslagen, Sweden's implementation of NIS2, entered into force on 15 January 2026 and extends incident reporting and risk management duties across 18 sectors. A public-facing service that went dark because a renewal silently failed is a weak story to tell a supervisory authority, and the shorter the certificate, the more often the renewal has to succeed. Treating certificate renewal as a monitored production job rather than a background chore is the practical response.

The Swedish government's cloud policy for public administration, published in May 2026, asks agencies and municipalities to prefer solutions built on open standards with a documented exit plan. ACME is a good fit for that requirement. The same cert-manager Issuer or Acmebot configuration can point at Let's Encrypt, Google Trust Services, ZeroSSL or a European CA that implements ACME, and the ARI extension is a standard, not a vendor feature. Managed certificates from a single cloud provider are easier today and harder to leave. Neither is wrong, but the exit plan should say which one you chose and why.

Finally, European CAs are not a way around any of this. SC-081 was adopted by the CA/Browser Forum in April 2025 and applies to every CA trusted by Chrome, Safari, Firefox and Edge, wherever it is headquartered. The 100-day and 47-day ceilings arrive on the same dates for everyone.

Checklist

• 1. Inventory. Query Azure Resource Graph for Key Vault certificates, Front Door custom domains, Application Gateway listeners and App Service bindings, then add every VM and AKS cluster that runs an ACME client. Record the issuer for each.
• 2. Grep for literals. Search runbooks, cron files, Terraform and Helm values for 83, 80, 60, 30 and 720h in a certificate context. Each one becomes a relative rule.
• 3. Upgrade clients. certbot 4.1.0 or newer, cert-manager 1.21 or newer, current Acmebot. Enable ARI where it is behind a flag, in non-production first.
• 4. Automate every challenge. With 10-day authorization reuse, hand-created TXT records and one-off HTTP-01 paths will fail on the next renewal. Use the Azure DNS solver with a managed identity.
• 5. Fix pickup paths. Front Door secrets on Latest, Application Gateway on versionless identifiers, App Service on imported Key Vault certificates rather than uploads.
• 6. Fix DNS for managed certificates. Every Front Door custom domain CNAME points directly at the endpoint. No chains, no flattening.
• 7. Re-tune monitoring. Proactive lifetime checks and expiry alerts expressed as a fraction of the actual lifetime, plus an alert on the renewal job itself.
• 8. Test on staging from 14 October. Confirm the issued lifetime is 64 days and that every tool schedules renewal at roughly day 43.

The 64-day step is designed to be survivable with sloppy automation. The 45-day step a year later is not. Use the first to prepare for the second.