SSL Certificates Now Last at Most 200 Days. Who Handles the Next Renewal?
The invoice says SSL, one hundred twenty dollars a year, renewed, done. In a tab nobody opens, something much shorter is counting down on its own. The plan runs twelve months. The certificate inside it does not, and the gap between the two is where renewals quietly go to die.
The invoice and the certificate are two different animals
Three things are bundled into the phrase "our SSL," and they live on three different clocks. The plan term is a billing relationship: what you pay, for how long, to whom. The certificate is the actual object a browser checks on every connection, and it expires on its own schedule. Proof of domain control is the validation that gets redone each time a new certificate is issued, and it is the step people assume happened because the bill went through.
A browser does not read your invoice. It trusts the certificate that was actually deployed, and only for as long as that certificate says. So the question that matters is not what the invoice covers. It is who, specifically, is responsible for the certificate being renewed, deployed, and confirmed working once it is.
That is a different conversation from the SSL overview, where the point is what a certificate does. This one is about who does it.
The schedule is already set
The industry body that sets the ground rules for publicly trusted certificates, the CA/Browser Forum, has published a shortening schedule in its baseline requirements (as of the current text, checked November 2026): newly issued subscriber certificates are capped at 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. Issuers can always choose shorter lifetimes, so treat these numbers as ceilings, not a typical lifetime. See the CA/Browser Forum baseline requirements for the current wording.
Two things to hold onto. First, this is an issuance schedule. It does not retire every certificate on March 15; existing ones simply run to their own expiry dates, and each new one is shorter than the last. Second, a shorter certificate is not a worse certificate. Encryption does not degrade. What changes is the frequency of a task that somebody has to own, roughly six times a year instead of once.
A certificate does not wait for the quarterly review meeting. It simply stops being a certificate.
Three ways the renewal actually happens
Every setup lands in one of three arrangements, and they differ in who controls the three jobs: validation (proving the domain), deployment (putting the new certificate where traffic lands), and monitoring (noticing when it fails).
| Arrangement | Validates | Deploys | Notices failure |
|---|---|---|---|
| Platform-issued TLS | The platform | The platform | The platform, hopefully |
| Host-managed certificate | The host | The host, at the origin | You, if you set an alert |
| Organization-managed | Your team or agency | Your team or agency | Your team or agency |
The platform row looks free and it is, at the cost of control: if the platform is where the certificate lives, the platform is also where it fails, and you find out when a customer tells you. The host-managed row is where most small business sites live, and it carries the trap. The host renews at the origin, but traffic may land on a CDN in front of it, or on a subdomain with its own certificate, and the renewal can complete perfectly and still deploy to a place nobody checks.
Renewed is not the same as deployed. That is the whole argument in one sentence.
The owner's checklist
None of this prescribes which certificate you should buy. It prescribes one thing: a named answer to each of the five questions, written down before the first short-lived certificate forces you to find out.
- A responsible person by name. Not "the IT guy." A name, and a second name who knows where the first name is on a Tuesday afternoon.
- The renewal mechanism in one sentence. Which arrangement above, and with which provider, for the main domain and for every subdomain that serves HTTPS.
- An expiry alert that reaches a human. An alert delivered to an inbox nobody reads is the same as no alert. Six renewals a year means the alert has to be something a person will actually open.
- An alternate contact. The person who can act if the responsible person is the one who quit, got sick, or changed email addresses.
- A public check after every renewal. Load the site over HTTPS from outside the network, not from the machine that was just changed. The padlock and the date on the certificate, seen by a stranger, is the test.
Ten minutes, one document, no software. It is the smallest version of what a managed SSL service does for you continuously, and writing it down is the part that works no matter who you pay.
The lifetime of a certificate is no longer a product decision. It is a schedule the industry set, and it turns a yearly chore into a standing one. The invoice can stay annual. The accountability cannot. Decide who owns the next renewal while deciding it is still boring.
Certificate questions
Is an annual SSL plan still a thing?
Yes. The plan is a billing relationship and it can still run a year. What changed is the object inside it: the certificates issued against it now expire much sooner, more often. Paying annually no longer means the encryption is renewed annually.
Did every certificate expire in March 2026?
No. The 200-day cap applies to newly issued certificates from that date. Certificates issued earlier run to their own expiry, and the new ones simply get shorter as each milestone lands. Your site did not break on a single day.
Is auto-renewal enough?
Auto-renewal answers one of the three jobs: issuing. It does not deploy to a CDN that lives in front of the origin, and it does not notice a deployment that went to the wrong subdomain. "It renewed" and "it works" are different sentences.
Who checks the public endpoint after a renewal?
Whoever is named in the checklist. If the honest answer is nobody, that is also an answer, and it is the one this post exists to change. The check itself takes thirty seconds from any phone.
More from the blog
- What Uptime Numbers Actually Allow, the other promise that is quieter than it looks
- The First Hour When Your Site Goes Down, for when the certificate is not the thing that failed
- What Happens When Someone Types Your Address, the half second before the certificate matters at all
All posts are on the blog. For the step by step versions, see the domain and hosting guides.
Who owns your renewal?
Tell us how your site is served and we will tell you where the certificate actually lives, who renews it, and whether "it renewed" has ever been checked. If the answer is that your setup needs nothing, we will say that instead.