HARICA Won't Revoke Certs for Sanctioned Russian Banks
HARICA refused to revoke TLS certificates it issued to EU-sanctioned banks like Sberbank and VTB, testing sanctions compliance. Here's why it matters to you.
A researcher combing through public certificate logs this week found something that shouldn’t have been there: active, valid TLS certificates issued by a Greek certificate authority to Sberbank, VTB, and several other entities under EU sanctions. When the researcher reported it through the normal channel, the CA said no. Now the dispute is sitting in Mozilla’s public bug tracker, and it’s turning into a real test of what “trust” is supposed to mean in the certificate business.
What was found
A security researcher going by Iakov filed a report on Mozilla’s Bugzilla this week documenting certificates that HARICA, the Greek Universities Network’s certificate authority, had issued to a list of heavily sanctioned entities: Sberbank, VTB, *.kamaz.ru, *.veb.ru, and *.dialog.info, along with additional certs turned up for *.vk.com, *.alrosa.ru, and *.rosneft.ru. All of these are named under EU Council Regulation (EU) No 269/2014, the sanctions framework that bars EU entities from providing economic resources or services to designated Russian companies and institutions.
Iakov filed Certificate Problem Reports with HARICA’s compliance team, the standard mechanism anyone can use to flag a certificate that shouldn’t have been issued. HARICA closed the reports with a form response: the certificates are Domain Validated, they only attest to control of a domain rather than the identity of the organization behind it, and DV issuance doesn’t require the kind of vetting that would trigger a sanctions check. HARICA added that it would only act on further instruction from “a competent supervisory or law enforcement authority.”
Why this didn’t start with HARICA
The timing matters here. In mid-June, GlobalSign ran a second wave of forced revocations against sanctioned Russian companies, pulling certificates from roughly 44 organizations across 310 domains, including Gazprombank, Rosneft, and Alrosa. The move followed a CA/Browser Forum push requiring CAs to screen applicants against OFAC, BIS, and EU sanctions lists. Let’s Encrypt made a similar change to its subscriber terms around the same time, cutting off issuance to Russian government entities and sanctioned companies.
Gazprombank got a new HARICA wildcard certificate on June 19, one day after GlobalSign yanked its old one. Lose a certificate at one CA, show up at another the next morning with a fresh one: that’s the exact behavior sanctions screening is supposed to catch. It reads less like an oversight and more like a company shopping around for the CA that won’t ask questions.
The DV argument, and why people aren’t buying it
HARICA’s position rests on a real distinction in how certificates work. A Domain Validated certificate only confirms that whoever requested it controls the domain, nothing about who they are. Extended Validation certificates, by contrast, involve identity checks specifically because they’re meant to say something about the organization. HARICA is arguing that since it never vouched for Sberbank’s identity in the first place, sanctions compliance isn’t its problem.
The counterargument, made bluntly by a commenter on the bug thread, is that sanctions law isn’t scoped to certificate types. EU Regulation 269/2014 prohibits making services available to designated entities, full stop, and HARICA operates out of Greece, squarely inside the EU. Whether the certificate is DV or EV doesn’t change who it’s being issued to or that HARICA is an EU entity providing a service to a sanctioned one. The same commenter pointed to a 2023 incident involving SSL.com that raised nearly identical questions, suggesting this isn’t the first time a CA has tried the DV-certs-don’t-count argument.
There’s also a practical problem with HARICA’s “wait for a court order” stance. Sanctions regimes put the compliance burden on the entity providing the service, not on regulators to hunt down every violation one at a time. Waiting to be told is stalling, dressed up as due process.
What’s actually at stake
Root store programs, the lists that Mozilla, Chrome, Apple, and Microsoft maintain to decide which CAs get trusted by default, exist to enforce exactly this kind of accountability. If a CA is found to be knowingly serving sanctioned entities and refusing to revoke on legal grounds once notified, that’s the kind of finding that has ended trust for CAs before. The bug report is still unconfirmed as of this writing, and Mozilla has flagged it for input from its incident response team, so nothing has been decided. But the pattern here, revoked elsewhere, reissued at HARICA within a day, formal refusal to fix it, is not a good look heading into that review.
For everyone else running infrastructure, the practical lesson is smaller but still worth noting: certificate trust isn’t static. A CA that’s fine today can end up in a root store dispute next month, and if your renewal automation is pointed at a CA that gets distrusted, you’ll find out the hard way when browsers start throwing warnings.
To keep track of what’s expiring and when, before a CA dispute or a policy change turns into your outage, use SSLcalendar.com for renewal reminders. If you want visibility into which CAs actually issued the certificates running across your domains, SSLboard.com does the deeper certificate and chain surveying that catches this kind of exposure before it becomes a headline.
Sources: HARICA: Continued issuance and refusal to revoke TLS certificates for EU-sanctioned blocked entities (Mozilla Bugzilla), GlobalSign Revokes TLS Certificates for Sanctioned Russian Companies, Second Wave in One Week (abit.ee), Let’s Encrypt bans certificate usage in sanctioned territories (Hacker News discussion)