If you are used to buying an SSL certificate once a year and installing it by hand, that routine is about to end. In April 2025 the CA/Browser Forum, the body that brings together browser makers and certificate authorities, approved Ballot SC-081. It shortens the maximum validity of TLS certificates in stages until, in 2029, a certificate can live for only 47 days. The rule applies to free and paid certificates alike.
The timeline
Until 15 March 2026 a certificate could be valid for up to 398 days. Since that date the limit is 200 days, from March 2027 it drops to 100 days, and from March 2029 to 47 days. The period during which a domain validation result can be reused shrinks as well, reaching just 10 days by 2029.
| From | Maximum certificate validity | Domain validation reuse |
|---|---|---|
| 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 first stage is already in force, so a certificate ordered today lasts six and a half months at most. Vendors still sell "one-year" plans, but inside such a plan the certificate is reissued at least twice a year.
Why validity is being cut
The main reason is security. If a private key is stolen or leaks from a server, an attacker can impersonate your site for as long as the certificate stays valid, and revocation checking in browsers has never been reliable enough to fix that. Shorter lifetimes shrink that window. They also keep certificates in line with reality when a domain changes hands or a site moves, and they push the industry toward automation, because a manual task done once a year is easy to forget and easy to get wrong.
What changes for Let's Encrypt users
Let's Encrypt has issued 90-day certificates for years and has announced a move to even shorter 45-day ones. For sites that renew automatically over the ACME protocol this is barely noticeable, since the renewal client runs well before expiry. On sayt.uz hosting, for example, a Let's Encrypt certificate is installed for free and the panel renews it without any action from the customer.
An example: a paid certificate renewed by hand
Picture a trading company in Tashkent that buys a one-year OV certificate every November. An IT employee generates a CSR, waits for the approval email, uploads the files and restarts the web server, which takes half a day once a year. After March 2026 the same procedure has to happen twice a year, from 2027 four times, and from 2029 roughly eight times. Sooner or later the person in charge is on holiday, the reminder lands in spam, and on Monday morning visitors see a browser security warning. The sensible fix is to automate: pick a commercial CA that supports ACME, or move to a free auto-renewing certificate if OV or EV is not required.
How automation works
ACME turns ordering, domain validation and installation into a fully scripted process. On Linux servers the usual tools are certbot and acme.sh; in hosting panels it is typically a single auto-renew setting. You can test renewal with certbot renew --dry-run and check the real expiry date of a live certificate with openssl s_client -connect example.uz:443 -servername example.uz </dev/null | openssl x509 -noout -enddate.
Failures we see most often
Auto-renewal can fail silently. The most common cause is a domain whose DNS points to a different server: HTTP-01 validation fetches a file through the domain, so if the A record points elsewhere the check fails and the old certificate quietly expires. With a 47-day lifetime there is very little slack to notice and fix it. The second classic is a forgotten mail server certificate, installed by hand years ago, which one day makes Outlook and phone mail apps show certificate errors to staff.
What to do now
Start with an inventory of every certificate you have: the main site, subdomains, mail, control panels, APIs and internal services. Note which ones are renewed manually, because each of them needs automating before 2027.
- Enable auto-renewal in your hosting panel, or set up certbot or acme.sh with a timer on your own server.
- Check DNS so that A and AAAA records point to the server that issues the certificate.
- Use DNS-01 for wildcards, since
*.example.uzcan only be validated through DNS. - Add monitoring that warns you 14 days before expiry.
Most of this is done once. If your site is hosted on sayt.uz, free SSL for the domain and subdomains already renews automatically, and all you need to watch is that the domain's DNS points to the hosting. Short-lived certificates are nothing to fear; they simply retire the manual chore.