Blog
Shorter SSL certificate lifetimes: what changes for your website before 2027.
The industry rules behind every HTTPS padlock now cap a certificate at 200 days, fall to 100 days from March 2027 and reach 47 days in 2029, which turns renewal from a yearly diary entry into a process that has to be automated and watched.
The padlock in the address bar depends on a small file with an expiry date. When that date passes, every modern browser replaces your home page with a full screen warning that the connection is not private, forms stop submitting, the Google Ads landing pages go dark and the first person to notice is usually a customer. For twenty years the industry answer was to buy a certificate that lasted a year or more and put the renewal in somebody's calendar. That answer is now out of date, because the rules that every browser enforces have changed.
This article sets out what was decided, the dates that matter, what the change means for an ordinary business website and the audit we recommend running before the next step lands in March 2027.
What a certificate does and why its life is being cut.
A TLS certificate, still called an SSL certificate by most people, proves to a browser that the website at your domain is the one it claims to be and lets the two of them encrypt everything that passes between them. Certificates are issued by certificate authorities, and the rules those authorities follow are written by the CA/Browser Forum, a body made up of the authorities themselves and the companies that make browsers and operating systems. Browsers enforce the rules by refusing certificates that break them, so a change at the Forum is a change for every website on the public internet.
In April 2025 the Forum passed Ballot SC-081v3, proposed by Clint Wilson of Apple and endorsed by Sectigo, Google Chrome and Mozilla. Twenty-five certificate authorities voted in favour, none against and five abstained; Apple, Google, Microsoft and Mozilla voted in favour as certificate consumers. The ballot reduces the maximum validity of a public TLS certificate from 398 days to 47 days and the period for which a domain validation can be reused from 398 days to 10 days, in steps that began in March 2026 and finish in March 2029.
The reasoning is about risk. A certificate that lives for a year keeps working for a year even if the private key behind it is stolen or the domain changes hands, and revocation has never worked reliably in browsers. A short certificate limits the damage window on its own, and a short validation period means the authority has recently checked that you still control the domain. The ballot also names a secondary benefit: once renewal has to happen every few weeks, nobody can keep doing it by hand, so the whole ecosystem moves to automated issuance and replacement.
The schedule, step by step.
The dates are written into section 6.3.2 of the Forum's Baseline Requirements, the document every public certificate authority must follow. The maximum validity period of a certificate depends on the day it is issued.
- Issued before 15 March 2026: 398 days. This is the limit most people still have in mind.
- Issued on or after 15 March 2026 and before 15 March 2027: 200 days. We are in this window now, so any certificate bought or renewed this year already expires inside seven months.
- Issued on or after 15 March 2027 and before 15 March 2029: 100 days. From here a website needs at least four renewals a year.
- Issued on or after 15 March 2029: 47 days. Eight renewals a year, and in practice a renewal every month.
Section 4.2.1 of the same document sets the period for which a domain validation can be reused, and it follows the same steps: 200 days now, 100 days from March 2027, then 10 days from March 2029. In other words, by 2029 the authority must have confirmed your control of the domain within the previous ten days before it will issue, which rules out any validation that depends on a person responding to an email.
Two details are easy to miss. The Requirements measure a day as exactly 86,400 seconds and tell authorities not to issue for the maximum by default, so a certificate bought today is more likely to show 199 days than 200. And the limits apply on the day of issue, not the day the rule changes, so a 200 day certificate issued in February 2027 remains valid into August 2027. There is no grace period beyond that.
What this means for a business website.
For many websites the change will pass unnoticed, because renewal is already automatic. Let's Encrypt has issued 90 day certificates since 2015 and built its service around clients that renew without a person involved; it now offers an optional six day certificate, generally available since January 2026 and valid for 160 hours, and has said it will bring its default down to 45 days by February 2028. Managed hosting platforms, content delivery networks and most modern hosting panels renew through the same protocol, called ACME. If your website sits behind one of those and nobody has touched the certificate in years, the mechanism is probably working.
Probably is the problem. Let's Encrypt ended its expiry warning emails on 4 June 2025, explaining that most subscribers now have reliable automation and recommending a third party monitoring service for anyone who still wants a reminder. The free safety net that caught a silent renewal failure for a decade no longer exists, so a website that depends on automated renewal needs its own independent check that the renewal actually happened.
The websites most exposed are the ones with certificates that were bought rather than issued automatically. Organisation validated and extended validation certificates are typically generated, downloaded and installed by hand, and the person who did it may have left. Under the current rules that job comes round twice a year; from March 2027 it comes round four times a year, and the validation itself has to be repeated each time. The purchase price is the smallest part of that cost.
Manual certificates also hide in places nobody thinks of as the website.
- Load balancers, firewalls and reverse proxies in front of the hosting, which often carry their own copy of the certificate.
- Origin certificates between a content delivery network and the server behind it.
- Subdomains used for tracking, email sending, customer portals, booking tools and application programming interfaces, each with its own hostname.
- Payment gateway callbacks, warehouse and ERP integrations and SFTP transfers that check your certificate on their side.
- Mobile apps or partner systems that pin a specific certificate, which will break the moment it is rotated.
- Staging and testing environments, which fail quietly and then block a release.
An audit you can run this month.
The audit is not technical in the way a code review is technical. It is an inventory exercise that a website support team can complete in a day for most organisations, and it answers five questions for every public hostname you own.
- What certificates exist? List every hostname that answers on HTTPS, including the ones above, and record the issuer, the issue date, the expiry date and the type of certificate. Certificate transparency logs are public and will show you certificates you had forgotten about.
- How is each one renewed? Automatic through ACME, automatic through a hosting or CDN panel, or by a person. Anything in the third category needs a plan before March 2027.
- How is the domain validated? Validation over HTTP needs the authority to reach a file on your server, which security rules and redirects can block. Validation through DNS needs an API key for your DNS provider, which is the only route for wildcard certificates. Validation by email needs a person, which will not survive the 10 day rule.
- Who finds out when it fails? Set up expiry monitoring that is independent of the authority and the hosting, with an alert at 14 days and again at 7, and make sure the alert goes to a role mailbox rather than a person.
- What depends on the certificate staying the same? Check for pinning in apps and integrations, and for partners who whitelist a certificate fingerprint rather than a hostname.
Record the answers somewhere the whole team can see them. The audit is not a one off; it is the register that the renewal process runs from, and it should be reviewed each time the limit steps down.
Where frequent renewal goes wrong.
Automation fails in predictable ways, and almost all of them are visible before the certificate expires if somebody is looking. A security rule added to the web application firewall starts blocking the validation request. A DNS provider rotates its API keys. A certificate that covers several domains on one request fails completely because one of those domains has lapsed. A content delivery network is switched on in front of the website and the old validation route stops working. A renewal succeeds but the service that uses the certificate is never reloaded, so visitors are still served the old one. None of these are exotic; we have seen each of them on websites that had been renewing happily for years.
The practical defence is to test the renewal path on purpose rather than wait for it. Force a renewal on staging after any change to hosting, DNS, firewall or CDN settings. Watch the logs of the ACME client, not just the padlock. Keep the number of hostnames on any one certificate small so one lapsed domain cannot take the others down. Treat a renewal failure alert as an incident with an owner, because under a 47 day limit the time between a silent failure and a public outage is measured in weeks, not months.
Finally, resist the temptation to solve the problem by buying longer certificates from a different authority. There are none. Any certificate a browser trusts is bound by the same Requirements, and an authority that issued outside them would be removed from the browsers' trust stores. The only durable answer is a renewal process that does not need a person.
How we can help.
Certificate management is one of the quieter parts of the website support work we do for clients, alongside hosting, security monitoring, backups and the maintenance that keeps a website trading. If you are not certain how every certificate on your domain is renewed, or who would hear first if one of them failed, we can run the inventory above, move the manual renewals onto automated issuance with monitoring, and hand you a register that will still be right in March 2027. Start with a conversation about where your certificates come from today.
Questions, answered
Frequently asked questions.
Yes, but usually invisibly. Managed hosts and content delivery networks already renew automatically and will simply renew more often as the limits step down. The thing to confirm is that the automatic renewal covers every hostname you use, not just the main domain, and that somebody independent of the host is alerted if a renewal fails.
Browsers show a full screen warning that the connection is not private and most visitors leave. Forms, payments, logged in portals and embedded tools stop working, and automated systems that call your website, such as payment callbacks or integrations, reject the connection. Search engines and advertising platforms can also flag the pages. The outage lasts until a new certificate is installed.
No. Every certificate a browser trusts is subject to the same lifetime limits regardless of price or type. What changes is the process: a certificate that is installed by hand must now be reinstalled several times a year, so the sensible step is to move to automated issuance through the ACME protocol, which most hosting platforms and certificate authorities support.
For encrypting the connection, a domain validated certificate from Let's Encrypt or an equivalent authority provides the same protection as a paid one, and browsers treat them identically. Some organisations still require organisation validated certificates for policy or procurement reasons; those can also be automated, but the validation steps are more involved and should be planned early.
Validity is how long a certificate works once issued. Domain validation reuse is how long the authority may rely on an earlier check that you control the domain before it must check again. Both are shrinking on the same schedule, to 100 days in March 2027, and from March 2029 validation reuse drops to 10 days while validity drops to 47, so proving control of the domain must be automated as well as the renewal itself.
Now, because the current 200 day limit already means two renewals a year for anything manual, and the next step to 100 days arrives on 15 March 2027. An inventory and a monitoring alert can be put in place in days. Moving manual certificates onto automated issuance, especially where load balancers, integrations or pinned apps are involved, is better done with months to spare than weeks.
Keep reading












