Since March 15, 2026, a publicly trusted SSL/TLS certificate can be valid for at most 200 days. The limit falls to 100 days on March 15, 2027 and to 47 days on March 15, 2029. If you renew any certificate by hand today, you will have to do it at least eight times a year by 2029. The answer is to automate renewal now, and to monitor that the automation keeps working.
The schedule comes from the CA/Browser Forum, the group of certificate authorities and browser makers that writes the rules every public certificate follows. This guide explains the schedule, the less discussed change to domain validation, and what to do before each deadline.
The schedule
Ballot SC-081v3, adopted in April 2025, changed the Forum’s Baseline Requirements in three steps. Two limits fall together: how long a certificate may be valid, and how long a certificate authority may reuse an earlier check that you control the domain.
| Certificate issued | Maximum validity | Domain validation reused for up to |
|---|---|---|
| Before March 15, 2026 | 398 days | 398 days |
| From March 15, 2026 | 200 days | 200 days |
| From March 15, 2027 | 100 days | 100 days |
| From March 15, 2029 | 47 days | 10 days |
The ballot page has the vote and the full text. The limits apply when a certificate is issued. A certificate issued before a deadline stays valid until its own expiry date, so nothing you have today stops working on March 15. It just can’t be replaced by one that lasts as long.
What domain validation reuse means
Before a certificate authority issues a certificate, it checks that you control the domain, for example by asking you to publish a DNS record or serve a file over HTTP. Until now it could reuse that check for over a year. From March 2029 the reuse period is 10 days, so almost every renewal will need a fresh check. A renewal that used to work on remembered validation will now depend on your DNS and web server answering correctly every time.
Why lifetimes are getting shorter
- Information in a certificate goes stale. Domains are sold, companies move hosting, keys leak. A shorter lifetime limits how long an outdated or compromised certificate can be used.
- Revocation is unreliable. Browsers can’t always check whether a certificate has been revoked. Expiry is the backstop that always works, and a shorter one works sooner.
- It forces automation. Manual yearly renewal is exactly the process that fails: the person who did it left, the reminder went to an old inbox. When renewal is frequent, it has to be automated, and automated processes can change algorithms or authorities quickly when they need to.
Let’s Encrypt is going further
Let’s Encrypt certificates already last 90 days, well inside every limit above. In Decreasing Certificate Lifetimes to 45 Days it announced its own schedule:
- May 13, 2026: the opt-in
tlsserverprofile issues 45-day certificates. - February 10, 2027: the default
classicprofile moves to 64-day certificates, and validations are reused for 10 days instead of 30. - February 16, 2028: the default moves to 45-day certificates, with validations reused for only 7 hours.
Let’s Encrypt also stopped sending expiration notification emails in 2025. If you relied on those to notice a failed renewal, nothing replaces them unless you set it up.
A checklist to get ready
1. Find every certificate you own
The website is the easy one. Also list API endpoints, admin panels, staging sites, mail servers, load balancers, CDN edge certificates and old campaign subdomains. Certificate Transparency logs record every public certificate, so searching them for your domain (for example on crt.sh) shows certificates nobody remembers ordering. The SSL checker shows the expiry date, issuer, names and chain for any host.
2. Automate renewal with ACME
ACME is the standard protocol for requesting and renewing certificates without a person in the loop (RFC 8555). Certbot, acme.sh and Caddy speak it, as do most hosting panels, load balancers and CDNs. Many commercial authorities support it too, so paid certificates can be automated as well. Renew well before expiry, with about a third of the lifetime left, so a failed attempt has time to be retried.
3. Make validation work every time
With a 10-day reuse period, each renewal needs a passing validation. Check the method you use:
- HTTP validation needs port 80 open and
/.well-known/acme-challenge/reachable, without a redirect to a login page or a firewall rule in the way. - DNS validation needs API access to your DNS provider, and credentials that don’t expire quietly.
- CAA records, if you publish them, must name the authority you use. A CAA record left over from a previous provider blocks issuance. Look them up with the DNS lookup tool.
A changed DNS record is one of the most common reasons a renewal that worked for years suddenly fails. DNS monitoring tells you when one changes.
4. Deploy what you renew
A renewed certificate on disk does nothing until the server loads it. Make sure your client reloads the web server after renewal, and that every server behind a load balancer gets the new certificate, not just the one where the renewal ran. Appliances and services that need a certificate uploaded by hand are where shorter lifetimes hurt most; find out now whether they can fetch one automatically.
5. Rethink manually bought certificates
A certificate sold as a one-year product can no longer be issued for a year. Since March 2026 it has to be reissued at least once during the term, and from 2029 about every six weeks. If an organization-validated certificate is a requirement, ask your authority how it supports ACME before the 100-day step in 2027.
6. Monitor the certificate that is actually served
Automation fails quietly: an expired DNS API token, a server move that skipped the renewal timer, a reload that never happened. The only reliable test is to look at the certificate visitors get, from outside, on a schedule. Our guide to SSL certificate expiry monitoring covers the details, and SSL certificate errors explained shows what visitors see when it goes wrong.
What each deadline means in practice
- Now, at 200 days: every certificate is replaced at least twice a year. A manual process still works, but it is the moment to make the inventory and automate, while a missed renewal is rare.
- From March 15, 2027, at 100 days: at least four replacements a year. A certificate uploaded by hand to an appliance or a hosting panel becomes a quarterly chore that somebody will forget.
- From March 15, 2029, at 47 days: at least eight replacements a year, each with a fresh domain validation. Anything manual will fail sooner or later, and so will automation whose DNS credentials, firewall rules or reload step nobody has tested.
The work is the same at every step: fewer manual certificates, renewal that validates and deploys on its own, and an outside check that tells you when it didn’t.
How Uptimecheck watches your certificates
Every HTTPS monitor in Uptimecheck reads the certificate on each check, so there is no separate SSL monitor to set up.
- Reminders go to the monitor’s alert channels 30, 14, 7 and 1 day before the certificate expires, and on the day.
- Days left turn amber under 30 days and red under 14, and certificates expiring within 14 days are listed under Needs attention on the overview.
- An expired, self-signed or mismatched certificate fails the check, so it opens an incident like any other outage. A missing intermediate certificate shows as Incomplete chain.
Match the reminders to your renewal timing. If your client renews with more than 30 days left, any reminder means a renewal failed. If it renews later, as it will with 47-day certificates, the 30-day reminder arrives before every renewal, and the first reminder after your client’s renewal point is the one that needs action. See how to monitor SSL certificate expiry.
The domain registration has its own expiry date, and no certificate helps once it lapses. Domain monitoring reminds you on the same days; check any domain with the domain expiry checker.
Shorter certificates shouldn’t mean more outages. Try Uptimecheck free for 14 days, no credit card required.