HARICA Revokes TLS Certs Twice in a Week Over CP/CPS Bug
HARICA revoked TLS certificates twice in ten days after CP/CPS policy violations, forcing European university networks to scramble before each tight deadline.
IT teams at universities across Germany spent much of the last two weeks doing the same stressful dance twice: renewing TLS certificates on a hard deadline, not because anything was compromised, but because their certificate authority’s paperwork didn’t match what it had actually been issuing. HARICA, the Greek academic-network CA, forced two separate mass revocations in the span of ten days, and the second one, on July 25, was bigger than the first.
What happened
The trouble traces back to two separate compliance gaps that HARICA found in its own issuance process. The first involved certificates issued between June 15 and July 15, 2026, that carried the id-kp-clientAuth key purpose ID in violation of HARICA’s certificate policy. That one forced a revocation round in the middle of July, and institutions running HARICA-issued certs had to replace them on short notice.
Before that dust had settled, a second, unrelated problem turned up. Back at the end of March, HARICA had removed the AIA OCSP URI access method from its server certificates, but nobody updated the CP/CPS document to reflect that change. So for nearly four months, HARICA was issuing certificates that didn’t match its own published policy. Once that mismatch got flagged, there was only one way to fix it under the CA/Browser Forum’s baseline requirements: revoke every certificate issued while the discrepancy was live. That meant everything issued between March 27 and July 20, 2026, plus, awkwardly, the certificates that institutions had just replaced the week before to fix the clientAuth problem. Those had to be swapped out again.
HARICA set the cutoff for 10:00 UTC on July 25. Anything not replaced by then got revoked automatically, and any TLS service still pointing at a revoked cert would start throwing browser errors or failing outright.
Who got caught up in it
HARICA grew out of the Greek academic and research network and still serves a lot of that world, so the fallout landed heavily on European university IT departments. Status pages at the University of Hamburg, TU Berlin, TU Dresden, RWTH Aachen, and the GWDG computing center in Göttingen all posted urgent notices telling users to check their certificates and replace anything affected before the deadline. For campuses running dozens or hundreds of subdomains, most of it maintained by different departments with varying levels of certificate hygiene, chasing down every affected cert in a few days is not a small task.
Some of it happened without anyone lifting a finger. ACME clients that support Renewal Info, including recent versions of acme.sh, Certbot, go-acme/lego, and Caddy, picked up the replacement automatically. Anyone on an older client, or managing certs by hand, had to do it manually and hope they didn’t miss one.
Why a paperwork mismatch forces mass revocation
This is the part that trips people up: nothing about these certificates was insecure. The clientAuth purpose ID and the missing OCSP URI weren’t security holes, they were compliance mismatches against the CA’s own governing document. But the baseline requirements that browser root programs enforce don’t grade on severity. If a certificate doesn’t match what the CP/CPS says it should look like, it counts as mis-issuance, and mis-issued certificates get revoked on a fixed clock, typically within days of discovery, regardless of whether the underlying deviation was actually dangerous to anyone.
It’s the same rule that’s produced mass revocations at DigiCert and other large CAs in past years. Trust in the CA system rests on CAs doing exactly what their published policies say, so even a boring administrative drift has to get corrected fast and completely. HARICA owes Mozilla an incident report laying out the root cause and what changes are meant to keep it from happening again.
What this means for anyone running HARICA certs, or any certs
Two revocation events in ten days from the same CA is rare, and it’s a good reminder that expiration isn’t the only way a cert can suddenly stop working. Policy violations, mis-issuance findings, and root program disputes can all force a replacement on a timeline you don’t control, sometimes with days of notice instead of weeks.
The institutions that weathered this cleanly were the ones running ACME clients with renewal automation already switched on. Everyone else was stuck manually tracking down every domain on a HARICA cert and swapping it before a UTC deadline that didn’t care about time zones or staffing.
To avoid finding out about a forced revocation the hard way, use SSLcalendar.com to track certificate expirations and renewal deadlines before they sneak up on you. For visibility into exactly which CA issued which certificate across your infrastructure, SSLboard.com provides deeper certificate and chain surveying so an event like this doesn’t blindside you.
Sources: HARICA: Issuance of Server TLS Certificates without AIA OCSP URI against CP/CPS (Mozilla Bugzilla), HARICA: Issuance of Server TLS Certificates with id-kp-clientAuth KeyPurposeID against CP/CPS (Mozilla Bugzilla), Information: HARICA – Replacement of Affected Server Certificates Required by 25 July 2026 (GWDG Status), HARICA – Another recall of a larger number of SSL server certificates on July 25, 2026 (Leibniz Universität Hannover)