Workshop

Nobody Tells You When the CA Rules Change

Published on: 2026-07-09

By: Ian McCutcheon

Nobody Tells You When the CA Rules Change

Your certificate renewal failed last night. The one that's renewed itself without a hiccup for three years. Nobody touched the server, nobody touched the DNS, the change calendar is empty — and yet here you are, reading a validation error at 7 a.m. and wondering who broke what.

Probably nobody broke anything. The rules changed. They've been changing on a published schedule for almost two years now, and unless certificate policy is your actual job, nobody sent you the memo.

This is the memo. Here's where things stand as of July 9, 2026 — four changes, plain language, sources at the bottom so you don't have to take my word for any of it.

One: certificates live shorter now

Maximum certificate lifetime dropped to 200 days this past March. It drops to 100 days in March 2027, and lands at 47 days by 2029 — with the validation work behind each certificate reusable for only 10 days. The era of "renew it annually and forget it" is over, and the manual-renewal workflow that limps along today will simply not survive the math. I wrote up what that means for how you prove domain control — which methods died, which survived, and where to place your bets — in Domain Validation in the 47-Day Era.

Two: the CA checks from more than one place now

Since September 2025, a CA can't validate your domain from a single vantage point anymore. It has to look from multiple network perspectives around the world and get corroborating answers — the industry calls it MPIC, multi-perspective issuance corroboration. The quorum keeps ratcheting up: four remote vantage points as of this June, five by December.

The security reasoning is solid — an attacker who can poison DNS near one CA data center shouldn't be able to mint certificates. But flip it around and look at the operational side: if your nameservers give different answers depending on where the question comes from — a stale secondary, a lagging zone transfer, geo-split DNS that wasn't supposed to apply to this record — that inconsistency used to be invisible. Now it's a failed issuance. Sectigo's MPIC FAQ is the best short read; check the reading list below for more.

Three: the CA validates DNSSEC now — no longer optional

Since March 15, 2026, CAs are required to validate DNSSEC on the DNS lookups they make during issuance — the CAA policy checks and the domain-control checks both. If there are broken signatures anywhere along the path they walk, the lookup fails. Not "logs a warning." Fails.

If you run signed zones — and I do, and I've written three parts on why you should — this is good news with teeth. Your signatures were always a promise; now there's a well-funded third party checking that promise on every single issuance, from five directions at once.

Four: for signed zones, "it didn't answer" means no

This one's the sleeper, and it's been in the Baseline Requirements all along. When a CA's policy lookup fails outright — timeout, server error, whatever — the CA is allowed to shrug and issue anyway only if your zone has no DNSSEC chain to the root. Signed zone? No shrug. A failed lookup is treated as a refusal.

Read that again, because it's the rule that turns other people's DNS problems into your certificate outages.

The trap, walked end to end

Let's slow down and walk the exact failure, because this is the part that gets misdiagnosed — and because the people who get paged for it usually own systems that are working perfectly.

The setup, and notice that every choice in it is correct: your zone is signed, the DS chain to the root is intact, and you've published a CAA record at the apex naming your CA. And app.yourcompany.com is a CNAME to tenant-xyz.vendor-platform.example, because that's exactly what the vendor's onboarding doc told you to do. Signed zone, explicit policy, standard integration. Textbook.

Renewal night. Before issuing, the CA has to check CAA for app.yourcompany.com. Watch the queries:

  1. The CA's validating resolver asks for CAA at app.yourcompany.com.
  2. The answer at that name is a CNAME — and CAA lookups ride ordinary DNS resolution, Let's Encrypt says it plainly, so the query follows it. It has now left your DNS. Your signed zone, your careful CAA record: not consulted yet. The answer to a question about your name is about to come from infrastructure you've never seen. (Who controls the policy in that arrangement is its own rabbit hole — I wrote that one up separately.)
  3. What happens next depends entirely on the vendor zone's DNSSEC posture, and this is the short-circuit:
  4. Cleanly unsigned vendor zone: fine — genuinely fine. DNSSEC has a proper way for a branch to opt out: the parent's signed denial proves there's no DS record, the resolver marks the answers "insecure," and accepts them. Empty CAA at the target? The lookup climbs back up your name, finds your apex CAA, your policy governs, issuance proceeds. Nothing broke, because nothing was broken.
  5. A vendor zone that claims DNSSEC but is broken: a stale DS left over from their last provider migration, expired signatures, or the classic — nameservers that sign real answers fine but botch empty ones, and a CAA query is almost always answered empty (that bug class is common enough Let's Encrypt documents it). There's a subtler flavor too: a signed parent delegating to a legitimately unsigned child, but botching the proof that the delegation is unsigned — the child did nothing wrong, the validator just can't prove it, so it's treated as broken anyway. Either way the resolver gets provable garbage: SERVFAIL. The CA just failed a CAA lookup for your name.
  6. A vendor zone that fails without DNSSEC's help: an authoritative server that answers A-record queries all day but chokes on the CAA query type itself — REFUSED, a half-formed response, an answer that never comes. No signatures involved, same net result: a failed lookup. (Plain timeouts live here too, but in practice the incomplete-and-refused family is what you'll actually see.) And intermittent versions of any of these are worse than solid breakage — it renews clean twice and then doesn't.
  7. Here's where your good hygiene turns on you. The rules let a CA treat a failed lookup as "no policy, proceed" only for zones with no DNSSEC chain to the root. Your zone is signed — so the CA is required to refuse. Sit with that fringe for a second: the unsigned world gets failure-forgiveness, and you, who did everything right, are held to the strict standard. Signing your zone raised the bar for every lookup made about your names — including the ones that ride your CNAMEs into zones you can't see.
  8. And since MPIC, this whole dance runs from four or five vantage points at once. Any one of them catching the vendor's bad answer can sink the corroboration.

Then the error report lands, and it says: CAA lookup failed for app.yourcompany.com. Your name, front and center. Your DNS team checks their zone — signed, serving, validating, perfect. Because it is perfect. The broken thing is one CNAME hop away, in a zone nobody in your building can log into, run by whoever your vendor outsourced DNS to. Your DNS team isn't responsible for somebody else's DNS — and no amount of staring at your own zone files will find this one.

And change one is the multiplier on all of it. This trap existed years ago — but a 398-day certificate walked into it once a year, usually with a human watching the renewal. A 47-day certificate walks into it every few weeks, on an automated loop nobody's watching. The rules didn't just get stricter; they get enforced more often every year from here on out.

The trap as a flowchart: the CAA query follows the CNAME out of your DNS; the vendor zone's DNSSEC posture forks to issued, SERVFAIL, or refused-incomplete; failed lookups meet the signed-zone rule — unsigned is forgiven, signed is refused

Whose problem is this?

Not the DNS team's — let's be precise about that. A DNS team running DNSSEC is, almost by definition, a team that knows what it's doing. Everything they own is signed. Everything they own validates. Everything they own works. This failure doesn't live in anything they own.

It lives in the seam between certificate issuance and DNS — and the seam has an owner. If you run the certificate function, the validation chain is your domain now: how CAA gets looked up, what the CA does when it meets a CNAME, what DNSSEC does to a failed answer, what five vantage points mean for consistency. Nobody's asking you to operate the DNS. The ask is to know enough to walk over to the DNS team with a precise request: "this name CNAMEs into a vendor zone with broken signatures — here's the dnsviz trace — we either get the vendor to fix their DS record, or we stop pointing validation-critical names into zones we can't see." That sentence is the job. If the pieces of it don't parse yet, the reading list below is where they come from.

What to actually do

The reading list

The rules changed. Nobody sent you a memo. Now you've read one — which puts you ahead of most of the people who'll be debugging this at 7 a.m.

Building an Enterprise Anycast CDN at the Network Edge »

« The Lazy Way to Actually Lose Weight