The certificate ACME doesn't renew is the one that kills your VPN

Do the arithmetic: 15 March 2026, the day the 200-day ceiling for public TLS certificates came into force, plus 200 days. That lands on 1 October 2026. Today. The first certificates issued under the new rule start expiring this week, and with them ends the stretch of the calendar in which this was a 2029 problem.

We are a network operator in our own right: we run BGP, transit and peering, site-to-site tunnels over WireGuard, multi-site SD-WAN, and the documentation for all of it in NetBox. Which is why the short-certificate conversation interests us from a different angle than the usual one. Almost everything written about the 47 days is about websites, and on websites this has been solved for years and renews itself. The certificates that cause trouble are elsewhere in the rack: the firewall's admin portal, the VPN gateway people come in through, the RADIUS box signing EAP-TLS for the corporate wifi, the load balancer. Those are renewed by a person, by hand, off a calendar reminder.

The four dates, lined up

The calendar was set by the CA/Browser Forum — the body where certificate authorities and browser vendors agree the rules of public trust — through ballot SC-081v3, passed on 11 April 2025. Two columns, not one: how long the certificate may last, and how long the domain validation may be reused.

The 47 is a sum, and it is worth knowing because it explains the design: 31 days (one of the long months) plus 15 (half a short month) plus 1 of slack. It is sized so that a monthly renewal fits, with room for one attempt to fail and be retried. The 200 is built the same way out of six months: 184 plus 15 plus 1. The vote was 25 certificate issuers in favour, none against, five abstaining; and all four certificate consumers — Apple, Google, Microsoft and Mozilla — in favour. This is not something you negotiate with your provider, because your provider voted in favour too, or abstained.

2029 is not your date. Nor is 15 March 2027, exactly

There are 165 days left before the ceiling drops to 100. And there is a detail that changes how you plan for it: the Baseline Requirements are written by date of issuance, so the steps are not retroactive. Each one applies to certificates issued on or after its date; earlier ones keep their validity until they expire. A certificate issued on 14 March 2027 is born with a legitimate 200 days and stays alive until 30 September that year.

That sounds like good news. It is the opposite. If everything broke at once on 15 March 2027, you would have a date on the calendar and a committee deciding what to do before it. What will actually happen is that the pressure arrives in stages and without a marked day: each certificate changes regime when its own renewal comes round, spread across 2027, and each one is individually too small to justify a meeting. Changes with no date end up with no owner, and in March 2027 there will be nothing on anybody's calendar.

The arithmetic, with the assumptions on the table

Take a modest estate and let us declare the assumption: 14 public certificates. It is not any client's figure, it is an example number, and in a 40-person company with two sites you get there without effort between the corporate website, mail, a customer portal, two reverse proxies, the VPN gateway, the firewall portal, the RADIUS box, the test environment and a device or two more. Dividing 365 by each validity:

And that assumes you renew on the last day, which nobody does: automated clients renew early so they have room if an attempt fails, so the real figure is higher. Thirteen a year you handle with a reminder. Fifty-one, you do not — and not because it is many hours, since renewing is quick. The cost of a recurring task sits in remembering, in the person who remembers being there that day, and in nobody assuming someone else did it.

Why ACME cannot reach the firewall: because you segmented properly

This is the part that decides your work for the next three years. The standard answer is "automate with ACME", and it is correct: there is plenty of documentation, and firewall vendors have published theirs for years. The question that documentation does not ask is where you can automate.

For an authority to issue you a certificate it has to verify that you control the domain, and the two convenient methods verify it from the outside: http-01 needs to reach your port 80 from the Internet, tls-alpn-01 your 443. A web server passes both without thinking, because being published is literally its job. Now say the same about your firewall's admin portal. That device is deliberately not reachable from the Internet: it not being reachable is the result of having done things right, and it is among the first things any serious network review looks at.

From which follows an uncomfortable and, we think, true conclusion: the better segmented your network, the worse your position against the certificate calendar. The company with everything hanging off a public reverse proxy automates in an afternoon. The one that separated its management plane, put it behind a VPN and publishes nothing that does not need publishing finds that its own good practice is what stops it validating the easy way. Before anyone reads this backwards: the way out is not to publish the firewall. It is to accept that the work ahead of you does not look like the work the guides describe.

The remaining path, and the new risk it brings

For those devices dns-01 remains: validation happens by publishing a TXT record at _acme-challenge in your zone, and it works even if the device is reachable from nowhere. It is the right method and it is the one to use. And it has a second half the guides mention in passing: it means handing a script credentials to write to your public DNS. You have solved a renewal problem by creating a key that, if it leaks, lets someone rewrite where your domain points. On a scale of things you do not want to lose, a token with write access to the zone sits above the certificate itself.

The answer to that is not caution, it is scope, and the recommended practice has been documented for years: delegate _acme-challenge with a CNAME to a separate zone dedicated to nothing else, and give the renewal client a token with permission over that zone and nothing more. If it leaks, someone can issue certificates for that name — serious, yes — but not move the MX records or the A. What almost never gets done is the other half: writing down which token has rights over which zone in the same place as the rest of the network's truth, rather than in the head of whoever set it up. We already wrote about why a network needs a single source of truth and why the spreadsheet lies; a DNS token with write permissions is exactly the kind of object that ends up with no documented owner.

There are two more things the previous paragraph left out, and neither is minor. First: ACME not only needs to be reached, it needs the device to get out to the authority's server. A properly isolated management plane does not have that path open either, so deciding where that traffic exits — and writing it down — joins the work list. Second: several vendor-embedded ACME clients do not implement dns-01. Cisco's, on their firewalls, only documents http-01 — and the fix the vendor itself proposes says a lot about the size of the problem: the device opens port 80 for the duration of the challenge and closes it when enrolment finishes. In other words, Cisco's answer to "my firewall is not published" is to publish it for a while. Anyone unwilling to do that has to issue the certificate elsewhere and push it into the appliance, and then the comfortable path is not available either.

And after all that there is still installing it, which is a separate step and the one separating teams that have this solved from teams that think they do. On a web server you copy the file and reload the service. On a network appliance you go in through its API, upload it, bind it to the right service and, on some, restart the daemon — with the charming detail that this sometimes drops active management sessions, including yours. It is a piece of development per equipment vendor you own. You do it once and it stays done, but it has to be done.

Half the list should not be in the public chain at all

And here is the part that runs against what is being written these months. This whole calendar applies to publicly trusted certificates: the ones any browser accepts without having been taught anything. The internal admin portal of a firewall, opened by four people from a management network, does not need that. Your own CA has no 47-day ceiling, never had one and will not get one, because the CA/Browser Forum rules do not reach it.

So for part of the inventory the right answer is not "automate faster", it is taking it off the clock: fewer certificates subject to the calendar, and the ones that remain genuinely automated. Said with the catch up front, because otherwise this reads like a free lunch: your own CA is not free. You become responsible for distributing and rotating the root on every device that has to trust it, and that is a job with its own way of failing the day a new laptop does not have it. The rule we use to decide is simple: if a browser you do not control opens it — a customer, a supplier, somebody's phone — public trust and ACME. If only your own people open it from your own machines, your own CA, and the clock stops applying.

What you cannot dodge: validation drops to 10 days

The right-hand column of the table is worth reading carefully because it is easy to misread. The reuse period does not require revalidating every 10 days: it says that the validation you issue with cannot be more than 10 days old. Validations per year still equal issuances — with 47-day certificates, around eight per name — so the count is not the problem.

What dies is something else, and it is subtler: the pattern of validating once and then issuing for months without touching validation again. Today, with 200 days of reuse, you can validate in March and issue in September — adding a name, rotating a key, replacing a certificate somebody deleted — without the validation path having to work that day. From 2029, no longer: every issuance, including the emergency one at two in the morning, requires a validation less than 10 days old. What changes in nature is the validation path, which goes from something you set up once to a production dependency that has to work on the bad day. If the TXT record is published by hand, that day there is no certificate.

There is a piece of the standard pointing the same way, and it is worth knowing about. In June 2025 the IETF published RFC 9773, the ACME Renewal Information extension: the authority's server tells the client when it should renew, instead of each client deciding on its own with a fixed percentage. It exists to spread load, and also so an authority that has to revoke in bulk can ask its whole base to renew early at once. It is an engineering detail, but it says where this is going: the client stops keeping the calendar.

The most predictable failure in all of IT

We repeat one idea a lot: failure is inevitable, an outage is a design decision. An expiring certificate is the extreme case of that, because here the failure is not even inevitable: it is scheduled. The exact date is written inside the certificate itself, in a machine-readable field, months in advance, and anyone can read it with one line of openssl from the other side of the Internet. There is no better-announced failure in the whole of computing.

And it takes companies down every month. That is not a certificate problem, it is a diagnosis: if your organisation does not handle well a failure whose exact instant is published in advance, the conversation about unpredictable failures is arriving early. The mechanism is the same one we described with the redundancy that assumes the spare arrives tomorrow: what fails is not the component, it is the assumption nobody wrote down. Here the assumption is "somebody will remember".

That said, expiry alerting has a trap worth naming: at 47 days, a "30 days left" warning fires before the automated client has even attempted a renewal, and what it trains your team to do is ignore it. If you are going to measure this, measure what matters — that the automated renewal happened — and not the calendar. It is exactly the problem of alert fatigue and monitoring that actually warns you, with thresholds inherited from when certificates lasted a year.

Four columns, not twenty steps

The only thing needed before March is not a project. It is a table of the public certificates you have, with four columns, because the four together decide by themselves what to do with each row:

The table takes a morning to fill in and you do not have to buy anything to do it. The uncomfortable part arrives at the end, when there are usually rows in column 2 that never needed to be in the public chain, and two or three in column 3 that name somebody who is on holiday in August.

The limits of what we have just said

The 1st of October is not a date on anyone's official calendar: it is the result of adding 200 days to 15 March 2026, and it only affects whoever issued on that day at the maximum validity. If you issued in April, your date is a different one; the arithmetic is the same and your openssl does it, not this post. The 14 rows in the example are a declared assumption, not anybody's data. And the SC-081v3 schedule is what was published on 1 October 2026: the CA/Browser Forum votes continuously, and what governs is the current text of the Baseline Requirements, not an article.

Nor are we against the change, which is what people tend to expect from someone writing this from the operator's side. Short certificates are good: a compromised key stops being useful in weeks rather than in thirteen months, and revocation has never worked well in practice, so shortening lifetimes is the only lever that really works. What we are criticising is not the schedule: it is that it gets told as though the only place a certificate lives were a web server.

And the conflict of interest, stated up front: operating somebody's network and keeping that inventory is work we bill for. If that table already exists in your company, is dated, and no row in column 3 names a person, you do not need us for this.

Sources (verified on 1 October 2026): the ballot, its result (25 issuers in favour, 0 against, 5 abstaining; Apple, Google, Microsoft and Mozilla in favour) and the scope of the change — CA/Browser Forum Ballot SC081v3; the full schedule of validity (398 / 200 / 100 / 47) and of validation reuse (398 / 200 / 100 / 10) with their dates, the breakdown of 47 as 31 + 15 + 1 and of 200 as 184 + 15 + 1 — DigiCert, a certificate authority and a voter on the ballot; that the steps are written by date of issuance (and are therefore not retroactive) — the current text of the TLS Baseline Requirements, §6.3.2 (validity) and §4.2.1 (validation data reuse); that the first batch of 200-day certificates expires in early October 2026 — Sectigo; that the ACME client on Cisco firewalls only validates via http-01 and opens port 80 for the duration of the challenge — Cisco Secure Firewall Management Center documentation; the extension letting the authority signal when to renew — RFC 9773, ACME Renewal Information (IETF, June 2025). The http-01, tls-alpn-01 and dns-01 validation methods and their reachability requirements are those of the ACME protocol; the CNAME delegation of _acme-challenge and the public-trust-versus-private-CA criterion are our own practice, not a Forum recommendation.