HARICA Revoked 235,301 TLS Certificates in Five Days
HARICA's incident report shows 235,301 live TLS certificates revoked in five days over a policy mismatch. Here's why revocation now beats expiry as a risk.
When HARICA made European universities swap out their TLS certificates twice in July, nobody outside the CA knew how big the second round really was. The full incident report has now landed in Mozilla’s Bugzilla. The number is 235,301. That’s how many live, unexpired certificates the Greek academic CA pulled between July 20 and July 25, because a policy document said one thing and the issuing system did another.
What the report says
HARICA issued 305,642 affected certificates in total across a window that opened on March 27 and closed on July 20. By the time the problem was confirmed, 235,301 of those were still unexpired and unrevoked. That’s the population that had to be replaced. All of them were server TLS certificates, DV through EV.
The window has precise edges because it maps to two code changes. At 09:31 EET on March 27, HARICA removed the AIA OCSP URI from its TLS certificate profiles, part of an OCSP deprecation it had announced back in January. At 22:53 EEST on July 20, it put the extension back. Everything issued in between got pulled.
The certificates were fine. The paperwork wasn’t.
Dropping the OCSP URI was the right technical call. Browsers have moved to CRLite and CRLSets, OCSP leaks browsing data to the CA, and Let’s Encrypt shut its own responder down last August. HARICA published a deprecation plan and executed it.
What it didn’t do was update Section 7.1.2.3 of its CP/CPS to say the extension was now optional. So for almost four months the published policy required something the certificates didn’t contain. Under the CA/Browser Forum baseline requirements that counts as mis-issuance, and mis-issuance gets revoked on a five day clock whether or not anyone was ever at risk. The Chrome Root Program team caught the inconsistency on July 17 while reviewing a separate HARICA incident about clientAuth key purpose IDs. HARICA confirmed it the next business day and the clock started.
Two compliance findings within days of each other, both traced to the same section of the same document. Neither involved a bad key or a bogus domain validation. Both cost thousands of admins their weekend.
87 percent got out ahead of it
That’s the share of affected subject alternative names that already had a replacement certificate before revocation began at 10:00 UTC on July 25, and almost all of it came from automation. HARICA switched on ACME Renewal Information for both its legacy and flexible ACME endpoints, so clients that speak ARI (recent Certbot, acme.sh, lego, Caddy) picked up new certificates with nobody touching anything. For subscribers issuing through the portal or the API, HARICA batch-issued replacements on July 22 and told people to come download them.
The other 13 percent is where the pain lived. Manual deployments. Forgotten subdomains. That one certificate owned by a department whose last sysadmin graduated. It didn’t help that cm.harica.gr and the ACME API buckled under load for stretches of July 22, which some institutions escalated to GÉANT as a serious problem. HARICA says it has made improvements there since.
The deadline you don’t control
Most certificate management still treats the expiry date as the only date that matters. Track it, renew a couple of weeks out, done. That’s getting less useful every year.
A certificate can stop working because it expired, because a root program distrusted the CA that issued it, or because the CA found a mismatch in its own paperwork and has five days to clean it up. You know the first date years in advance. The other two show up with a few days of notice and a hard cutoff in UTC that doesn’t care what time zone you’re in. With 200 day certificates now standard and 100 day certificates arriving in March 2027, the renewal cadence alone justifies automating. Events like this one are why you also want to know, at any moment, which CA issued what across your estate.
If HARICA had needed to reach you last month, would you have known which hostnames to check?
Track your certificate expirations and renewal deadlines with SSLcalendar.com so nothing slips past quietly. For a view of which CA issued which certificate across your infrastructure, plus chain and TLS health checks, SSLboard.com does the surveying.
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), HARICA – Another recall of a larger number of SSL server certificates on July 25, 2026 (Leibniz Universität Hannover), Important Notice: Deprecation of OCSP for HARICA Publicly-Trusted TLS Certificates (HARICA)