Mincifry Certificates: How to Use Them Without Installing in Your System

1. The problem

You open a bank’s site or Gosuslugi. The browser yells “Connection is not private” and draws a red lock icon. Sound familiar? There’s almost always one reason: the site uses a Mincifry certificate, and your system knows nothing about that certificate authority.

This usually surfaces at the worst possible moment. An accountant calls in a panic, can’t log into online banking, a payment deadline is on fire, and you open a ticket to see the exact same picture: NET::ERR_CERT_AUTHORITY_INVALID or its cousin SEC_ERROR_UNKNOWN_ISSUER. You google it, land on the first how-to with screenshots, and it says plainly: download the file, double-click it, check “trust this certificate for identifying websites,” done.

And now you’re dragging a Russian certificate authority’s root certificate straight into the system-wide trusted root store, right next to real global CAs like DigiCert and Let’s Encrypt. From that point on, your system will accept any certificate signed by that root as valid. For any site. Not just for Gosuslugi, and not just for the one bank that started all this.

Technically, “connection is not private” doesn’t mean there’s no encryption. There is: the TLS handshake completes, the channel is encrypted. The browser is arguing about something else: it can’t build a chain of trust from the site’s certificate up to some root it already has marked as trusted. The chain breaks at the last link, the Mincifry root certificate, which simply isn’t in the default trust set of any operating system or browser.

That’s the exact problem this article is about. Installing a Mincifry certificate system-wide solves a five-minute problem and opens a door wider than needed, indefinitely. Nobody remembers later that this root was ever added, and even less often does anyone remove it once access to that one site is no longer needed. Below, we’ll cover how to get access to the sites you need without handing your system unlimited trust.

What you’ll get: working access to sites with Mincifry certificates through an isolated browser profile or curl scoped to a single file, with zero changes to the system trust store. Takes about fifteen minutes if you don’t fumble it. You’ll need a browser with a separate certificate store (Firefox is perfect for this), terminal access, and the certificate files themselves from an official source.

The list of sites using Mincifry certificates is wider than it looks at first glance. It’s not just the Gosuslugi portal itself, but also some sanctioned banks, certain insurance companies, some regional government services portals, and internal services at organizations whose certificate was revoked by a former foreign CA and who haven’t yet switched, or couldn’t switch, to an alternative commercial Russian provider. The current list of such domains is published at the same official source where you download the certificates themselves.

In this article:

• why the browser complains and what “untrusted root” actually means
• trust architecture and how the system store differs from the browser store
• step-by-step installation into an isolated profile on Windows, Linux, and via curl
• verifying what works and what doesn’t work where it shouldn’t
• common mistakes and how to fix them
• alternatives, including Yandex Browser and container isolation
• how to avoid redoing this whole quest six months from now

There’s nothing exotic in the recipe: every tool here is either already on your system or installs with one command from the standard repo. The exotic part starts when someone decides that “install system-wide” and “install so it works” are the same task. They’re not, and the second one is solved far more carefully than the first.

2. Why this happens

Why does a browser even argue with a site that clearly has a valid certificate? Let’s break it down.

• Foreign CAs revoked certificates from some Russian organizations. Sanctions hit not just banks as businesses, but also their ability to renew TLS certificates with DigiCert, Sectigo, and similar authorities. Renewing or reissuing a certificate with the old CA became impossible, and an expired certificate on a site means the same red lock, just for a different reason.
• Mincifry launched its own certificate authority. The national CA issues free certificates for Russian organizations’ websites to replace revoked ones, based on an application from a legal entity, taking about five business days. The root is called Russian Trusted Root CA, the issuing certificate is Russian Trusted Sub CA, and this exact pair shows up in the chain on sites like gosuslugi.ru and several banks.
• This root isn’t in the default trust list of any operating system or browser. Windows, macOS, the major Linux distros, and mobile OSes don’t include Russian Trusted Root CA in the base set of roots updated through Windows Update, Apple’s root store program, or the ca-certificates package on Linux. That’s a deliberate decision by vendors with their own criteria for admitting a CA into their trust program, not an oversight or technical bug.
• The browser sees the certificate chain but can’t find the root in its store. The server honestly sends the whole chain: the site certificate, the intermediate Sub CA, sometimes even the root. The format is fine, the signatures within the chain check out. The browser gets to the last link and finds nothing matching in its list of trusted roots. Hence the red lock: not because something’s broken, but because there’s nobody to vouch for the chain.
• There are two certificate variants: RSA and GOST. The RSA variant works in any modern browser once you add the root, because it uses a standard signature algorithm. The GOST variant is needed for encryption using Russian crypto algorithms and isn’t supported everywhere: Safari on macOS and iOS doesn’t understand it at all, no matter what you install.
• Online guides almost always recommend a system-wide install. It’s the fastest route for an average user who just wants to open a bank’s site once and forget about it. It’s also the widest in terms of consequences for system trust, because it extends the circle of trusted signers to the entire OS at once, instead of to one specific domain. Authors of mass-market guides rarely explain the difference and almost never warn about how to roll it back.
• Some organizations keep both certificate variants running in parallel. The same domains sometimes serve an RSA certificate, sometimes a GOST one, depending on load balancer settings or the specific edge node, which is why the same site can load fine in one browser and fail in another on the same machine with no apparent reason.

Worth understanding separately: for any certificate authority, including long-established global CAs, a browser’s trust isn’t an abstract given, it’s the result of passing a specific vendor’s audit program. Russian Trusted Root CA never went through Mozilla’s, Google’s, or Apple’s standard programs, and wasn’t intended to from the start: the root gained trust not through an independent technical audit, but administratively, through direct inclusion in specific Russian browsers and systems. For the average reader, that means one thing: treat how much you trust this root as a conscious decision, not a default, which is the main argument for isolation instead of a system-wide install.

3. Architecture: how browser trust works

Here’s the key part. Your browser and your operating system can have different trusted root stores. Windows and macOS keep their own system list, Chrome and Edge on Windows use that list, but Firefox doesn’t. Firefox has its own NSS store, separate for each user profile. By default, Firefox doesn’t even look at Windows’ system list unless you explicitly enable security.enterprise_roots.enabled.

Hence the recipe: if you add the Mincifry root not to the system store, but to the NSS database of a specific Firefox profile, trust stays within the boundaries of that profile. Everything else on the machine, your mail client, other browsers, system utilities, has no idea this root even exists.

This separation of stores isn’t an accident or an oversight. Mozilla has its own root certificate admission program with a public list of requirements and an open registry of decisions, and for years it’s maintained independence from whatever the host operating system uses. Hence the side effect that works in our favor: since Firefox doesn’t automatically inherit the system list, you can manage its list separately without touching anything else.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Need access to a site with a Mincifry certificate"] --> B{"One-time visit?"}
    B --> C["Yandex Browser"]
    B --> D{"Need isolation from the system?"}
    D --> E["Separate Firefox profile"]
    D --> F["Browser in a container"]
    E --> G["Certificate only in profile's NSS store"]
    F --> G
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style G fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style F fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412

Here’s what the trust check looks like during a connection, when the root lives in an isolated profile instead of the system.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#f8fafc',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'noteBkgColor': '#fefce8',
    'noteTextColor': '#713f12',
    'noteBorderColor': '#fbbf24',
    'actorBkg': '#f8fafc',
    'actorBorder': '#94a3b8',
    'actorTextColor': '#1e293b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'sequence': {
    'mirrorActors': false,
    'messageAlign': 'center',
    'actorMargin': 120,
    'width': 160,
    'noteMargin': 12
  }
}}%%
sequenceDiagram
    participant U as Profile browser
    participant S as Mincifry site
    participant N as Profile's NSS store
    U->>S: ClientHello
    S->>U: Certificate chain
    U->>N: Check root in store
    N->>U: Root found, trusted
    U->>S: Connection established

System requirements were checked against current versions at publication time. Before installing, check for fresh browser releases and updated root certificates at the official source.

4. Recipe: connecting without breaking your system

Before downloading files, it’s worth checking once which certificate variant the target site actually serves: RSA, GOST, or both in rotation. This saves time: you won’t have to blindly download both archives and figure out which one doesn’t fit.

openssl s_client -connect www.gosuslugi.ru:443 -showcerts < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -i "signature algorithm"

If you see sha256WithRSAEncryption or a similar RSA-related string in the output, the site is serving the RSA variant, and you can skip the GOST archive entirely. If you see GOST R 34.10-2012 or a similar mention, you’ll need the GOST variant specifically, and as a reminder, it won’t work in Safari no matter what you try with certificates.

Preparation. You’ll need the certificate file itself, downloaded from the official source, not from a three-year-old forum post. The current list of sites with Mincifry certificates and the download files themselves are hosted on the Gosuslugi portal, crt section. Before installing, check the SHA-256 fingerprint of the downloaded file against what’s listed on the official page: the values change with each reissue, so a fixed hash in this article would be wrong in six months.

Step one. Check the fingerprint of the downloaded file before trusting anything.

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

Result: a line like SHA256 Fingerprint=XX:XX:… Compare it visually with what’s listed on gosuslugi.ru/crt. If it doesn’t match, don’t install it, you downloaded the wrong file or from the wrong place.

Step two. Create a separate Firefox profile just for sites with Mincifry certificates. This is your sandbox, and it doesn’t overlap with your regular browsing.

firefox -CreateProfile "mincifry ~/mincifry-profile"

Result: a mincifry-profile folder appears in your home directory with a clean, empty Firefox profile. None of your bookmarks, passwords, or cookies ended up there.

Step three. Find the path to this profile’s NSS store. Firefox creates it on first launch of the profile, so open the profile once and immediately close it.

firefox -P mincifry -no-remote &
sleep 5
kill %1
ls -d ~/mincifry-profile/*.default*

Result: a path like /home/user/mincifry-profile/xxxxxxxx.mincifry. This is the directory with the cert9.db database, where we’ll add the root next.

Step four. Add the root and issuing certificates to exactly this database, without touching the system trust store.

PROFILE_DIR=~/mincifry-profile/xxxxxxxx.mincifry

certutil -A -n "Russian Trusted Root CA" \
  -t "C,," \
  -i russian_trusted_root_ca_pem.crt \
  -d sql:$PROFILE_DIR

certutil -A -n "Russian Trusted Sub CA" \
  -t ",," \
  -i russian_trusted_sub_ca.crt \
  -d sql:$PROFILE_DIR

Note the difference in trust flags. The root gets “C,,” – trust for validating websites. The issuing certificate gets empty flags, it’s just part of the chain and isn’t a trusted authority on its own.

Step five. Launch the profile and check the target site.

firefox -P mincifry -no-remote https://www.gosuslugi.ru

Result: the lock turns green, the page loads without complaints. Meanwhile your regular Firefox profile and the system store remain untouched.

Step six, for those living in Chrome or Chromium instead of Firefox. On Linux, these browsers also use NSS, but they keep the database in a different location, in the ~/.pki/nssdb directory for a specific user, not the system store. The isolation is less complete than with a separate Firefox profile, because there’s one database per user and all Chromium-based browsers see it, but it still doesn’t depend on the system trust store.

mkdir -p ~/.pki/nssdb
certutil -N -d sql:$HOME/.pki/nssdb --empty-password

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

certutil -A -n "Russian Trusted Sub CA" \
  -t ",," \
  -i russian_trusted_sub_ca.crt \
  -d sql:$HOME/.pki/nssdb

Result: Chrome and Chromium for this user now see the chain as trusted, while the system /etc/ssl/certs remains unchanged, and other apps that don’t read NSS know nothing about the new root.

If your site check lives not in a bash script but in a Python utility built on requests, the principle is identical: point to the certificate file path with the verify parameter, don’t touch the system set of roots that the certifi library uses by default.

import requests

response = requests.get(
    "https://www.gosuslugi.ru",
    verify="/opt/certs/chain.pem"
)
print(response.status_code)

Result: 200 in the console, no SSLError raised, and the system certificate set used by this same script’s other HTTPS requests to different services stays untouched.

A separate case: console scripts and monitoring. If you have a Zabbix check or a cron curl job hitting a site with a Mincifry certificate, you don’t need to drag the root into the system for the sake of one check. Point to the file directly.

curl --cacert /opt/certs/russian_trusted_root_ca_pem.crt \
  -I https://www.gosuslugi.ru

Result: HTTP/2 200, no SSL errors, and the system trust store stays out of it again.

Step seven, for macOS users. Same logic: Firefox on macOS also uses its own profile NSS database and doesn’t read the system Keychain by default, so the profile and certutil recipe carries over one to one, just with different paths. Safari and Chrome on macOS, unlike Firefox, talk to the system Keychain, and there you have to choose between the login keychain of the current user and the system keychain shared by all users.

security add-trusted-cert -d -r trustRoot \
  -k ~/Library/Keychains/login.keychain-db \
  russian_trusted_root_ca_pem.crt

Note the -k flag pointing specifically to the current user’s login.keychain-db, not System.keychain. Trust in this case extends to all apps run by this user that read the Keychain, but doesn’t affect other users on the machine and doesn’t require admin rights, unlike the system keychain.

5. Verification

Check the certificate list in the Firefox profile via about:config or the graphical certificate manager inside that profile.

certutil -L -d sql:$PROFILE_DIR

The output should show “Russian Trusted Root CA” with the C flag and “Russian Trusted Sub CA” without the C flag. If these lines are missing, the install didn’t go through, go back to step four.

Check that the system store is untouched. On Linux:

trust list | grep -i "russian trusted"

The result should be empty. If something turned up, the root ended up in the system after all, and it’s worth rereading the recipe section.

Check the target site with curl pointing to the certificate file, as shown above. A 200 response code and no handshake errors is a good sign.

It’s worth looking at the chain itself rather than trusting the browser’s word for it. openssl’s s_client command shows the full chain exactly as the server actually sent it.

openssl s_client -connect www.gosuslugi.ru:443 -showcerts < /dev/null | grep -E "subject|issuer"

Result: a list of subject and issuer values for each certificate in the chain. The last issuer line should resolve to “The Ministry of Digital Development” or a similar name for the National Certification Authority. If it shows something else, the problem isn’t trust, it’s the site itself.

In the browser itself, don’t rely on the lock color alone. Open the certificate details via the lock icon in the address bar and check with your own eyes that the chain reaches Russian Trusted Root CA rather than breaking earlier. In Firefox this is View Certificate, in Chromium it’s the Connection is secure tab, then Certificate is valid.

6. Troubleshooting

If something in the recipe went wrong, the fastest way back to a clean state isn’t fixing things in place, it’s deleting the whole profile directory and starting over from the profile creation step. A plain Firefox profile without Mincifry certificates is created in seconds, while a broken NSS database sometimes takes longer to fix than to just recreate.

rm -rf ~/mincifry-profile
firefox -CreateProfile "mincifry ~/mincifry-profile"

It’s not as bad as it looks at this point in the article. It’s much simpler if you don’t skip the fingerprint check step.

A separate note on the unknown issuer error in curl. It almost always happens for one reason: the file passed via –cacert contains only the root certificate, and the intermediate Sub CA was left out. curl, unlike a browser, can’t automatically fetch missing chain links from the internet, so the chain needs to be assembled by hand and passed in full.

7. Alternatives

System-wide install. The fastest route, fine for disposable personal machines you don’t care about, and for cases where the user physically can’t deal with profiles and NSS databases. For a sysadmin’s workstation or a server running anything else, I wouldn’t risk extending trust for the whole system for the sake of one bank’s website. Especially on a server: system-wide trust there can unexpectedly affect automation that talks HTTPS to something else entirely, and nobody will remember a year later why a Russian root is sitting in the trust store.

Yandex Browser. It ships with Mincifry certificates already baked in, nothing to add, the site just opens. The upside: zero effort and zero chance of messing up an NSS database. The downside: you’ll need to keep this browser around specifically for sites with these certificates if your main browser is something else, and it’s still a separate piece of software on the system with its own updates and telemetry to keep an eye on.

Container isolation. For the paranoid and for corporate scenarios: run the browser in a separate Docker container with a profile and certificates already configured inside. Full isolation from the host system, down to a separate network namespace, but the resource overhead is noticeable, and for visiting a site once a month it’s clearly overkill.

Portable Firefox build. If you don’t want to touch even an installed Firefox, you can keep a separate portable version in your own folder, fully independent from the main install, with its own profile and its own NSS database out of the box. Good for a USB drive you carry between machines when you need a guaranteed clean tool for a single task.

docker run --rm -it --shm-size=2g \
  -v mincifry_profile:/home/user/.mozilla \
  -e DISPLAY=$DISPLAY \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  jlesage/firefox

I chose the separate Firefox profile as the main recipe in this article because it doesn’t require extra software or container resources, and the isolation ends up just as reliable. It makes sense to add a container on top of this recipe, not instead of it, if your organization’s security policy requires physically separating the browser process from the host system, not just separating the trust store.

A separate word about “just ignore the problem and open the site in a system browser under a different non-admin user.” Sounds like isolation, isn’t actually one: another local user on the same machine still uses the same system certificate store for Windows or Linux, if that user’s browser relies on it. Separating OS users solves the file access question, but not the TLS trust question. For that you need isolation at the level of a specific browser profile’s NSS database, like in the main recipe.

If the certificate isn’t just for you but for a dozen workstations in a department, manual GUI installation on each machine turns into its own special hell. The same isolation principle applies here, just rolled out through automation instead of mouse clicks.

For a Windows fleet, a ready-made Firefox profile with certificates already added can be packaged once and rolled out via group policy as a plain file resource, copying the profile directory into each user’s AppData at logon, with zero changes to the Windows certificate store. Same logic I covered in the article about distributing Browser Shortcut Creator via GPO: take a prebuilt artifact and copy it with a login script, instead of touching the registry or system trust policies.

$src = "\\fileserver\deploy\mincifry-profile"
$dst = "$env:APPDATA\Mozilla\Firefox\Profiles\mincifry"

if (-not (Test-Path $dst)) {
    Copy-Item -Path $src -Destination $dst -Recurse
}

For a Linux fleet, the same thing is handled by an Ansible playbook: copy a ready-made profile directory with a pre-built cert9.db database to every machine in the group, without a single copy module touching /usr/local/share/ca-certificates and without a follow-up update-ca-certificates call, which is exactly what makes an install system-wide.

ansible workstations -m copy \
  -a "src=/opt/mincifry-profile/ dest=~/mincifry-profile/ mode=0700"

The result is the same whether it’s one machine or a hundred: trust lives in the copied profile directory, and the system trust store on every workstation stays exactly as it was before the rollout.

8. Security

The main risk of a system-wide root install isn’t Mincifry itself, it’s the principle of unlimited trust. Any certificate signed by that root will be accepted by your system as genuine, for any domain, not just gosuslugi.ru. That’s a classic man-in-the-middle setup, just legal and voluntary. Isolation at the browser profile level removes this problem entirely: trust is bounded by a single profile and a single set of sites.

If you went the container isolation route, keep the container unprivileged and don’t mount extra sockets beyond X11 or Wayland, which are needed to display the window.

Restrict physical access to the profile directory the same way you’d restrict access to any directory with private browser data: there are cookies in there, and possibly saved passwords for the sites protected by this certificate.

A separate note on the scale of risk for organizations versus a home machine. If you’re rolling out a profile like this to employee workstations via group policy, don’t turn the task into a system-wide install “for simplicity.” That creates a single point through which, if the certificate authority itself is compromised or an attacker spoofs a certificate, the entire fleet of machines gets hit at once, not just access to one site. An isolated profile confines that blast radius to a single application’s boundary.

Never download Mincifry certificates from mirrors or forums. A certificate file isn’t a proprietary distro image you can re-upload anywhere, it’s a cryptographic anchor of trust, and a tampered copy on a third-party site is a ready-made attack vector. There’s one official source: the Gosuslugi portal, crt section.

It’s worth reflecting on how many guides across the internet propose solving a one-site problem by changing trust for the whole machine. The difference between “open one site” and “trust one authority for everything” seems trivial until the first incident, and after the first certificate-spoofing incident it doesn’t seem trivial anymore.

Keep in mind the flip side of isolation too: if the root is added only to one profile and not the system, every other app that talks directly to Mincifry-protected sites, thick banking clients, desktop apps for government services, some VPN clients with their own TLS stack, will keep complaining about the certificate regardless of your browser settings. For those, you’ll have to find a dedicated trust setting for the CA file inside the app’s own configuration, following the same scoped-trust principle, rather than dragging the problem back into the system store just because that’s the one thing that worked for a particular client.

A separate note on HSTS and pinning. Some major sites use HTTP Strict Transport Security along with hardcoded lists of acceptable certificates baked into the browser. For Mincifry domains this usually isn’t an issue, since those sites aren’t on the preloaded HSTS list with hard pinning, but if you’re dealing with a corporate domain that does use pinning, an isolated browser profile is the only safe way to test a new root without risking breaking trust on production user machines.

9. Prevention

Backups. Back up the entire mincifry-profile directory, including cert9.db, so you don’t have to re-download and re-add certificates after a system reinstall. Archive the profile to external storage once a month.

tar -czf mincifry-profile-backup.tar.gz ~/mincifry-profile

Updates. Mincifry periodically reissues certificates, especially GOST variants with an upcoming expiration. Check for updated files on gosuslugi.ru/crt once a quarter and recheck the fingerprint before replacing anything in the NSS database. Before updating, save a copy of the current database somewhere, so you have something to roll back to if the new file turns out to be broken.

cp $PROFILE_DIR/cert9.db $PROFILE_DIR/cert9.db.bak

Test restoring from backup ahead of time, not at the moment the profile actually breaks. Extract the archive to a test directory and confirm certutil sees the same entries as before.

tar -xzf mincifry-profile-backup.tar.gz -C /tmp/restore-test
certutil -L -d sql:/tmp/restore-test/mincifry-profile/xxxxxxxx.mincifry

Result: the same pair of Root CA and Sub CA lines as in the working profile. If the backup is good, restoring after a system reinstall takes a couple of minutes: unpack the archive, launch Firefox with the -profile flag pointing to the unpacked directory, and the sites open again without a single extra click.

Monitoring. If the certificate is used in automation, say in Zabbix curl checks, add an alert for the certificate file’s expiration date, not just for the HTTP response code.

openssl x509 -in russian_trusted_root_ca_pem.crt -noout -enddate

If several servers and cron jobs end up using the certificate file, it’s simpler to put together a small check script and add it as a separate item in your existing monitoring, rather than keeping the expiration date in your head.

#!/bin/bash
CERT=/opt/certs/russian_trusted_root_ca_pem.crt
DAYS_LEFT=$(( ($(date -d "$(openssl x509 -in $CERT -noout -enddate | cut -d= -f2)" +%s) - $(date +%s)) / 86400 ))

if [ "$DAYS_LEFT" -lt 30 ]; then
  echo "Mincifry certificate expires in $DAYS_LEFT days, time to renew"
  exit 1
fi

It only takes one weak link to bring everything down. One forgotten expired certificate copy in production kills monitoring for the whole department on a Monday morning, and of course it happens right when everyone else is on vacation and you’re the only one left to sort it out.

Every six months, it’s worth checking not just the certificate file itself, but whether your specific site still appears on the list of organizations Mincifry has issued a certificate to. The organization may have switched to a commercial Russian TLS certificate provider and dropped the national CA, and then the chain on the site will change on its own one day, without warning, and your isolated profile with the outdated root will start complaining about a perfectly ordinary new chain from a different CA. In that case the fix goes the other way: you no longer need to remove Russian Trusted Root CA from the profile, the regular set of trusted roots will handle it on its own.

10. FAQ

Why doesn’t a site with a Mincifry certificate open after installation?

Most often the certificate was added to the wrong profile or the wrong NSS database, or the browser was launched without the -P flag pointing to the profile name. Run certutil -L -d with the database path and confirm you see both the Root and Sub CA lines.

How do I check that a Mincifry certificate is working correctly?

Open the target site in the profile where the certificate was added and look at the lock icon in the address bar. For scripts, use curl with the –cacert flag and check for a 200 response code with no SSL handshake errors.

What do I do if the browser shows an unknown issuer error after installation?

Usually the intermediate Sub CA certificate is missing from the chain. Add it separately with empty trust flags next to the root, or combine both certificates into a single chain.pem file for curl.

How is an isolated profile different from a system-wide install?

A system-wide install extends trust in the root to every app that uses the system certificate store, which potentially means any site on the internet. An isolated profile limits trust to a specific browser profile and leaves the rest of the system untouched.

Is it safe to use Mincifry certificates at all?

The certificate itself isn’t dangerous, it’s just a cryptographic signature from a specific certificate authority for a site. The risk comes from the scale of trust you hand that authority. Limit the scale through isolation, and the risk drops to the level of one specific site.

Do I need to install both RSA and GOST certificates?

Not always. If the target site only serves the RSA variant, you can skip GOST entirely. Install both only if you already know the site uses GOST encryption or switches between variants on different requests, as sometimes happens with large load balancers.

Why is the certificate installed differently on a phone than on a computer?

Android and iOS don’t have the familiar concept of a separate browser profile with its own NSS database, the way desktop Firefox does. On mobile systems, a certificate gets installed through the system security settings and becomes effectively available to every app on the device, so for a phone it makes more sense to just use Yandex Browser with trust already built in, rather than wrangling with iOS or Android system settings.

Can I use a Mincifry certificate in several browsers at once?

Yes, nothing stops you from setting up a separate isolated profile in each browser you use. The only hassle is that you’ll need to add the certificates to each NSS database individually, there’s no shared central store between Firefox, Chromium, and other browsers on one machine, and the architecture doesn’t provide for one.

11. Takeaway

We did the same thing as the typical top-of-search guide, with one important difference: trust in the Mincifry root now lives within the boundaries of a separate browser profile instead of spreading across the whole system. Bank and Gosuslugi sites open just fine, and the rest of the system has no idea this certificate authority even exists. Monitoring scripts and curl checks work with the same certificate file directly, also without a single line added to the system trust store.

From here it’s just routine: check the certificate’s validity against the official source once a quarter, back up the profile along with cert9.db once a month, and forget about the red lock until the next reissue. The one thing worth keeping in mind: after a full system reinstall, you don’t need to restore the whole system, just one specific profile directory, and access comes back in a couple of minutes. If the site still won’t open after all these steps, or curl complains about something new, drop a comment, we’ll sort it out.