On July 29, 2024, DigiCert — one of the largest certificate authorities on the internet — announced it would revoke 83,267 TLS certificates belonging to 6,807 customers. Not because the certificates were forged. Not because a key leaked. Because of a missing underscore.
That’s the whole technical defect, and it’s worth sitting with how small it is before we get to the part where a company took a certificate authority to federal court to stop it.
What the underscore was for
When you buy a certificate, the CA has to confirm you actually control the domain you’re asking it to vouch for. One of the standard ways is a DNS challenge: the CA hands you a random value, you publish it in a DNS record on your domain, the CA looks it up, and if it matches, you’ve proven control. DigiCert offered this as a CNAME record — you add a record containing their random string, they check it.
Here’s the detail that mattered. The random value is supposed to be published under a label that starts with an underscore — something like _ prefixed onto the token. Underscores aren’t legal in ordinary hostnames, which is exactly the point: a label beginning with an underscore can’t be a real, resolvable server name. It lives in a separate namespace reserved for machine-readable records, walled off from the names people actually type. Putting the validation token there guarantees it can’t collide with, or be confused for, a legitimate hostname somebody might control for other reasons.
DigiCert’s system was supposed to prepend that underscore automatically. Starting in August 2019, in some fraction of validations, it didn’t. The random value went out without the prefix. For nearly five years, nobody noticed. In early July 2024 a researcher wrote to DigiCert’s problem-report address asking whether certificates validated with random values that lacked the underscore needed to be revoked; after weeks of back-and-forth, a code review on July 27 confirmed that some validation paths had never added it.
Did any of those 83,000 domains actually get taken over because of this? Almost certainly not. The customers controlled their domains; the validation reached the right people; the certificates went to the right owners. In practical terms, the missing underscore was harmless.
That didn’t matter even slightly, and understanding why it didn’t matter is the actual subject of this post.
The rule is bright-line on purpose
A public certificate authority doesn’t operate on its own judgment. It operates under the CA/Browser Forum’s Baseline Requirements, the rulebook that browser root programs enforce. And the Baseline Requirements say that when a CA discovers a certificate was issued without a properly completed domain validation, it must revoke that certificate within 24 hours. Not “within 24 hours unless it would be inconvenient.” Not “after assessing real-world risk.” Twenty-four hours.
People’s first reaction to this is that it’s insane — revoke 83,000 live certificates, overnight, over a cosmetic flaw that hurt nobody? But the rule is bright-line precisely so that it can’t be argued with, because the moment you let a CA say “this particular mis-issuance wasn’t really dangerous, so we’ll take our time,” you’ve handed the CA the one power it must never have: the discretion to decide which of its own mistakes count. That discretion is corrosive. Every CA that ever died slowly — and they do die slowly, from missed deadlines and self-granted extensions — died by accumulating exactly that habit. The 24-hour clock is unforgiving because a forgiving version of it is worthless.
So the CA has no out. The defect is a validation defect, full stop, and the clock starts the moment it’s found. DigiCert’s engineers understood this. The problem was that their customers did not, and could not comply even if they wanted to.
The part the rule doesn’t account for
Here’s the collision at the heart of the whole episode. The 24-hour revocation rule quietly assumes that replacing a certificate is fast — that you can mint a new one and swap it in before the old one dies. And for anyone running modern automated issuance, that’s true: an ACME client renews certificates on a cron job, and a forced revocation is a non-event, just an early renewal.
But the organizations that got hit hardest were, almost by definition, the ones not doing that. Certificates pinned into embedded devices. Certificates hand-installed on load balancers by a person who does it twice a year. Certificates buried in appliances, in change-frozen production environments, in systems where “rotate the TLS cert” is a scheduled maintenance window, not an API call. For them, 24 hours wasn’t a deadline. It was an outage notice.
DigiCert, caught between the Baseline Requirements and a revolt from exactly these customers, blinked. Within a day it pushed the deadline for a subset of certificates whose owners couldn’t rotate in time out to August 3 at 19:30 UTC — about five days after the announcement instead of one. Which was a kindness, and also itself a violation: a delayed revocation is still a breach of the rules, and DigiCert had to file it as a second compliance incident in the public bug tracker. There is no clean move here. Comply fully and you knock customers offline over a harmless typo. Give customers room and you’ve broken the rule you exist to uphold.
When revocation went to court
And then one customer did something that genuinely rattled the certificate world: it sued.
Alegeus Technologies, a benefits-and-payments SaaS company, filed in U.S. District Court in Utah on July 30 seeking a temporary restraining order to stop DigiCert from revoking its certificates. The judge granted it. For up to seven days, until a hearing, DigiCert was legally prohibited from revoking the Alegeus certificates — the same certificates the Baseline Requirements required it to revoke within 24 hours.
Read that again, because it’s a genuinely novel kind of problem. A CA now had a court order on one side telling it not to revoke, and the entire browser trust ecosystem on the other side telling it that it must. The Baseline Requirements aren’t a contract between DigiCert and Alegeus; they’re the condition under which browsers trust DigiCert’s root at all. A court can order a company around. It can’t order Chrome and Mozilla to keep trusting a CA that stops following the rules — and a CA that lets a customer’s lawsuit override its revocation obligations is a CA quietly advertising that its promises are negotiable.
It didn’t come to that. On August 1, Alegeus’s lawyers told the court the two sides had reached a preliminary agreement: Alegeus would replace its certificates, and both parties moved to vacate the restraining order. DigiCert’s incident report says the last of the 83,267 certificates was revoked on August 3. The system held. But it held by luck and hustle, not by design — and the precedent is still sitting there. The next company that can’t rotate in time now knows there’s a courthouse option.
The underscore is a footnote
Strip away the specifics and here’s what the DigiCert incident actually demonstrated: the Web PKI’s enforcement model and a large share of its users are running on incompatible assumptions. The rules assume certificates are disposable and rotation is instant. A huge installed base treats certificates as durable infrastructure you touch as rarely as possible. As long as both of those are true at once, every mass-revocation event is a crisis, and there will be more of them — the trigger is always some small process flaw, discovered late, because that’s how five-year-old bugs get found.
The fix was never going to be “stop making typos.” CAs are enormous automated systems; they will always have latent defects, and the ecosystem has gotten better at catching and disclosing them, which paradoxically means more revocation events, not fewer. The actual fix is the boring one the industry has been inching toward anyway: certificates short-lived enough, and issuance automated enough, that revocation stops being an emergency and becomes a shrug. If your certificates already renew themselves every few days, a forced revocation is just a slightly early renewal, and no one calls a lawyer.
The missing underscore will be forgotten. What it exposed — that a bright-line safety rule and an un-automatable installed base cannot coexist peacefully — is the thing worth remembering. The organizations that treated the 2024 scramble as a wake-up call and automated their certificate lifecycle will sleep through the next one. The ones that treated it as a DigiCert problem are going to relive it, probably sooner than they think, and the typo that triggers it won’t be theirs to fix.