If you have ever been woken up by "your connection is not private" on your own site, you know how an expired certificate feels. The page is still there. Your server is fine. But every visitor gets a full-screen warning and most of them leave.
That problem is about to get more frequent for anyone who still renews certificates by hand. The rules for how long an SSL certificate can last are changing. The first step is already in effect.
The new limits, with dates
In April 2025 the CA/Browser Forum (the group of browser makers and certificate authorities that sets the rules for public certificates) passed ballot SC-081. Apple proposed it. It cuts the maximum lifetime of a public TLS certificate in three steps:
| From | Maximum lifetime |
|---|---|
| Before March 15, 2026 | 398 days |
| March 15, 2026 | 200 days |
| March 15, 2027 | 100 days |
| March 15, 2029 | 47 days |
The first step has already happened. If you bought a "one year" certificate this summer, it was issued for 200 days at most.
The ballot also shortens how long a certificate authority can reuse a past check that you control the domain. By 2029 that window is down to 10 days, which means the domain is validated again at almost every renewal.
Let's Encrypt is moving even faster
Let's Encrypt has always used short certificates: 90 days since it launched in 2015. It has now published its own schedule to go shorter:
- May 2026: the opt-in
tlsserverprofile started issuing 45-day certificates for early adopters. - February 10, 2027: the default profile drops to 64 days.
- February 16, 2028: the default profile drops to 45 days.
Let's Encrypt also stopped sending expiry reminder emails on June 4, 2025. If you relied on that email as your safety net, it is gone.
Why browsers want this
Shorter certificates limit the damage when something goes wrong. If a private key leaks or a certificate is issued by mistake, revocation is supposed to kill it. In practice revocation checks are slow and often skipped. A certificate that expires in 47 days is a problem for 47 days, not for a year.
It also forces automation. Once every certificate on the internet renews every month or two, nobody can do it by hand, so the whole system gets better at rotating keys and switching certificate authorities when it has to.
What changes for you
If your certificates already renew automatically, very little changes. certbot, acme.sh, Caddy, Traefik and most hosting platforms renew well before expiry. The one thing to check is the schedule. A cron job that renews "every 60 days" works for 90-day certificates and breaks for 45-day ones. Let's Encrypt recommends renewing about two thirds of the way through a certificate's life, or better, using ACME Renewal Information (ARI) so the certificate authority tells your client when to renew.
If you buy a certificate and install it by hand once a year, that workflow is already over. At 200 days you renew twice a year. By 2029 it is roughly eight times a year per domain. Every renewal is a chance to forget.
If you run lots of small projects, the math gets ugly. Ten side projects on hand-installed certificates means a renewal every few days by 2029.
How to stop thinking about certificates
There are three common ways to get there.
Use an ACME client on your server
certbot with the Nginx plugin is the classic setup:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com
certbot installs a systemd timer that checks twice a day and renews when the certificate is close to expiry. Run sudo certbot renew --dry-run once to make sure renewal works before you forget about it.
Use a web server that does it for you
Caddy gets and renews certificates on its own as soon as you name a domain in its config. Traefik does the same with a certificate resolver. Both are good choices when you want HTTPS without a separate tool.
Put the site behind something that owns the certificate
This is what platforms like Vercel and Netlify do. It is also what DomainDock does for apps on your own server. Our gateway holds a wildcard Let's Encrypt certificate for *.digitalweb.host and renews it in the background. When you add myapp.digitalweb.host and point it at your server's IP and port, the address is covered immediately. Your app can listen on plain HTTP and visitors still get a valid padlock.
The shorter lifetimes don't change anything for you in that setup. The gateway renews more often and you never notice.
Automation still needs a watcher
Automatic renewal fails in boring ways: a DNS API token expires, a firewall change blocks port 80 for the HTTP challenge, a disk fills up and the client can't write the new certificate. With 47-day certificates you have less time to notice.
A simple check from outside catches all of these. This prints the expiry date of the certificate a server is actually serving:
echo | openssl s_client -connect app.example.com:443 -servername app.example.com 2>/dev/null \
| openssl x509 -noout -enddate
Run it from a cron job and alert when the date is less than 14 days away. Or use an uptime monitor that checks certificates. DomainDock checks every route every 5 minutes, so a broken HTTPS connection shows up in the dashboard with the reason instead of in a support email from a visitor.
The short version
- Since March 2026, no public certificate lasts more than 200 days. By 2029 the limit is 47.
- Let's Encrypt is going to 45 days by default in 2028 and no longer emails you before expiry.
- Manual renewal is on its way out. Use an ACME client, a server that manages certificates or a gateway that does it for you.
- Keep an outside check on the expiry date, because automation fails quietly.
If you want HTTPS for a project on your own server without running any of this yourself, get a free domain with a certificate included.