Certificates now expire sooner than the reminder you set
The padlock in the address bar is a certificate, and a certificate has an expiry date. For most of the last decade that date was about a year away, which fitted neatly into the way businesses handle anything annual: a reminder in a calendar, an invoice, half an hour of somebody's afternoon.
That arrangement stopped being possible in March 2026. The maximum life of a certificate is now shorter than a year, and it is scheduled to get shorter twice more. The dates were set in public, more than a year in advance, by the body where the browser makers and the companies that issue certificates agree the rules both sides follow.
The schedule is published, and it is below. The question that decides whether any of it lands on you is simpler: does renewing your certificate happen because a person remembers, or because a machine does it? For most businesses reading this, it happens by itself and nothing here needs acting on. For the rest, an annual habit has quietly stopped fitting the thing it was built around.
Is this your problem at all?
Probably not. It is worth settling that before anything else, because if your site sits on one of the big hosted platforms, your certificate is issued and renewed by the platform, and the schedule below never reaches you.
One vocabulary note before the table: vendors write SSL, or SSL/TLS, where this article writes certificate. Same thing, older name.
| Where the site lives | Renewed automatically? | What the vendor's own page says |
|---|---|---|
| Squarespace | Yes, if the domain points correctly | Certificates "refresh every 90 days" |
| WordPress.com | Yes | "Your domain's SSL certificate renews automatically when you renew your domain" |
| Cloudflare | Yes | Cloudflare "issues — and renews — free, unshared, publicly trusted SSL certificates" |
| Netlify, its own certificate | Yes | "Certificates are generated and renewed automatically as needed." |
| Netlify, a certificate you bought | No | A caution headed "Renewal is not automatic" |
| Vercel | Yes, once DNS is in place | Generates a certificate "for every domain once it is added to a project" |
| Azure App Service, managed | Yes, if prerequisites hold | "automatically renewed, as long as the prerequisites that you set up stay the same" |
| Azure App Service, uploaded | No | Renewal is yours; the page says only that "For an uploaded certificate, there's no automatic binding update." |
| AWS Certificate Manager | Depends on validation method | Renews automatically with DNS validation, or "send you email notices when expiration is approaching" |
The organisation shortening the lifetimes says the same thing to its own users. Let's Encrypt, announcing its own reduction from 90 days to 45, wrote: "Most users of Let's Encrypt who automatically issue certificates will not have to make any changes."
So who is left? Three groups, named precisely, because the rest of this is written for them. First, anyone who bought a certificate for a year from a reseller and installed it by hand - Namecheap's own page for that arrangement now tells such customers: "You'll simply need to reissue and reinstall each new file every 200 days." Second, anyone running a platform that renews what it issues but not what you upload, which is what Netlify and Azure both say in the table above. Third, everything that is not a public website at all: an internal tool on the office network, a mail server, a booking terminal, a piece of equipment with a web interface.
If none of that describes you, the rest of this is background. If any of it does, the arithmetic below is the part that changed.
What changed, and when?
The rule lives in a document called the Baseline Requirements, kept by that body - the CA/Browser Forum. The edition in force as this was written is version 2.3.0, dated 7 September 2026, and it carries a table of dates on which things change.
Three rows matter. "Subscriber Certificate" is the standard's name for the ordinary certificate sitting on a website - yours included.
| From | Maximum life of a certificate |
|---|---|
| 15 March 2026 | "Maximum validity period of Subscriber Certificates is 200 days." |
| 15 March 2027 | "Maximum validity period of Subscriber Certificates is 100 days." |
| 15 March 2029 | "Maximum validity period of Subscriber Certificates is 47 days." |
The first of those took effect on 15 March 2026, which is where the arithmetic below starts. The second falls two and a half years before the third, and the third is far enough out that nobody needs to plan for it yet.
The rule's actual wording is slightly stricter than the summary table, and the difference explains something you may see on an invoice. It reads: "Subscriber Certificates issued on or after 2026-03-15 and before 2027-03-15 SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days." Two hundred is the hard ceiling; a hundred and ninety-nine is the recommended one. That is why one certificate seller describes what it now offers as 199-day renewals while another writes about a sequence of 200-day certificates: both are inside the rule.
One consequence is already here rather than pending. A certificate issued on the first day of the new rule, for the longest term allowed, expires on 1 October 2026. That is the first wave of renewals arriving earlier than a yearly reminder expects them, and it lands in the autumn of 2026.
Why does a yearly habit no longer fit?
Turn the schedule into the only number that matters to somebody running a business: how many times a year the same job comes round.
| Maximum life | Renewals per year |
|---|---|
| 398 days, until March 2026 | 0.92 |
| 200 days, from March 2026 | 1.83 |
| 100 days, from March 2027 | 3.65 |
| 47 days, from March 2029 | 7.77 |
Under the old rule the job happened slightly less than once a year, which is why an annual reminder worked. It works now for exactly one cycle and then drifts, by five months a year, until the reminder and the deadline have nothing to do with each other.
The operational version of this is simple: renewal frequency roughly doubles, and whatever was being done by hand now has to be done twice as often. The practical answer is to build in slack rather than aim at the deadline - treat a 200-day certificate as a six-month one and renew at about the 180-day mark, leaving three weeks to recover if the renewal fails. Shorter lifetimes are not in themselves the risk; unprepared systems and manual processes are.
Which parts of your business still depend on somebody remembering a date? And what would each of them cost on the day it is forgotten? That is what the process audit settles: what can be automated, in what order, and what each piece is worth, in writing, in three business days.
The second clock, the one nobody mentions
The certificate's life is not the only thing shortening on that schedule. The same table cuts how long a certificate authority may re-use its earlier proof that the domain is yours.
The Baseline Requirements set that reuse period at 398 days before March 2026, 200 days from March 2026, 100 days from March 2027, and 10 days from March 2029. So the last step changes the nature of the work rather than its volume. When the certificate lasts 47 days and the domain check is only good for 10, proving ownership stops being an occasional errand and becomes something that has to run by itself.
For a business today, this is the part worth knowing rather than acting on. It explains why the certificate authorities have moved so firmly towards automation, and why advice that used to be optional - keep the renewal out of human hands - has hardened into the default recommendation from every certificate seller quoted here.
Who decided this, and on what argument?
This came through a ballot at the CA/Browser Forum, proposed by a representative of Apple and endorsed by Sectigo, Google Chrome and Mozilla. Voting closed on 11 April 2025. Among certificate authorities the result was 25 in favour, none against, with 5 abstentions; among browser makers, Apple, Google, Microsoft and Mozilla all voted in favour. Nobody voted against.
The reasoning is set out in the ballot itself, under the heading Benefits, and it explains why this will not be reversed:
Certificates are representations of a point in time state of reality. ... The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality. Thus, a reduction to both certificate lifetimes and data reuse periods increases the average net reliability of certificates.
A certificate says that on a particular day, a particular organisation controlled a particular domain. The longer that statement stands, the more likely it is to have stopped being true - the domain moved, the company changed hands, the key leaked. Shortening the statement's life is the cheapest available fix, and the cost of it lands on whoever renews.
One thing circulates as fact and is not one. Google Chrome, which decides for itself which certificates it will trust, has published a position paper proposing shorter lifetimes still, describing "our proposed maximum TLS server authentication subscriber certificate validity" as ninety days. Proposed. It is not a rule, and no browser currently enforces it.
What does your customer see on the day?
Not an apology, and not a maintenance page. If the certificate on your site does lapse, modern browsers treat it as a possible attack, and they say so in those words.
The full-page warning Chrome puts up instead of your site is headed "Your connection is not private", and the paragraph under it reads: "Attackers might be trying to steal your information from ... (for example, passwords, messages, or credit cards)." The only way past it is a link labelled "Proceed to ... (unsafe)". Firefox's version is headed "Warning: Potential Security Risk Ahead", and for this specific cause it explains that "Websites prove their identity via certificates, which are valid for a set time period", and then names the date yours expired.
Somebody who has decided to book an appointment, pay an invoice or send you a document is told, in the browser's own voice, that their passwords and card details may be being stolen at your address, and is offered the option of continuing at their own risk. A fair number of them will close the tab and not mention it to anyone, which is why an expired certificate so often surfaces as a quiet week rather than as a complaint.
What breaks that nobody sees at all
The visible half is the browser. The invisible half is every system that talks to yours without a person watching, and there the failure produces no screen at all.
Stripe lists an error for exactly this - TLS is the machinery behind the padlock, and a TLS error is what its systems get instead of a page - and states the cause plainly: "Issues with the SSL/TLS certificate or an intermediate certificate in the destination server's certificate chain usually cause these errors." The mechanism is not the part to hold on to. What follows is: "Stripe attempts to deliver events to your destination for up to three days with an exponential back off in live mode." Three days of retries, and then the event is gone. The payment went through. The message telling your systems about it did not.
Error 11236 exists for exactly this. A webhook, in Twilio's wording, is the address your systems gave it to call, and the code is what "Twilio returns ... when it makes an HTTPS request to your webhook or callback URL and the endpoint presents an expired certificate."
Shopify's version is the one that outlives the outage. Its documentation states that Shopify "verifies SSL certificates on delivery", that if it "receives no response or an error, it retries 8 times over the next 4 hours", and then: "After 8 consecutive failures, the subscription is automatically deleted if it was configured using the Admin API." Four hours of failure, and the arrangement that sends you your own orders is removed. Fixing the certificate does not bring it back, because there is no longer anything to deliver to. This is where an integration that stops sending without saying becomes permanent, and where a failure nobody was told about stops being recoverable - and it is one reason the certificate on a shop is worth knowing the owner of, even when the shop is somebody else's platform.
Email has a narrower version of the same problem, and the exact wording is what limits it. Under the standard called MTA-STS, a sending mail server that finds a policy set to "enforce" must not deliver to a host whose certificate fails validation, and the specification is explicit that the receiving server's certificate "MUST not be expired". That only bites when the other side publishes such a policy in enforcing mode. It is not a general rule that mail stops.
The reminder email is no longer a given
For years the safety net under all of this was a message from whoever issued the certificate, a few weeks before expiry. That net has holes in it now, and one of the largest issuers removed its own.
Let's Encrypt announced on 22 January 2025 that "Since its inception, Let's Encrypt has been sending expiration notification emails to subscribers that have provided an email address to us. We will be ending this service on June 4, 2025." Its reasoning was that automation had won: "Over the past 10 years more and more of our subscribers have been able to put reliable automation into place for certificate renewal." For anyone who still wanted the messages, it pointed at a third-party service. On 26 June 2025 it confirmed the service had ended.
Ten months after that first announcement, and now announcing shorter lifetimes, the same organisation was blunt about the consequence: "Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes", and "We also recommend that you make sure your systems have sufficient monitoring in place to alert appropriately if certificates aren't renewed when expected." The advice is correct. It also lands on people who no longer receive the email that used to be their monitoring.
What that looks like in practice is a site owner who never found a replacement for the reminder email, received no notice, missed the date, and discovered the expiry when the website stopped loading - unable even to post a notice about it, because the notice would have gone on the site that was down. Two things have to go wrong for that to happen, and the first of them is that nothing said the date was coming.
Plenty of providers do still send reminders. DigiCert warns five times - "90, 60, 30, 7, and 3 days before a certificate expires and seven days after a certificate expires". Namecheap warns four: "to the account email address 30, 15, 7 and 1 day prior to the expiration date". AWS Certificate Manager either renews for you or emails when expiry approaches. Whether anybody warns you is now a property of who you bought from, and which yours is, you should find out before you need to.
Issued or bought is the real dividing line
Reading through a dozen hosting providers, the split runs between a certificate the platform issued and a certificate you handed it. Good platforms and bad ones sit on both sides of it.
Netlify says both halves on the same page: its own certificates "are generated and renewed automatically as needed", and then, under a caution headed "Renewal is not automatic", that "When the time comes to renew your custom certificate, Netlify cannot do this automatically." Azure App Service draws the line in the same place. A managed certificate is "automatically renewed, as long as the prerequisites that you set up stay the same", while an uploaded one is left to you - the page notes only that "For an uploaded certificate, there's no automatic binding update."
There is a quieter category, too. Shopify and Wix both document that a certificate is issued automatically for a connected domain, and neither page says anything at all about renewal - the word does not appear. That is an absence in documentation rather than evidence of a problem, and it is a reasonable thing to ask your provider directly rather than assume in either direction.
If your automations and integrations are written down anywhere - and a register of what is automated is where this belongs - the useful column is whether each certificate is issued by the thing hosting it, or installed by a person. Where the answer is "a person", the follow-up is who, and whether they still work with you: exactly the question a handover checklist is supposed to have settled.
Organisations with staff get this wrong too
It would be comforting to think this is a small-business problem solved by having an IT department. It is not, and the schedule itself explains why. A one-year certificate bought in early 2025, under the old rules, runs out in early 2026 under the new ones - and its replacement cannot be bought for a year. Every organisation that renewed annually has a batch of certificates whose next renewal falls on a date nobody's calendar was built around.
The second reason is the assortment. Automated renewal is well supported for the public website and poorly supported for a good deal else: internal tools, mail servers, VPN gateways, devices, the older service somebody set up years ago. An organisation with a modern stack might have automated a fraction of what it runs; one with more legacy platforms is close to "nothing supports automated renewal".
That is the real shape of the problem. Not the website, which is usually handled, but the assortment of other things that also present a certificate and were never part of anybody's renewal routine.
What should you check this week?
Four questions. None of them requires knowing how any of this works.
- Ask who renews the certificate on your website. The answer is either the name of a platform or the name of a person. If it is a platform from the table above, you are finished. If it is a person, ask when it next expires, and put that date somewhere other than their head.
- List the things that are not the website. A booking system on its own address, a customer portal, a staff login page, a mail server, anything with a web interface bought as a box. Each one presents a certificate, and each one was set up by somebody who may not be around.
- Find out whether a reminder email still arrives, and where. Not whether your provider sends one - which address it goes to. An address at an agency you stopped working with is not a reminder.
- Ask what your payment provider and your shop do when they cannot reach you. The specific answers in this article - three days of retries at one, a deleted subscription after four hours at another - are the difference between a bad afternoon and a job of work in the following week.
None of that renews anything. It converts an invisible date into a named owner, which is the whole of what is being asked here.
When this stops being a hosting question
For a business with one website on a hosted platform, this is genuinely nothing. The platform renews, the schedule shortens, and no one notices, which is what good infrastructure looks like.
It becomes something else at the point where you cannot say how many things in your business present a certificate, or who renews each one. Encryption is the small half of that. It is the same question as who holds the passwords, who receives the failure emails and what happens when the person who set it all up moves on - the ordinary problem of a business whose systems have outgrown the map anybody is holding.
If you would rather have somebody find where that has happened and work out what is worth putting on rails and what each piece is worth, that is the process audit. $299, three business days, and a written map you keep whether or not you hire us.