In short. Russian bank sites stopped loading in Chrome, Safari, Firefox, Opera and Edge because the banks moved to TLS certificates issued by the National Certification Authority of the Russian Ministry of Digital Development. That authority's root is not in the Google, Apple, Microsoft or Mozilla trust stores, so the chain cannot be completed. Two ways out: use a browser that ships the root itself, or install it on the device.
What actually happened
In early August 2026 the websites of Sberbank, VTB, Alfa-Bank, Rosselkhozbank and others began failing in every mainstream browser with NET::ERR_CERT_AUTHORITY_INVALID or an equivalent warning. Card payments on unrelated merchant sites broke at the confirmation step, because the 3-D Secure window is served from the bank's own domain.
The certificates themselves are valid and unexpired. What changed is who signed them: after certificates from foreign authorities were revoked, the banks switched to the National Certification Authority (НУЦ) run by the Ministry of Digital Development, whose root no browser vendor distributes.
The warning reads like a problem with the site. It is a statement about your device: nothing in your trust store vouches for this certificate.
Why a valid certificate is rejected
A browser does not evaluate a certificate in isolation — it walks a chain. The site certificate is signed by an intermediate, the intermediate by a root, and that root must already be present in the device's trust store or inside the browser itself. Remove the last link and the chain is unverifiable, which is indistinguishable from an interception attempt as far as the browser is concerned.
Yandex Browser and Atom open these sites with no action from the user: their vendors compile the root and intermediate certificates into the browser binary, bypassing the operating system's store entirely. Everything else needs the root installed.
If a chain breaks for an ordinary reason instead — a missing intermediate rather than an untrusted root — the symptoms look similar but the fix is different; that case is covered in the article on incomplete certificate chains.
Browser by browser
| Browser | Ships the root | What is required |
|---|---|---|
| Yandex Browser | yes, in the binary | nothing |
| Atom | yes, in the binary | nothing |
| Chrome | no | install into the OS store |
| Safari | no | install, then enable full trust |
| Edge | no | install into the OS store |
| Opera | no | install into the OS store |
| Firefox | no, and keeps its own store | install inside Firefox separately |
Firefox is the exception worth remembering: it deliberately ignores the system store and maintains its own. Adding the certificate to Windows or macOS has no effect on it.
Installing the root
The official source is gosuslugi.ru/crt on the Russian government services portal. A root certificate is not an ordinary download, and mirrors on file-sharing sites are not an acceptable substitute — the reason is in the trade-off section below.
iOS and iPadOS
Two steps, and the second is the one people miss.
- Open the certificate page in Safari — only Safari downloads configuration profiles — and accept the profile.
- Open Settings, tap the "Profile Downloaded" entry that appears near the top, and install it.
- Required. Go to Settings → General → About → Certificate Trust Settings and enable the switch next to the installed root.
Since iOS 10.3 a manually installed certificate is not trusted for TLS automatically; trust has to be granted explicitly. Skip step three and the certificate is present but inert, which looks exactly like a failed installation.
Android
Install through Settings → Security → Encryption & credentials → Install a certificate → CA certificate. The exact path differs across Android versions and vendor skins — searching the settings for "certificate" is faster than following any fixed route. The system will warn that installing a third-party certification authority reduces security. That warning is accurate; see below.
Windows and macOS
On Windows the file goes into Trusted Root Certification Authorities. The import wizard offers to choose the store automatically — do not let it; automatic placement puts the certificate somewhere that will not be used for TLS validation.
On macOS add it to the System keychain in Keychain Access, then open the certificate and set Trust to "Always Trust". Like iOS, macOS grants no trust by default.
Verifying the installation
The direct check is the command line:
openssl s_client -connect example-bank.ru:443 -servername example-bank.ru < /dev/null 2>&1 | grep -E "Verify return code|issuer"Verify return code: 0 (ok) means the chain validated. Codes 19 and 20 mean the root was not found — either not installed, or installed into a store that TLS validation does not consult.
To see the issuer and the chain of any site without a terminal, use the SSL certificate check: it reports the issuer, expiry and whether the chain is complete.
The site works, the mobile app does not
A common and confusing outcome on Android: after installing the certificate the site loads in the browser while the bank's app still fails.
Since Android 7, apps do not trust user-installed certificate authorities by default — only the system ones baked into the OS. The app's developer has to opt in through the network security configuration. Nothing on the user's side changes this; the browser is the workaround until the app ships an update.
What you are agreeing to
This part is usually left out of installation guides, and it is the part worth understanding. A root certificate in the system store is not a key to one bank's website. It is your device declaring that it will trust any certificate issued by that authority for any domain — mail, messaging, anything.
In practical terms: whoever controls the root can technically issue a certificate for a name they do not own, and the browser will accept it silently. This is a property of every root authority, not a peculiarity of this one — which is exactly why the preinstalled list in each browser is short, deliberated, and why adding your own triggers a system warning.
Three consequences follow:
- Download only from the official portal. A substituted root is indistinguishable from the real one by eye and hands over your traffic.
- If you need these sites occasionally, Yandex Browser or Atom is the better trade: trust stays inside one browser instead of covering the whole system.
- The root can be removed at any time from the same place it was added. This is reversible.
Which certificates have actually been issued for a given domain is publicly auditable through certificate transparency logs — how those work is worth knowing whichever roots you trust.
If you run one of these sites
A visitor on Chrome without the root will see a warning and, in most cases, leave. Serving the full chain including the intermediate removes half the problem, because browsers that do ship the root then have everything they need from your server alone. Configuration and verification are covered in the article on Russian certificate authorities.
Expiry deserves separate attention: to a visitor, a silently expired certificate looks exactly like an untrusted root.
Symptom, cause, fix
| What you see | Cause | Fix |
|---|---|---|
| "Connection is not private" on a bank site | Root not installed | Install it, or use Yandex Browser |
| Installed, Safari still warns | Full trust not enabled | Settings → General → About → Certificate Trust Settings |
| Works in Chrome, fails in Firefox | Firefox uses its own store | Add the certificate inside Firefox |
| Site loads, app does not | Android 7+ ignores user CAs in apps | Use the site; wait for an app update |
| Card payment fails at confirmation | 3-D Secure page is on the bank's domain | Same root installation |
| One bank works, another does not | Not the root — that site's own chain | Check the site's chain |
Frequently asked questions
Is this a block? Will a VPN help? No to both. The site is reachable and the connection is established; the browser terminates it during certificate validation. A VPN changes the route, not the contents of your trust store.
Do I need this if I only use the bank's app? Not for the app itself. But paying by card on a third-party site opens the bank's confirmation page in a browser, and that page needs the root.
Will it expire and need reinstalling? Root certificates are issued for years and rotate rarely. Intermediates and server certificates change more often, but those are the site owner's problem.
Can I take the file from my bank's website? Large banks publish their own instructions and that is a legitimate route. But an ordinary user has no way to verify a file obtained from a third party, which is why the official portal remains the safer source.
Nothing changed after installing. Now what? Check three things in order: whether full trust is enabled (iOS and macOS), whether you are testing the browser you installed it for (Firefox needs its own), and whether the certificate landed in the trusted root store rather than the personal one (Windows).
Checklist
- File taken from the official portal, not a mirror
- Full trust enabled explicitly on iOS and macOS
- Firefox handled separately, inside the browser
- Target site loads without warnings in the browser you installed for
- You understand the root covers every domain from that authority, not only banks
- You know where to remove it