Monitoring sites on Russian Trusted Root CA (Минцифры) certificates

Foreign certificate authorities have been revoking certificates for Russian companies through 2026, and many sites have moved to the Ministry of Digital Development’s own CA — the Russian Trusted Root CA (НУЦ Минцифры). That root ships in no browser and no default trust store, so a monitor pointed at such a host used to fail verification: HTTPS monitors went hard DOWN, SSL monitors sat in DEGRADED, and the product even suggested turning certificate checking off.

PingZen now recognises this root for its own checks. If your .ru site serves a Минцифры certificate, its monitor goes green again — no setting to change.

What actually changed

The check does two passes. First it verifies against the standard public trust store, exactly as before. Only if that fails does it retry against the Минцифры root. A monitor that already passed keeps passing the same way; nothing about public-CA verification changed.

Recovered monitors are logged as verified through the added anchor, so it stays visible which check trusted the non-public root rather than a public CA.

Contained on purpose

Trusting a state root everywhere would be too much, so it is boxed in:

• Only the health check uses it. Everything else PingZen does — sign-in, alert delivery, webhooks — keeps verifying against public roots only. A Минцифры certificate for, say, a Google or Telegram endpoint is still rejected.
• Russian domains by default. The root carries no name constraints, so the fallback is limited to .ru, .su and .рф hosts. A Минцифры certificate on a .com target does not quietly turn a monitor green.

When your host is Russian but the domain isn’t

Some Russian operators serve a Минцифры certificate on a non-Russian domain. The gate can be lifted for that one monitor — it is off by default and set per target, so you loosen trust for a single host you chose, never across the board. If you run such a host and its monitor stays red, get in touch and we will enable it for that monitor.

What this is not

This is not GOST TLS. Servers that speak GOST cipher suites fail the handshake before any certificate is exchanged, and no trust anchor helps there — that is a separate problem. And a host that serves a certificate with no chain at all stays DEGRADED: the fix there is on the server (send the full chain), not in the trust store.