` reads). %>
HARICA Revoked 63,525 Certificates in Five Days. Here's Why. | TLS Radar
Skip to main content
strategy
August 3, 2026
5 min read
By<br>TLS Radar Team
HARICA Revoked 63,525 Certificates in Five Days. Here's Why.
In July 2026, the public certificate authority HARICA revoked 63,525 TLS certificates because its own compliance policy (CP/CPS) had drifted out of sync with its issuance system - not because of a security breach or any browser objection. The certificates were valid and working, yet customers got as little as five days to rotate them. The lesson is structural: any CA can be forced into a mass revocation, so the only reliable defense is monitoring your certificates' trust and revocation status independently of your CA.
Key facts
•<br>66,105 server TLS certificates were issued in violation of HARICA's own published policy between June 15 and July 15, 2026.
•<br>64,949 of them were still valid (non-expired, non-revoked) when the violation was discovered.
•<br>63,525 were revoked by July 20, 2026, within the CA/Browser Forum's mandatory five-day revocation window.
•<br>Root cause: HARICA's CP/CPS kept a June 15, 2026 clientAuth cutoff after Chrome extended the industry deadline to March 15, 2027, and its issuance system was never updated to match.
•<br>A second, unrelated violation - certificates issued without the required AIA OCSP URI - forced a further round of revocations by July 25, 2026.
•<br>Neither incident involved a security breach or a compromised key. Both were self-inflicted policy-sync failures.
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...