Your website's security certificate now expires twice as often, and nobody emails you about it
Since March 15, 2026, the maximum life of a public TLS certificate is 200 days, down from 398. It drops to 100 days in March 2027 and 47 days in March 2029. The first wave of 200-day certificates comes due around October 1. Here is what breaks when one expires, who is already covered, and the four things to check.
There is a small padlock next to your website address. Behind it is a file called a TLS certificate, and it has an expiry date on it the way milk does.
When it expires, your site does not get slower or look slightly off. Every visitor gets a full-page red warning saying the connection is not private, with your domain named in it. Most people close the tab. Chrome and Safari make it deliberately awkward to click through, because the warning exists for the case where somebody really is intercepting the connection, and the browser cannot tell the difference between an attack and an administrator who forgot.
The rules about how long those certificates last just changed, and they are going to keep changing until 2029. If your site is on a modern managed host, this is a non-event and you can stop reading after the next two sections. If any part of your setup involves a person manually installing a certificate file, it is a recurring outage waiting for a date.
What changed
In April 2025 the CA/Browser Forum, the body where certificate authorities and browser makers agree on the rules both have to follow, passed ballot SC-081v3. It was proposed by Apple, endorsed by Sectigo, Google Chrome, and Mozilla, and passed with no votes against. It sets a staircase that cuts the maximum life of a public certificate from 398 days to 47 over three years.
| From | Maximum certificate lifetime | Maximum domain validation reuse |
|---|---|---|
| Before March 15, 2026 | 398 days | 398 days |
| March 15, 2026 | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
The first step already happened. Since March 15 of this year, no certificate authority is allowed to issue a public TLS certificate valid for more than 200 days. In practice several of them issue slightly under the cap to leave themselves margin: DigiCert moved to a 199-day maximum on February 24, 2026, one day short on purpose.
The second column matters less to most people but explains a chunk of the work. Domain control validation is the step where the certificate authority proves you actually control the domain, usually by asking you to publish a DNS record or serve a file. That proof used to be reusable for over a year. It now expires on the same staircase, and by March 2029 you will be re-proving domain control every 10 days.
Certificates issued before March 15, 2026 keep their original validity until they expire. That is why this has felt like nothing so far. The old 398-day certificates are still out there running out the clock.
Why they did it
Two reasons, and both are more sensible than they look from the outside.
The first is that revocation does not work. When a certificate’s private key is stolen, the fix is supposed to be revoking the certificate so browsers stop trusting it. In practice the mechanisms for checking revocation have been unreliable for two decades, and browsers largely fail open rather than break your site over a check they could not complete. A shorter lifetime is the fallback: if the certificate cannot be reliably revoked, at least it stops working on its own reasonably soon. Going from 398 days to 47 cuts the window in which a stolen key is useful by roughly eight times.
The second is honestly the point of the exercise: shorter lifetimes force automation. Anything a person has to do twice a year eventually gets forgotten, and the industry has decided the way out is to make the interval short enough that manual processes become obviously untenable. At 47 days, nobody is renewing certificates by hand. That is the intended outcome, not a side effect.
Why this lands in the next few weeks
Do the arithmetic on the first step. A certificate issued on March 15, 2026, the first day of the 200-day cap, expires around October 1, 2026. Certificates from the major authorities that shaved a day off expire a day sooner.
So the entire first cohort of shortened certificates comes due in a cluster starting late September. Nick France, Sectigo’s CTO, has called September and October the wake-up call for organizations that were not ready for the higher renewal frequency, and the reason is exactly this: it is the first time a lot of teams will discover their renewal process was actually one person’s calendar reminder, and that person changed roles in June.
If you did not think about this in March because nothing broke, that is because nothing was supposed to break in March. It breaks in October.
The email that used to save you
For years the safety net for a forgotten certificate was the warning email. Your certificate authority would write to you at 30 days, 14 days, and 7 days out, and someone would panic in time.
Let’s Encrypt, which issues certificates for a very large share of the small business web, ended that service on June 4, 2025. It cited the cost of running it, the privacy cost of retaining millions of email addresses, and the fact that most subscribers now automate renewal anyway. All three are fair. It still means that if your renewal quietly fails today, there is no longer anything that tells you except your customers.
Let’s Encrypt is also moving faster than the industry floor requires. Its plan, published in December 2025, is a 45-day certificate on the opt-in tlsserver profile from May 13, 2026, a 64-day default from February 10, 2027, and a 45-day default from February 16, 2028. The replacement for the warning email is a protocol feature called ARI (ACME Renewal Information), which lets the certificate authority tell your renewal software when to renew, including early if something has gone wrong on their end. It is a better mechanism than email in every way except one: it only helps if you are running software that speaks it.
Who is already fine
If your site is hosted on a platform that issues and renews certificates for you, this whole change is somebody else’s job and they have already done it. That covers most of what a small business actually uses:
- Vercel, Netlify, Cloudflare Pages, Render, Fly
- Shopify, Squarespace, Wix, Webflow
- Managed WordPress hosts (WP Engine, Kinsta, and similar)
- Anything behind Cloudflare with their certificate in front of it
- Most cPanel hosts, which have run AutoSSL for years
Our own site runs on Vercel, and the honest answer to “what did AuraByt have to do about the 200-day change” is nothing. The certificates rotate without anybody watching. That is the correct amount of attention to pay to this problem, and it is worth stating plainly because the certificate management industry has an incentive to make you feel otherwise.
Who is not fine
The risk is concentrated in the things that are not your marketing website:
- A VPS or dedicated server you rent, where somebody installed a certificate once. If it was set up with certbot and a cron job, you are probably fine. If it was set up by pasting a
.crtfile into a config, you are not. - Windows Server and IIS. Certificate renewal here is manual by default. There is good ACME tooling for it, but somebody has to have installed and configured that tooling.
- Network appliances. Firewalls, VPN gateways, NAS boxes, remote-access portals, mail servers, printers with web interfaces. These almost never automate certificate renewal, and their expiry tends to break the thing you use to fix things.
- Load balancers and reverse proxies sitting in front of an otherwise automated setup, holding their own separately managed certificate.
- Internal tools. The staff portal, the booking admin, the reporting dashboard. Nobody notices these are broken for a day, which is precisely why they stay broken.
- API integrations and payment callbacks. Machines do not click past certificate warnings. A payment provider or a partner system posting to your endpoint will simply fail, usually silently, and often without an alert on your side.
That last category is where an expiry stops being embarrassing and becomes expensive. In December 2018 an expired certificate inside Ericsson’s mobile core software took O2’s network down across the UK, cutting off around 32 million subscribers, and hit SoftBank in Japan the same day. The equipment was not compromised or attacked. A date passed, and by design the software refused to keep running.
What to actually do
Four things, in order, and the whole exercise is an afternoon.
1. Find out what you have. List every hostname your business serves over HTTPS, including the ones you forgot: the staging site, the old domain that redirects, mail., the VPN endpoint, the internal dashboard. For each one, note who issues the certificate and what renews it. If the answer to the second question is a person’s name, that is your finding.
2. Automate anything that is manual. For nearly everything, this means an ACME client (certbot, acme.sh, win-acme on Windows, or whatever is native to your platform) on a schedule, renewing at roughly two thirds of the certificate’s life rather than at a fixed number of days. Fixed intervals are what break when the lifetime changes underneath you, and it is going to change again in March 2027.
3. Monitor expiry independently of whoever issues the certificate. This is the part people skip, and it is the part that actually catches failures. Automation that silently stopped working nine weeks ago looks exactly like automation that is working, right up until it does not. An external check that alerts you at 21 and 7 days out costs nothing and is the only thing standing between a failed renewal and a Saturday morning.
4. Write down who is responsible. Not the vendor, a person at your business who gets the alert. Certificates are the classic thing that everyone assumes somebody else handles.
The one email to send
If you do nothing else with this, send this to whoever maintains your website and to your IT provider if they are different people:
Can you give me a list of every hostname we serve over HTTPS, when each certificate expires, and what renews it? For any that renew manually, what would it take to automate them before October? And do we have alerting if a renewal fails?
If the answer comes back in a day with a clean list, you are in good shape and you can ignore the 100-day change in March 2027 entirely, because a setup that survives 200 days survives 100.
If the answer is vague, or the list turns out to be longer than anyone expected, you have found something worth fixing now rather than at 6am on a Sunday in October. This is one of those problems that costs an afternoon on a schedule and a very bad day otherwise, which is the same shape as keeping your runtime versions current and patching the appliances at your network edge. The pattern is not a coincidence. Most of what actually takes a small business offline is a maintenance item that was never assigned to anybody.
Update, August 20, 2026: the deadline above now has a second half
Two dates are about to land on top of each other, and they compound.
The first cohort of 200-day certificates comes due around October 1, as described above. Chrome 154 arrives on September 22, and it turns on “Always Use Secure Connections” for every Chrome user by default, which means Chrome shows a full-page warning before loading any public site it cannot reach over HTTPS. Google’s original announcement said October 2026; Chrome’s move to a two-week release cycle starting September 8 pulled the date forward by a few weeks. We wrote up the details, including what is exempt, in the post on Chrome’s HTTP warning, and the cadence change itself in the post on every browser going biweekly. That second one is worth a look if you keep a maintenance calendar: browser version numbers stopped being a rough proxy for months in September, which is exactly how this date moved without the announcement changing.
This does not change any of the advice above, and it does not change what an expired certificate does to someone who follows an https:// link. That has always been a hard error page and still is. What it changes is the last silent path into your site. Today, a visitor arriving through an http:// link, which is what old QR codes, printed material, directory listings, and years of accumulated backlinks still contain, gets upgraded to HTTPS by Chrome automatically, and when that upgrade fails because the certificate expired, Chrome quietly drops back to plain HTTP and serves the page anyway. From September 22 that fallback becomes a warning instead.
So a failed renewal used to cost you the visitors on https:// links and quietly keep the rest. After Chrome 154 it costs you both. The first weekend of October is now the worst timed version of this problem available in 2026.
Send the email in the section above this week rather than in September.
If you are not sure what your site runs on or who renews its certificates, send us a note. Working out what you have is usually a short conversation, and it is a better use of an hour than finding out from a customer.