Your certificate was fine. It got revoked anyway.
On July 20, 2026, between 12:55 and 13:12 UTC, HARICA revoked 63,525 TLS certificates. Seventeen minutes. On September 10, SSL.com revoked another 2,697, less than a day after its auditors asked for evidence that turned out not to exist.
None of those certificates had a compromised key. SSL.com says outright that there is no indication of compromise or of incorrect domain validation. HARICA's problem was one extra value in the certificate profile. Every one of those certificates did its job perfectly well. They got revoked over paperwork on the CA's side: in one case a policy document that said one thing while the issuance system did another, in the other a validation record missing evidence the rules require.
People get this part wrong. Say "mass revocation" and they picture a breach or a stolen key. The big events of the last few years were compliance bugs at the CA. Your security posture had nothing to do with it. You still got somewhere between 24 hours and five days to swap the certificate before it was dead.
What HARICA got wrong in July
HARICA is a Greek academic CA, and a lot of European universities buy from it through their national research networks. Its incident report on Mozilla's Bugzilla is a textbook case.
Chrome's root program is pushing CAs to drop the clientAuth extended key usage from TLS server certificates. HARICA's CP/CPS, the public document that describes what it issues, said it would stop including clientAuth on June 15, 2026. Chrome Root Program Policy 1.8 had already pushed the deadline for leaf certificates out to March 15, 2027, so nobody was in a hurry. HARICA's CP/CPS still said June 15, though. And its issuance profiles kept adding clientAuth after that date.
Issuing against your own published policy counts as misissuance. Whether the certificate would have passed every browser check is irrelevant. A third party filed a problem report on July 15 at 15:07 UTC. HARICA halted issuance at 17:15 and fixed the profiles at 17:19. Then it had to deal with 66,105 certificates issued in the window, 64,949 of them still valid. The root cause, in HARICA's own words: "No automated control checks certificates against our own CP/CPS."
Universities passed the news on as best they could. The University of Hamburg's notice went out on Friday, July 17. Staff had to find every HARICA server certificate with a "Valid from" date between June 15 and July 15, request a replacement and get it activated through the central service desk. Then install it before Monday morning. Friday announcement, Monday deadline. Plenty of those certificates had been requested by hand and installed by hand.
What SSL.com got wrong in September
SSL.com's case is quieter and more technical. On September 9 at 19:32 UTC, during the annual WebTrust audit, the auditors asked for Multi-Perspective Issuance Corroboration evidence on a sample of certificates. Four of them had none.
MPIC has been mandatory since March 15, 2025. The CA must confirm your domain validation from several network vantage points before it issues (we covered what MPIC does to your firewall rules in August). SSL.com did the primary validation correctly. What it couldn't prove was that the remote perspectives had agreed.
The incident report traces it to two domain-validation entry points in the codebase. MPIC was enforced where one of them was called and not the other. The MPIC results lived only in audit log tables, never on the validation record itself, and nothing at issuance time asked whether MPIC evidence existed. So from the day MPIC became mandatory, certificates validated through the secondary path went out without it.
6,031 certificates were affected, 2,700 of them still valid: 2,418 DV, 280 OV and 2 EV. Revocation finished at 20:25 UTC on September 10. SSL.com's customer notice says subscribers were told by email and that "affected certificates must be replaced."
And then this, buried in the report. During containment SSL.com tried to block TLS issuance. The block didn't hold, and nine more certificates went out the door. The emergency brake failed in the middle of the emergency. Remember that the next time you assume the people upstream of you have it handled.
24 hours or five days, and you don't pick
Section 4.9.1.1 of the Baseline Requirements sorts revocation reasons into two buckets.
The 24-hour bucket covers key compromise and unauthorized requests. It also covers the case where "the validation of domain authorization or control ... should not be relied upon." The five-day bucket includes a certificate "not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement."
HARICA was in the five-day bucket and used nearly all of it. SSL.com revoked inside 24 hours. DigiCert's July 2024 incident was a domain-validation bug, a missing underscore prefix in CNAME validation, and that put 83,267 certificates in the 24-hour bucket.
You don't get a vote. The CA picks the bucket, based on a rule you've probably never read, about a bug you couldn't have seen. Since December 1, 2025 every CA has to state in its CPS that it keeps a mass revocation plan and tests it every year (section 5.7.1.2, added by ballot SC089). Nobody requires you to have one.
Find out whether the window covers you
Both incidents were scoped by issuer and issuance date. For HARICA that meant everything issued from June 15 to July 15. For SSL.com it meant certificates validated through the un-gated path after March 15, 2025. So when an incident goes public, the first question is which of your certificates came from that CA inside that window. Most teams answer it by grepping a spreadsheet.
Certificate Transparency does it better. Every publicly trusted certificate is logged, including the ones nobody remembers ordering. crt.sh has a JSON endpoint:
curl -s 'https://crt.sh/?q=example.org&output=json&exclude=expired' -o certs.json
jq -r '.[]
| select(.issuer_name | test("HARICA"))
| select(.not_before >= "2026-06-15" and .not_before < "2026-07-16")
| [.serial_number, .not_before, (.name_value | gsub("\n"; ","))]
| @tsv' certs.json | sort -u
Keep the sort -u. crt.sh lists the precertificate and the final certificate as separate entries with the same serial. And crt.sh is a free community service that falls over a lot. It was returning 502s the whole time this post was being written. If you need the answer during an incident, run your own CT monitoring (here's how to do it without drowning) or keep an actual inventory. No inventory? Then you probably don't know how many certificates you have.
CT can't tell you where a certificate is deployed. The log entry has no idea that the same serial sits on a load balancer in Frankfurt and on an appliance nobody has logged into since 2023. That mapping is your job.
Check what the endpoint is serving
Expiry monitoring won't catch any of this. A revoked certificate can have 140 days left on it. You have to check the revocation status of whatever is actually being served, against the CA's own CRL.
For this purpose OCSP is mostly gone. Let's Encrypt dropped it entirely, and revocation checking in browsers is a mess anyway. That leaves CRLs. The script below pulls the served chain, fetches the CRL named in the leaf's distribution point, verifies that CRL's signature against the served issuer and looks for the serial:
#!/usr/bin/env bash
# Usage: ./check-revoked.sh example.com
set -euo pipefail
HOST="$1"
cd "$(mktemp -d)"
# The chain the server actually serves: cert1.pem is the leaf, cert2.pem its issuer
openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts </dev/null 2>/dev/null \
| awk '/BEGIN CERT/{n++; f="cert" n ".pem"} f{print > f} /END CERT/{f=""}'
SERIAL=$(openssl x509 -in cert1.pem -noout -serial | cut -d= -f2)
CRL_URL=$( (openssl x509 -in cert1.pem -noout -ext crlDistributionPoints 2>/dev/null || true) \
| grep -o 'http[^[:space:]]*' | head -1 || true)
if [ -z "$CRL_URL" ]; then
echo "$HOST: leaf has no CRL distribution point, check it another way"
exit 2
fi
curl -sf "$CRL_URL" -o crl.der
# Don't trust a CRL the served issuer didn't sign
openssl crl -inform DER -in crl.der -CAfile cert2.pem -noout > verify.txt 2>&1 || true
grep -q 'verify OK' verify.txt || { echo "$HOST: CRL signature check failed"; exit 2; }
openssl crl -inform DER -in crl.der -noout -text > crl.txt
if grep -q "Serial Number: $SERIAL" crl.txt; then
echo "$HOST: REVOKED (serial $SERIAL)"
exit 1
fi
echo "$HOST: not revoked (serial $SERIAL, CRL $CRL_URL)"
Point it at revoked.badssl.com to see what a hit looks like. Exit code 1 means revoked, 2 means it couldn't tell, 0 means clean. The script writes the openssl output to files first and greps those. Piping straight into grep -q under pipefail can turn a match into a miss when grep exits early, and that's the last thing you want in a revocation check.
Some leaf certificates carry no CRL distribution point at all and rely on OCSP. The script tells you so. It won't guess.
Rehearse the replacement under a deadline
Renewal is a scheduled event with weeks of slack. Replacement during a mass revocation is the same operation on a deadline, possibly against a CA that has just halted issuance. Those feel very different at 2 a.m.
On ACME, forcing it is one command:
# certbot
certbot renew --cert-name example.org --force-renewal
# cert-manager
cmctl renew my-cert -n production
cmctl renew --all -n production
That only helps if the new certificate reaches every place the old one lives. cert-manager updates the secret. Does your ingress controller pick it up? What about the copy baked into a sidecar image, or the one uploaded to the CDN? Pick one non-critical hostname this quarter. Force-replace its certificate in the middle of a workday and time how long it takes until every endpoint serves the new serial. That number is your real mass revocation readiness. Over 24 hours means you'd have missed SSL.com's deadline.
Where the CA supports it, ACME Renewal Information is the channel a CA uses to tell your client to hurry, and we wrote about why your client needs to read it. Neither incident report mentions ARI. Don't count on it.
Manual certificates are where this really hurts. HARICA customers had to file a request, wait for approval and install the result, over a weekend. If you buy OV certificates through a portal, find out today who gets the CA's incident email. Usually it's whoever placed the original order. Sometimes that person left two years ago.
Short certificates make this somebody else's problem
The Baseline Requirements exempt Short-lived Subscriber Certificates from mandatory revocation. For certificates issued since March 15, 2026, short-lived means a validity of 7 days or less. Let's Encrypt's six-day certificates qualify. Had HARICA or SSL.com issued those, the fix would have been to stop issuing the bad ones and wait a week.
I wouldn't move everything to six-day certs tomorrow. I would make the replacement pipeline so boring and so automated that nobody has to think about it, because the industry is going there whether you like it or not. Maximum lifetimes are already at 200 days and drop to 47 by 2029. If you can replace a certificate in an hour, a mass revocation is a Tuesday.
Frequently asked questions
Will browsers actually reject a revoked certificate? It depends on the client. Firefox checks revocation through CRLite. Chrome relies on its own curated CRLSets, which skip most revoked certificates, and plenty of non-browser clients don't check at all. Don't treat that inconsistency as a safety net, because some of your users' clients will fail and your CA still expects the certificate replaced.
Can I ask my CA to delay revocation? You can ask, but the Baseline Requirements leave the CA very little room and root programs treat a delayed revocation as an incident of its own. In 2024 DigiCert held back part of its revocation for up to 120 hours for critical-infrastructure customers, and that delay got its own Bugzilla bug. Plan as if the deadline is real.
Does switching CAs protect me from mass revocation? No. Every public CA follows the same Baseline Requirements and can ship the same kind of bug. What helps is a tested second CA in your ACME setup, so you can still issue while your primary CA has stopped issuance during its own incident.
How do I know if a CA incident affects me before the email arrives? Watch the CA Certificate Compliance component on Mozilla's Bugzilla and your CA's status page, and keep a CT-based inventory you can filter by issuer and issuance date. The incident report usually shows up within a day or two of discovery, often before customer notices go out.
