47-day TLS certificates: the 2026-2029 timeline and what to do now

The certificates behind the padlock are getting shorter in steps: from 398 days to 47 days by 2029, under a CA/Browser Forum ballot that passed in April 2025. The first step already took effect on 15 March 2026. If you still renew by hand once a year, you will be doing it more and more often until manual renewal stops being realistic. This article sums up the schedule, what Let’s Encrypt is changing, and how to check that your server really renews by itself.

Facts checked against: CA/B Forum ballot SC-081v3, DigiCert’s summary and Let’s Encrypt announcements, as of October 2026. Commands are for Ubuntu 24.04 with certbot.

Why shorter

The stated reasons in SC-081 are to reduce the risk from misissued certificates and stale validation data, and to make it faster to switch cryptographic algorithms when needed. A long-lived certificate means that if a key leaks or a certificate is misissued, it stays usable for up to a year. Shorter lifetimes limit how long a bad certificate can be used.

The ballot passed on 11 April 2025: certificate issuers 25 yes, 0 no, 5 abstain; certificate consumers (browsers) 4 yes.

The SC-081 timeline

From	Max certificate lifetime	Max reuse of domain validation
Before 15 Mar 2026	398 days	398 days
15 Mar 2026	200 days	200 days
15 Mar 2027	100 days	100 days
15 Mar 2029	47 days	10 days

The right-hand column matters as much. Domain control validation (DCV) is how you prove you control a domain, for example by serving a file or adding a DNS TXT record. From 2029 a validation can be reused for only 10 days, so almost every renewal also needs a fresh validation. If that step is still manual, it has to be automated too.

This is a ceiling for every public CA, including paid ones.

What Let’s Encrypt is changing

Let’s Encrypt has issued 90-day certificates for years, already under the ceiling, but it is going shorter:

Date	Profile	Lifetime	Validation reuse
Today	classic (default)	90 days	30 days
13 May 2026	tlsserver (opt-in)	45 days	not stated
10 Feb 2027	classic	64 days	10 days
16 Feb 2028	classic	45 days	7 hours

Staging gets each change about a month before production, and you see the shorter lifetime at your first renewal after each date.

Also new: since 15 January 2026, short-lived certificates (the shortlived profile) and IP address certificates are generally available.

• A shortlived certificate lasts 160 hours, just over six days. It is opt-in; Let’s Encrypt says there is no plan to make it the default.
• IP address certificates (IPv4 and IPv6) must be shortlived.
• Certbot can request IP certificates from 5.3 (webroot needs 5.4 or later) but cannot yet install them into nginx; point your server at /etc/letsencrypt/live/<ip>/ yourself.

# Let's Encrypt's example: request an IP certificate on staging first (certbot 5.4+)
sudo certbot certonly --staging \
  --preferred-profile shortlived \
  --webroot --webroot-path /var/www/html \
  --ip-address 192.0.2.10

Worked example: renewals per year

Say you look after 10 domains, a manual renewal takes 30 minutes (request, validate, install, reload), and you apply the same rule to every lifetime: renew at about two-thirds of the lifetime, which Let’s Encrypt calls acceptable.

1. 398 days: renew every 398 × 2/3 ≈ 265 days → 365 ÷ 265 ≈ 1.4 renewals a year per domain
2. 200 days (now): every ≈ 133 days → 365 ÷ 133 ≈ 2.7
3. 100 days (2027): every ≈ 67 days → 365 ÷ 67 ≈ 5.4
4. 47 days (2029): every ≈ 31 days → 365 ÷ 31 ≈ 11.8, roughly once a month

For 10 domains at 47 days: 11.8 × 10 = 118 renewals a year × 30 minutes = 59 hours a year. At 398 days it was 1.4 × 10 × 0.5 = 7 hours. The same chore grows about eightfold, and a single forgotten renewal puts a red warning page in front of your users.

The 6-day certificate makes the point even more clearly: 160 × 2/3 ≈ 107 hours, a renewal every four and a half days. Nobody does that by hand.

The lifetime is not the problem; manual renewal is. If the machine renews itself, 47 days and 398 days feel the same in practice.

Check that your server really renews

On Ubuntu, certbot from snap or apt installs a systemd timer (snap.certbot.renew.timer or certbot.timer, depending on how it was installed). Check three things:

# 1) The timer exists, and when it last ran
systemctl list-timers | grep -i certbot

# 2) A real renewal run against staging, without replacing anything
sudo certbot renew --dry-run

# 3) When the certificate your site is actually serving expires
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Step 3 matters more than it looks. A renewed file on disk does not mean the site serves it: if nginx was not reloaded, the old certificate is still in memory. Have certbot reload on every successful renewal:

# Add a deploy hook to an existing certificate (once; stored in its renewal config)
sudo certbot reconfigure --cert-name example.com \
  --deploy-hook "systemctl reload nginx"

Then alert when a certificate has fewer than 14 days left. The approach from a server monitor that pings Telegram works: turn the step 3 output into days remaining and send a message past the threshold. A failed renewal is always silent, right up to the day it expires.

Prepare before 2029

• Automate domain validation. With DNS-01, the machine must update TXT records through your DNS provider’s API. Let’s Encrypt says it is working on a new method, DNS-PERSIST-01, with the CA/B Forum and IETF: set a TXT record once and leave it. It expects this to be available in 2026.
• Drop fixed 60-day cron jobs. Let’s Encrypt says plainly that a fixed 60-day interval will not be enough for 45-day certificates. Use a client that supports ACME Renewal Information (ARI), or renew at two-thirds of the lifetime.
• Count the hand-installed certificates. Certificates copied onto a load balancer, a network appliance or an app that does not read from /etc/letsencrypt are the ones that expire quietly.

Once HTTPS renews itself, set HSTS and the other headers too; see security headers on nginx.

Common mistakes

• Renewing without reloading. The new certificate sits on disk while the site serves the old one until it expires.
• Testing against production repeatedly and hitting rate limits. Use --dry-run or --staging while experimenting.
• Nobody receives the expiry email. The address registered at issuance belongs to someone who left. Run your own alert.
• Using the nginx plugin for an IP certificate. As of October 2026 certbot cannot install IP certificates into nginx or Apache; use certonly and set the paths yourself.
• Forgetting that staging changes first. Test systems on staging see shorter certificates about a month before production, which is a chance to catch problems early.

Sources

• Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods — CA/Browser Forum
• 6-day and IP Address Certificates are Generally Available — Let’s Encrypt
• Decreasing Certificate Lifetimes to 45 Days — Let’s Encrypt
• Six-Day and IP Address Certificates Available in Certbot — Let’s Encrypt
• TLS Certificate Lifetimes Will Officially Reduce to 47 Days — DigiCert
• CA/Browser Forum and 47 Days: Everything you need to know — AppViewX