HTTPS and the Web Server in Practice: Part 5 — What Is the Ministry of Digital Development's Certificate (Russian Trusted Root CA) and How to Install It

The Ministry of Digital Development’s certificate — the root certificate of the National Certification Authority (NCA) of the Ministry of Digital Development of Russia, Russian Trusted Root CA. The center has been operating since March 2022: at that time foreign certification authorities stopped issuing and renewing certificates for some Russian organizations, and websites needed a source of certificates inside the country. NCA certificates have been issued to sites of several banks, government and other organizations. Chrome, Firefox and Safari do not trust this root, so such sites open with the error “Connection is not secure” until the root certificate is installed manually. Below — how to check whether you need it and how to install it on different systems. How a browser verifies certificates and the trust chain — in the article “What is HTTPS and how the TLS handshake works”.

Which certificates are included

• Russian Trusted Root CA — root: C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA, valid from 1 March 2022 to 27 February 2032. This is the one you need to add to trusted roots;
• Russian Trusted Sub CA and Russian Trusted Sub CA 2024 — intermediates that issued site certificates. A properly configured site serves the intermediate certificate itself, but on Gosuslugi they publish them together with the root, and installing them won’t hurt.

The official source is the gosuslugi.ru/crt page: it hosts the certificate files and an installer for Windows. Download certificates only from there: a root certificate from a random source gives its author the ability to impersonate any site on your computer.

Verify the downloaded file:

openssl x509 -in russian_trusted_root_ca_pem.crt -noout -subject -dates -fingerprint -sha256

Compare the SHA-256 fingerprint with the one published on Gosuslugi.

In addition to these certificates, there are roots using Russian GOST algorithms. They are needed for systems that use GOST TLS and require a separate crypto provider; they are not needed for ordinary browser sites.

Do you need it

Sign: a site opens in Yandex Browser or Atom (they have the Ministry’s root built-in), but in Chrome or Firefox it shows the error NET::ERR_CERT_AUTHORITY_INVALID or SEC_ERROR_UNKNOWN_ISSUER. In the site’s certificate details the issuer is Russian Trusted Sub CA.

Check from the command line:

openssl s_client -connect site.example.ru:443 -servername site.example.ru </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer
# issuer=C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Sub CA

If you rarely use such sites, the simplest option is to open them in Yandex Browser or Atom and not install anything system-wide.

Windows

1. Open the russian_trusted_root_ca.cer file → “Install Certificate”.
2. Store location: “Current User” (or “Local Machine” for all users — administrator rights required).
3. “Place all certificates in the following store” → “Trusted Root Certification Authorities”.
4. Confirm the security warning.

Same from an administrator command line:

certutil -addstore -f Root russian_trusted_root_ca.cer

Chrome and Edge on Windows trust root certificates installed in the system. Firefox does not — see below.

macOS

1. Open the file — it will be added to Keychain, in the “Login” or “System” keychain.
2. Find Russian Trusted Root CA, open it → “Trust” → “When using this certificate: Always Trust”.

From the terminal:

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain russian_trusted_root_ca_pem.crt

Safari and Chrome use the system keychain.

Linux

Debian and Ubuntu — the system store used by curl, wget, Python, Git and most programs:

sudo cp russian_trusted_root_ca_pem.crt /usr/local/share/ca-certificates/russian_trusted_root_ca.crt
sudo update-ca-certificates

The file in this directory should have a .crt extension. In RHEL, Rocky and Fedora — the directory is /etc/pki/ca-trust/source/anchors/ and the command is sudo update-ca-trust.

Chrome on Linux takes certificates from its own NSS user database. You can add it in Chrome settings (Privacy and security → Security → Manage certificates) or with the command from the libnss3-tools package:

certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "Russian Trusted Root CA" -i russian_trusted_root_ca_pem.crt

Firefox

Firefox uses its own store on all systems: Settings → Privacy & Security → Certificates → View Certificates → Authorities → Import, check “Trust this CA to identify websites”.

On Windows and macOS Firefox can be configured to use the system root certificates: in about:config set security.enterprise_roots.enabled = true.

Android

Settings → Security (or “Security & privacy”) → Encryption & credentials → Install a certificate → CA certificate. Exact path depends on the device manufacturer.

Since Android 7 apps by default do not trust user-installed certificates — only system ones. Browser Chrome accepts such certificates, while apps do only if the developer explicitly allows it. Banking apps don’t need this: they validate their servers’ certificates themselves.

iOS and iPadOS

1. Open the certificate file in Safari → allow the profile download.
2. Settings → General → VPN & Device Management → install the profile.
3. Settings → General → About → Certificate Trust Settings → enable full trust for Russian Trusted Root CA.

Without the third step the certificate is installed but not used for websites.

Programs and servers

If your script or service connects to a site with the Ministry’s certificate, you don’t have to install the root system-wide; you can specify it only for that call:

curl --cacert russian_trusted_root_ca_pem.crt https://site.example.ru/api/

import requests
requests.get("https://site.example.ru/api/", verify="/etc/ssl/russian_trusted_root_ca.pem")

Note that verify with a file replaces the default set of roots: with this parameter other sites will no longer be verified. For requests to different sites, assemble a combined file from the system set and the Ministry root.

Java uses its own cacerts store:

sudo keytool -importcert -cacerts -alias russian-trusted-root-ca \
  -file russian_trusted_root_ca_pem.crt -storepass changeit -noprompt

In a Debian-based Docker image — the same steps as for Linux, in the Dockerfile:

COPY russian_trusted_root_ca_pem.crt /usr/local/share/ca-certificates/russian_trusted_root_ca.crt
RUN update-ca-certificates

General rule for any root certificates

Any root certificate in the trusted store — not only Russian ones — has the right to sign certificates for any domains. So the general security rule is simple: install root certificates only from the official source and only where they are really needed. In theory the owner of any trusted root’s private key can issue a certificate for an unrelated site, and for manually installed roots browsers do not require entries in Certificate Transparency logs. This is a property of the TLS design in general, not a feature of a specific authority; the same considerations apply to corporate roots and antivirus roots.

If you want to limit the scope of a certificate, there are simple options:

• do not install the root system-wide, and open the needed sites in Yandex Browser or Atom, where it is already built-in;
• install only in a separate browser or profile, for example in Firefox with a separate profile for such sites, without touching the system store;
• in programs — specify the root only for specific calls (--cacert), not for the whole system.

On work computers the decision to install is made by the company’s information security service: they also distribute the certificate via group policies if it is needed.

For site owners

Legal entities get the NCA certificate through Gosuslugi; issuance is free. If your site can obtain a certificate from a public CA (Let’s Encrypt, Google Trust Services and others work with Russian domains), use it: with the Ministry certificate visitors using ordinary browsers will see an error. The Ministry certificate makes sense when public CAs refuse your organization. About certificate issuance mechanics — in the article “Let’s Encrypt Certificates: ACME, domain validation, CAA and Certificate Transparency”.