Will your reverse proxy survive Let's Encrypt's 45-day certificates?

Almost certainly, if your proxy renews by itself. Caddy, Traefik, Nginx Proxy Manager and a current certbot all renew a 45-day certificate with at least 15 days to spare, on their default settings, with nothing to reconfigure. The setups that break are the ones that renew on a calendar rather than by looking at the certificate: acme.sh older than 3.1.3, cron jobs that force a renewal every 60 days, and certbot renew scheduled monthly. And for the default certificate, nothing changes until 10 February 2027.

What changes, and when#

Let's Encrypt is shortening certificates in three steps, and which one applies to you depends on the ACME profile your client requests. If you never set a profile, you are on classic.

Let's Encrypt's own advice is specific. "Renewing at a hardcoded interval of 60 days will no longer be sufficient." Clients should renew about two thirds of the way through the certificate's lifetime, or use ACME Renewal Information (ARI), where the client asks the CA when to renew and the CA answers with a window. For a 45-day certificate, two thirds is day 30, which leaves 15 days to notice and fix a failure. Today, with 90-day certificates renewed on day 60, you have 30.

That halving of the margin is the real change. A renewal that fails quietly used to take a month to become an outage. From 2028 it takes two weeks.

Will each proxy renew in time? The per-tool table#

Each row below comes from the tool's own release notes or source code, read on 8 October 2026, not from its marketing page. "Renews" is the day of a 45-day certificate on which a renewal is first attempted.

The ARI rows say "about" because the window comes from Let's Encrypt and the client picks a point inside it; Let's Encrypt's rate limits post says it expects renewal around day 30 of a 45-day certificate.

Two things stand out. Every proxy that manages its own certificates is fine. And the tools that renew earliest, Traefik and Nginx Proxy Manager at 30 days left, are fine for a crude reason: a 30-day threshold was generous for 90-day certificates and is still generous for 45.

Caddy: nothing to do, as long as you are on 2.8 or later#

Caddy's 2.8.0 release, 29 May 2024, added support for the ARI draft, together with certificate lifetime and revocation status, to trigger renewals. Underneath, the CertMagic library checks every certificate every 10 minutes. With ARI available it renews inside the window Let's Encrypt suggests. Without it, the default renewal window is 1/3 of the lifetime remaining, which on a 45-day certificate is the same day 30.

The only Caddy that needs a look is one pinned to an image older than 2.8, which renews without ARI. Caddy vs Traefik has the rest of the case for Caddy.

Traefik: no ARI, and the setting people will reach for makes it worse#

Traefik 3.7.14 does not implement ARI. Its renewal rule is in the ACME provider's source: it picks a renew period from the certificatesDuration option, then renews any certificate whose real expiry date falls inside that period. The default is 2160 hours, 90 days, which maps to "renew with 30 days left, check once a day".

That rule looks at the actual certificate, so it works for any lifetime longer than 30 days. A 64-day certificate renews on day 34, a 45-day certificate on day 15.

The trap is the obvious-looking fix. The documentation describes certificatesDuration as "the certificates' duration in hours, exclusively used to determine renewal dates", and someone reading about 45-day certificates will set it to 1080. That moves Traefik into its 30-to-90-day bracket, where the renew period is 10 days and the check runs every 12 hours. A 45-day certificate then renews on day 35, later than before, and with less slack than Let's Encrypt recommends. If the minimum monitoring stack alerts on any certificate inside 14 days, it will fire on every renewal cycle.

Leave certificatesDuration at its default. It only needs lowering for a CA whose certificates last under 30 days.

What Traefik's missing ARI costs you is the early-renewal case: if Let's Encrypt needs a certificate replaced before its normal window, for example after a revocation, an ARI client hears about it and Traefik does not. Certbot's changelog gives exactly this reason for letting an early ARI window override a user's own schedule. For a home server that is an edge case, and it is the one argument here for Caddy over Traefik.

Nginx Proxy Manager: its own timer, not certbot's#

Nginx Proxy Manager runs certbot inside the container, but certbot does not decide when to renew. NPM 2.16.0 runs its own timer every hour, selects every Let's Encrypt certificate that expires within 30 days, and calls certbot renew --force-renewal on each one in turn. Certbot's ARI support is therefore never consulted.

For 45-day certificates that is harmless. Every certificate renews on day 15 and then has 30 days of margin, more than an ARI client would leave. It renews more often than it needs to, and that costs nothing: Let's Encrypt's rate limits post says renewals are exempt and that nobody needs a change to their limits for 45-day certificates.

The NPM risk is the one Caddy vs NPM already covers: a DNS plugin that breaks on a certbot upgrade inside the image. A renewal that fails that way fails every hour for 30 days, so the logs have plenty of time to tell you, if anybody reads them.

certbot: the client is fine, the schedule might not be#

Certbot's own renewal rule has moved twice. Before 4.0.0 it renewed at a hardcoded 30 days before expiry. 4.0.0 (April 2025) changed that to 1/3 of the lifetime left. 4.1.0 (June 2025) added ARI: certbot renew checks it automatically and, for Let's Encrypt, the changelog says this "will typically cause renewal at around 2/3rds of the certificate's lifetime". An early ARI window also overrides a later renew_before_expiry you set yourself.

So certbot's logic is right on any version. What can break is how often you run it. certbot renew only renews certificates that are due, and on 4.0 or later a 45-day certificate becomes due on day 30. A monthly cron job can land on day 29, renew nothing, and next run on day 59, two weeks after the certificate expired. Upgrading certbot makes a monthly schedule worse, because older versions made the certificate due from day 15.

Run certbot renew at least once a day, and check what actually schedules it:

# Is a timer doing the work?
systemctl list-timers | grep -i certbot

# What certbot thinks, without renewing anything
certbot renew --dry-run

acme.sh: version 3.1.3 is the line#

acme.sh is where the brittle default lived. Up to 3.1.2 it renewed 60 days after the certificate was issued, whatever the certificate's lifetime. On a 64-day certificate that leaves 5 days; on a 45-day certificate the renewal date is 14 days after expiry.

3.1.3 (28 April 2026) changed the default to 30 days. 3.1.4 (17 July 2026) enabled ARI by default and changed the installed cron job to run every 6 hours. Since 3.1.4 the source also caps a fixed schedule at one day before expiry, so a 60-day setting can no longer outlive the certificate, though one day is no margin at all.

Two steps:

acme.sh --upgrade
# then look for a pinned schedule; acme.sh only writes this line if you passed --days
grep Le_RenewalDays ~/.acme.sh/*/*.conf

If a Le_RenewalDays line appears, someone pinned the schedule, probably copying an old guide. Delete the line and acme.sh falls back to its default and ARI.

Hand-written cron jobs: the setups that break#

A crontab entry like 0 3 1 */2 * certbot renew --force-renewal or a script calling acme.sh --issue --force every 60 days ignores the certificate entirely. It has 4 days of slack from February 2027 and fails outright from February 2028. Let's Encrypt names this case specifically. Replace it with the client's own renew command run daily and let the client decide.

DNS-01 and the 7-hour reuse: what actually breaks#

Authorization reuse is how long after you prove control of a domain Let's Encrypt will issue for it without asking again. It is 30 days now, 10 days from February 2027 and 7 hours from February 2028.

This matters less for DNS-01 than it sounds. A routine renewal already happens 30 or more days after the last validation, so it already needs a fresh challenge today. A client holding a DNS provider API token, which is how Reverse proxy and TLS sets up Caddy and Traefik, writes a new TXT record every time and will not notice the change.

What breaks is anything done by hand. A certbot --manual certificate where you paste the TXT record yourself now needs that every month or so, and cannot be validated once and reused for a later certificate. Let's Encrypt is blunt: manual renewal "is not recommended". The planned fix, dns-persist-01, uses a TXT record that does not change between renewals, and acme.sh 3.1.4 already supports it, but Let's Encrypt said on 25 June 2026 that it will not deploy it until an open issue in the draft is resolved. Do not plan around it yet. Move manual hostnames to a DNS API.

Test your setup with a 45-day certificate now#

You do not have to wait for 2028. Request the tlsserver profile on one hostname and you get a 45-day certificate today. In Traefik that is --certificatesresolvers.le.acme.profile=tlsserver, available since v3.4.0; in certbot, --preferred-profile tlsserver from 4.0.0. Then read the dates and watch for the renewal:

echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null \
  | openssl x509 -noout -dates

When this answer stops applying#

• Other CAs. Every number here is Let's Encrypt's schedule. A different CA has its own lifetimes and may not offer ARI.
• Newer versions. The table reflects the versions named, read on 8 October 2026. Traefik adding ARI, or NPM changing its timer, would change those rows.
• Containers without persistent certificate storage. Short certificates do not cause this, but they make it hurt sooner: a proxy that loses its certificates on every recreate requests new ones each time, and those are not renewals.

What to do next#

Find out which row you are in: check the proxy's version, and run crontab -l and systemctl list-timers on every machine that holds a certificate. If you run Caddy, Traefik on defaults or Nginx Proxy Manager, you are done. If you run acme.sh or a hand-written cron job, fix it this month rather than in January 2027. Then make sure a failed renewal reaches you within days: The minimum viable monitoring stack covers a certificate-expiry alert, and Uptime Kuma can send one alongside uptime checks. If you are choosing a proxy now, Reverse proxy and TLS is the place to start.