Shorter SSL certificate validity: automated renewal without outages
The maximum SSL certificate validity is being shortened step by step. Publicly trusted certificates issued from 15 March 2026 may be valid for at most 200 days, from 15 March 2027 for at most 100 days and from 15 March 2029 for only 47 days (CA/Browser Forum Baseline Requirements). You can no longer get a certificate valid for a whole year, and manual replacement would have to be repeated more and more often. To keep your website, online shop and integrations from going down because of an expired certificate, you need an inventory of all certificates, automated renewal, domain validation without human intervention and independent monitoring that alerts you when a renewal fails.
They are commonly called SSL certificates; technically, they are certificates for the TLS protocol on which HTTPS is built. If your hosting renews the certificate automatically, it is usually enough to verify the renewal and add monitoring. Systems with manual or custom renewal will need the most work.
What is changing and when
Rules for all publicly trusted certificates
The rules for certificates trusted by browsers are set by the CA/Browser Forum, a voluntary organization of certification authorities and suppliers of browsers and other software. For a business website, two periods in its Baseline Requirements matter, and both are being gradually shortened: the maximum certificate validity and the time during which a certification authority may reuse a completed validation of control over the domain (Baseline Requirements, sections 4.2.1 and 6.3.2).
| Certificate issued | Maximum certificate validity | Maximum reuse of domain validation |
|---|---|---|
| before 15 March 2026 | 398 days | 398 days |
| from 15 March 2026 | 200 days | 200 days |
| from 15 March 2027 | 100 days | 100 days |
| from 15 March 2029 | 47 days | 10 days |
For a business, this means proving control over its domain more and more often. Setting up validation once by hand for the first certificate is therefore not enough – it has to work reliably at every renewal.
Let’s Encrypt: 45 days and no more email reminders
The free certification authority Let’s Encrypt issues 90-day certificates in its default profile. In December 2025 it published a schedule for shortening them: the opt-in tlsserver profile issues 45-day certificates from 13 May 2026, and the default classic profile is due to move to 64 days on 10 February 2027 and to 45 days on 16 February 2028. In the default profile, the reuse of domain validation will shrink from today’s 30 days to 10 days in February 2027 and to 7 hours in February 2028. The changes take effect at the first renewal after these dates (Let’s Encrypt: Decreasing Certificate Lifetimes to 45 Days).
In addition, Let’s Encrypt stopped sending expiration reminder emails on 4 June 2025 and recommends a third-party monitoring service instead (Let’s Encrypt: Ending Support for Expiration Notification Emails). If you relied on these emails, no reminder will come from Let’s Encrypt anymore.
A practical example: five addresses of one company
The following example is illustrative and does not describe a real client; the addresses use the example domain example.com. During an inventory, a small company finds that the certificates for its five HTTPS addresses are each managed differently:
| Address | How the certificate is renewed today | Risk with shorter validity | Action |
|---|---|---|---|
| www.example.com – WordPress on managed hosting | automatically by the hosting provider | low, as long as the domain points to the hosting | verify renewal with the hosting provider and add external monitoring |
| eshop.example.com – own server | ACME client run by a scheduler once every 60 days | high: a fixed interval will stop being enough | daily check and renewal based on ARI or after two thirds of the validity period |
| b2b.example.com – portal behind a load balancer | commercial certificate bought for a year before March 2026, uploaded manually | high: the next certificate will be valid for at most 200 days, and from 15 March 2027 for at most 100 days | automate via ACME or the provider’s interface, including deployment to the load balancer |
| *.example.com – internal tools | wildcard certificate, TXT record in DNS added manually | high: manual DNS changes with ever more frequent validation | DNS-01 with restricted API access to DNS |
| staging.example.com | nobody | medium: the certificate expires unnoticed | automate, or switch the address off |
So the biggest risk is not the main website but the systems with their own or manual renewal: the online shop, the B2B portal and the wildcard certificate. The online shop’s scheduler with a 60-day interval works with today’s 90-day certificates. With 64-day certificates from February 2027, however, only 4 days of margin will remain, and with 45-day certificates the certificate would expire before it is renewed. Let’s Encrypt explicitly states that a fixed 60-day interval is not sufficient for 45-day certificates, and it does not recommend manual renewal (Let’s Encrypt).
Step-by-step implementation
- Build an inventory. For every domain and subdomain with HTTPS, record who issues the certificate, where it is installed (server, load balancer, CDN, mail server), how it is renewed, who is responsible for it and when it expires. Do not forget staging, old campaign websites and API addresses.
- Decide how each certificate is renewed. If the certificate is managed by your hosting or CDN, check that renewal really runs automatically. On your own servers, use a client for the ACME protocol (Automated Certificate Management Environment). Keep manual renewal only as a temporary exception with a replacement deadline.
- Choose domain validation. With the HTTP-01 method, the client places a file at
http://example.com/.well-known/acme-challenge/and the certification authority downloads it over port 80. With the DNS-01 method, the client creates a TXT record named_acme-challenge(Let’s Encrypt: Challenge Types). The table in the next section covers the choice in more detail. - Set the renewal timing. If your client supports it, turn on ARI (ACME Renewal Information). Under the RFC 9773 standard, the certification authority can suggest a renewal window to the client, for example an earlier renewal ahead of a mass revocation of certificates (RFC 9773). How to enable ARI depends on the specific client. Without ARI, have the scheduler check certificates often – we recommend daily – and renew them at roughly two thirds of their validity, which Let’s Encrypt describes as acceptable behavior (Let’s Encrypt).
- Automate deployment. Every system that serves the certificate to visitors has to start using the renewed one: the web server after a reload, the load balancer, the CDN and the mail server. A new file on disk is not enough if the server still serves the old certificate.
- Turn on independent monitoring. Check the certificate that the address actually serves, not the file on the server. The alert should go to a specific person when renewal has not happened in the expected time – for example, for a 45-day certificate renewed after 30 days, when fewer than 10 days remain. Monitoring that alerts you to certificates that have not been renewed is also recommended by Let’s Encrypt.
- Test the automation in advance. If your ACME client supports profile selection, you can try the shorter validity right now: the opt-in
tlsserverprofile issues 45-day certificates, and Let’s Encrypt describes it as suitable for testing as well. It deploys further changes to its test environment (staging) roughly a month before the production dates (Let’s Encrypt). - Prepare an emergency replacement procedure. In certain cases, such as compromise of the private key, the certification authority must revoke a certificate within 24 hours (Baseline Requirements, section 4.9.1.1). Write down who replaces the certificate outside the schedule and how, and rehearse the procedure at least once a year.
How to choose domain validation and the renewal method
The decision depends on where the certificate runs and who manages DNS. The properties of the methods in the table are based on the Let’s Encrypt documentation; the recommendations are ours (Let’s Encrypt: Challenge Types).
| Situation | Recommended approach | What to watch out for |
|---|---|---|
| Website on hosting or behind a CDN that issues the certificate itself | the provider’s automation | verify renewal after DNS or proxy changes and add external monitoring |
| A single server reachable from the internet on port 80 | ACME client with HTTP-01 | no firewall, password or maintenance mode may block the validation file |
| Several servers behind a load balancer | DNS-01, or central issuance and distribution of the certificate | with HTTP-01, the validation file must be available on all servers |
| Wildcard certificate or a server not reachable from the internet | DNS-01 | a DNS API key with minimal permissions or a delegated _acme-challenge record |
| A system without support for automation | temporarily manual with monitoring, then replacement or a reverse proxy in front of the system | at most 100 days of validity from 15 March 2027, at most 47 days from 15 March 2029 |
DNS-01 only makes sense if your DNS provider offers an API for automated changes. Full API access to DNS stored on the web server increases the impact of a potential breach, so Let’s Encrypt recommends narrowly scoped credentials or validation from a separate server. The validation record can be delegated to a separate zone via CNAME. If the provider cannot confirm that a DNS change has propagated, the client has to wait long enough, often as much as an hour. The third method, TLS-ALPN-01, is not suitable for most users according to Let’s Encrypt; it is mainly intended for large hosting providers (Let’s Encrypt: Challenge Types).
In December 2025, Let’s Encrypt announced that, together with partners in the CA/Browser Forum and IETF, it is standardizing a new validation method, DNS-PERSIST-01, in which the TXT record does not change at every renewal (Let’s Encrypt). Before you count on it in your plans, check whether your certification authority and ACME client already support it.
Benefits and tradeoffs
Shorter validity has a security rationale: according to Let’s Encrypt, it limits the scope of a compromise and makes certificate revocation more efficient (Let’s Encrypt). For a business, the main benefit of automation is that replacing a certificate stops being an event someone has to remember. However, expect these tradeoffs:
- Validation needs access. HTTP-01 requires port 80 on all servers, DNS-01 requires access to DNS. Both types of access must be secured.
- More moving parts. The scheduler, deployment and monitoring all need maintenance, and someone has to read the alerts.
- Dependence on the certification authority. If renewal starts well in advance, a short outage at the authority is solved by retrying.
- Older systems. Some devices and applications do not support automation, so they need a proxy or a replacement.
When little is enough: if you have a single website on hosting that renews certificates by itself, it is often sufficient to verify renewal with the hosting provider and add external monitoring. A bigger project makes sense with multiple domains, your own servers, B2B portals and integrations.
Common mistakes
- The scheduler renews at a fixed interval, for example once every 60 days, instead of according to ARI or the remaining validity.
- The company waits for an email from the certification authority that Let’s Encrypt no longer sends.
- The certificate is renewed, but the web server, load balancer or CDN keeps serving the old one.
- A firewall, geoblocking, a password on staging or maintenance mode blocks the validation file, which Let’s Encrypt may download repeatedly from multiple locations. A normal redirect to HTTPS is fine – Let’s Encrypt follows up to 10 redirects, but only to ports 80 or 443 (Let’s Encrypt: Challenge Types).
- A full DNS API key sits directly on the web server.
- Old
_acme-challengeTXT records pile up in DNS; if the response gets too large, Let’s Encrypt starts rejecting the validation. - Only one person knows the procedure and it is not written down anywhere.
Checklist
Before the shorter validity reaches your certificates, tick off the following:
- the inventory contains all domains, subdomains, installation locations and responsible people,
- every certificate is renewed automatically or has a documented temporary exception with a replacement deadline,
- renewal follows ARI or the remaining validity, not a fixed interval,
- domain validation runs without human intervention and with minimal permissions,
- the renewed certificate is deployed automatically wherever it is used,
- external monitoring checks the certificate the address actually serves and alerts a specific person,
- the automation has been tested in the certification authority’s test environment,
- the procedure for replacing a certificate within 24 hours is documented and rehearsed.
Frequently asked questions
Does the shorter validity also apply to paid certificates?
Yes. The Baseline Requirements apply to all publicly trusted TLS certificates regardless of price. Let’s Encrypt states that all publicly trusted certification authorities will make similar changes. Switching providers will not let you avoid the shorter validity.
Is it enough if the hosting provider renews the certificate?
For a simple website on managed hosting, often yes. Still, check whether the hosting renews certificates for all subdomains and what happens after a DNS change or when a CDN is deployed. We recommend external monitoring in this case too, because email reminders from Let’s Encrypt no longer arrive.
When do I need DNS validation instead of HTTP?
For wildcard certificates, which the HTTP-01 method does not support, for servers not reachable from the internet and often also for several servers behind a load balancer. DNS-01, however, requires a DNS provider with an API and secure storage of the credentials.
How quickly must we be able to replace a certificate outside the schedule?
Think in hours, not weeks. In precisely defined cases, such as a key compromise, the certification authority must revoke a certificate within 24 hours. Automated renewal and a documented procedure are therefore also part of your incident readiness.
Want to keep your certificates under control?
We can help you build an inventory of your certificates and set up automated renewal, domain validation and monitoring for your website, online shop and B2B portal. Learn more about our work on the Webiant homepage, browse other articles on our blog or contact us directly.
Sources
- CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates – maximum certificate validity, reuse of domain validation and revocation within 24 hours
- Let’s Encrypt: Decreasing Certificate Lifetimes to 45 Days – the Let’s Encrypt schedule, ARI and recommendations on automation and monitoring
- Let’s Encrypt: Ending Support for Expiration Notification Emails – the end of email expiration reminders
- Let’s Encrypt: Challenge Types – the HTTP-01, DNS-01 and TLS-ALPN-01 validation methods
- RFC 9773: ACME Renewal Information (ARI) Extension – the standard for a suggested renewal window