Between June 15 and July 15, 2026, HARICA - a mid-sized public CA trusted by every major browser - issued 66,105 server TLS certificates that violated its own published policy. When the violation was discovered, HARICA had five days to fix it. They revoked 63,525 certificates by July 20. Ten days later, a second and unrelated policy violation forced another round of revocations by July 25. A third, still-open issue involves HARICA continuing to issue certificates to entities under EU sanctions and declining to revoke them without a court order.
None of the affected customers did anything wrong. Their certificates were valid, correctly issued, and working right up until they weren't.
What actually happened
The first incident traces back to a single missed update. In 2025, HARICA's Certification Practice Statement (CP/CPS) set June 15, 2026 as the internal deadline to stop issuing certificates with the clientAuth Extended Key Usage - matching Chrome's policy at the time. Chrome subsequently extended that industry-wide deadline to March 15, 2027. HARICA's compliance documentation was never updated to reflect the extension, but their issuance system kept including clientAuth on server certificates past their own internal cutoff. For a month, HARICA was operating out of compliance with its own written policy, even though Chrome's actual current requirement hadn't been violated at all.
A third party reported the discrepancy on July 15. HARICA confirmed the violation, corrected the certificate profiles within roughly two hours, and began the mandatory revocation process. Under CA/Browser Forum rules, once a compliance violation of this kind is confirmed, the affected certificates must be revoked within five days - not five days to notify customers, five days total including the revocation itself. HARICA's mass-revocation plan reportedly executed cleanly; 63,525 of the 64,949 certificates still in service at discovery were revoked by July 20, 2026, 13:12 UTC.
Ten days later, a second violation surfaced: server TLS certificates issued between late March and July 20, 2026 were missing the required AIA OCSP URI extension - again, a documented CP/CPS requirement that HARICA's issuance system had silently drifted away from. A further round of revocations was required by July 25.
Two unrelated compliance failures, one root cause: a manual, undocumented gap between what HARICA's policy said and what their issuance system actually did. Nothing in either incident involved a security breach or a compromised key. Both were self-inflicted paperwork problems that happened to carry a five-day revocation obligation.
The part that isn't a technical bug
A separate, still-unresolved report concerns HARICA continuing to issue and decline to revoke TLS certificates for entities under EU sanctions, including major Russian financial institutions. When pressed, HARICA's position has been that domain-validated certificates only attest to control of a domain, not the identity of the organization behind it, and that sanctions screening isn't part of DV issuance - they'll act only on instruction from a "competent supervisory or law enforcement authority."
Technically defensible, reputationally not a good look, and worth knowing about if HARICA is anywhere in your certificate supply chain: this is a CA currently navigating compliance friction on multiple fronts at once, not a one-off clerical error.
Why this isn't a HARICA-specific story
It's tempting to read this as "avoid HARICA." That's the wrong takeaway. The actual lesson is structural: every public CA maintains a CP/CPS full of internal deadlines, and every CA's issuance system has to stay in sync with that document as policy changes happen elsewhere in the industry - changes they don't control and sometimes don't fully track. HARICA got caught this time. The mechanism that caught them (a third-party researcher watching Certificate Transparency logs and comparing issued certificates against public CP/CPS documents) isn't unique to HARICA - it's a standing check anyone can run against any CA.
The uncomfortable fact for customers: your certificate can be revoked with as little as five days' total notice, for a reason that has nothing to do with anything you did, and you'll typically find out only when your CA emails you - if their notification pipeline works correctly, which is itself a system that can fail independently of the underlying compliance issue.
What to actually do about it
You can't audit your CA's internal compliance documentation. What you can do is stop assuming "my certificate is valid" means "my certificate is safe from revocation." Two concrete steps:
Check whether you're carrying unnecessary risk. If any of your public TLS certificates include the clientAuth EKU alongside serverAuth, ask your CA directly whether their current CP/CPS already prohibits that combination on server certificates - not whether Chrome currently enforces it, whether their own policy does. If it does, get reissued proactively rather than waiting for a forced revocation notice.
Monitor for revocation independently of your CA's notification. A CA's revocation-notice email can go to a stale distribution list, get caught in spam, or simply never get sent if their pipeline has its own bug - which is exactly the kind of documentation-vs-system drift that caused HARICA's incidents in the first place. External monitoring that checks your certificates' live trust and revocation status, independent of whatever your CA tells you, is the only way to know for certain your certificates are still trusted right now.
TLS Radar's scanner already checks for the specific pattern that caused HARICA's first incident: certificates that assert both serverAuth and clientAuth. If it finds one, it flags the risk with a severity graded by issuance date - a certificate issued after the Chrome Root Program's March 15, 2027 cutoff is flagged high severity as an active browser-rejection risk, while an earlier "grandfathered" certificate is flagged as a warning that it will stop being accepted at its next renewal. Either way, you find out from a scan, not from a five-day revocation notice.
Know before your CA tells you
Scan your domain free to check whether any certificate in your inventory carries the dual-EKU pattern that caused HARICA's mass revocation. Then create a free account so TLS Radar keeps watching continuously - independent of your CA's own notifications - and catches the next compliance-driven revocation before a customer does.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.