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 none of the major trust stores — Mozilla, Microsoft, Apple, Google; only Yandex Browser and Atom carry it preinstalled. 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.
How certificate trust actually works
Everything below rests on one idea: a certificate proves nothing on its own. What proves something is the list of roots the client already holds. Six steps of that machinery follow; if you know them, skip straight to what changed.
A certificate is a claim with a signature on it
A server certificate says one thing: “this public key belongs to example.com”. Anyone can write that document on a laptop in a second — that is exactly what a self-signed certificate is. What gives it weight is the signature of a certificate authority: the CA signs the contents with its private key, and the client verifies that signature with the same CA's public key.
The chain: leaf, intermediate, root
A server does not send one certificate, it sends a chain: its own (the leaf) plus intermediates. Each link was signed by the next one up, and the client verifies those signatures in order until it reaches the root — which is self-signed. Intermediates exist mainly so the root key can stay offline: a compromised intermediate can be revoked without touching the root, while the root sits in a billion devices and takes years to replace.
A trust store is just a list
The root is signed by itself, so its signature says nothing about whether it deserves to be trusted. Its entire weight comes from sitting in the client's trust store: a list of roots that ships with the operating system or the browser. Verification boils down to one question — does this chain build up to a root on my list? No root on the list, no trust, however correct the certificate is and however well the signatures add up.
The signature is not the only check
Even once the chain builds, the client checks several more things: the host name must be in the SAN list, today must fall between notBefore and notAfter, the intermediate must be allowed to sign at all (basicConstraints), and the certificate must not be revoked (CRL or OCSP). Chrome, Safari and Firefox additionally require the certificate to appear in Certificate Transparency logs. Any one of these can fail on a perfectly valid chain — and the other way round.
How a root gets onto that list
Not by talking to a browser vendor. A CA meets the CA/Browser Forum Baseline Requirements, passes an independent audit (WebTrust or ETSI) and applies to the root programs. There are several — Mozilla, Microsoft, Apple, Google — each keeps its own list and decides on its own, and from there a new root reaches users through an ordinary system or browser update. The trip takes years. The way out is shorter: DigiNotar had its infrastructure taken over in 2011 and a forged google.com certificate issued, and it was dropped from every store and shut down.
A root can be constrained by name
A root can carry a constraint (nameConstraints): sign only the domains listed in it. Such a root, even once it is in a store, is useless for someone else's name: a certificate outside the permitted list is rejected by the client even though the CA did sign it. General-purpose roots carry no such limit, which is why any publicly trusted CA is technically able to issue a certificate for any domain on earth. That hole is why CAA records exist (the domain owner names which CA may issue) and why Certificate Transparency does — a public log of everything issued.
That is where the rest of this story comes from. A Минцифры certificate is cryptographically no worse than any other: the chain builds, the signatures add up, the host name matches. Exactly one thing does not — its root is on none of the major lists. And that root carries no name constraints either: the first breaks the check on a perfectly healthy site, the second is why trusting it had to be boxed in by hand.
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,.suand.рфhosts. A Минцифры certificate on a.comtarget 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.