Сертификаты Минцифры: как не ставить их в систему и не сойти с ума

<h2>1. Диагноз</h2> <p>Открываешь сайт банка или Госуслуг. Браузер орёт «Подключение не защищено» и рисует красный замок. Знакомо? Причина почти всегда одна: сайт использует сертификат Минцифры, а твоя система про такой центр сертификации ничего не знает.</p> <p>Ситуация обычно всплывает не в лучший момент. Бухгалтер звонит в панике — не может залогиниться в клиент-банк, дедлайн по платёжке горит, а ты открываешь тикет и видишь ровно ту же картину: NET::ERR_CERT_AUTHORITY_INVALID или его собрат SEC_ERROR_UNKNOWN_ISSUER. Гуглишь, натыкаешься на первую инструкцию с картинками, и там прямым текстом: скачай файл, дважды кликни, поставь галку «доверять при идентификации сайтов», готово.</p> <p>И вот ты уже тащишь корневой сертификат российского удостоверяющего центра прямо в системное хранилище доверенных корней, туда же, где сидят настоящие мировые CA вроде DigiCert и Let’s Encrypt. С этого момента любой сертификат, подписанный этим корнем, твоя система примет как валидный. Для любого сайта. Не только для Госуслуг и не только для сайта того самого банка, ради которого всё затевалось.</p> <p>Технически «подключение не защищено» означает не то, что шифрования нет. Оно есть, TLS-хэндшейк проходит, канал зашифрован. Браузер спорит с другим: он не может выстроить цепочку доверия от сертификата сайта до какого-то корня, который у него уже прописан как доверенный. Цепочка обрывается на последнем звене — на корневом сертификате Минцифры, которого просто нет в базовом наборе ни у одной операционной системы или браузера по умолчанию.</p> <p>Это и есть та самая проблема, ради которой пишу статью. Установка сертификата минцифры в систему решает сиюминутную задачу за пять минут и открывает дверь шире, чем нужно, на неопределённый срок. Никто потом не помнит, что этот корень вообще был добавлен, и уж тем более никто не убирает его, когда доступ к конкретному сайту перестал быть нужен. Дальше разберём, как получить доступ к нужным сайтам, не отдавая системе неограниченный кредит доверия.</p> <p>Что получишь на выходе: рабочий доступ к сайтам с сертификатами Минцифры через изолированный профиль браузера или через curl со скоупом на один файл, без изменений в системном хранилище. Займёт минут пятнадцать, если руки не из другого места. Понадобится браузер с отдельным хранилищем сертификатов (Firefox подходит идеально), доступ в терминал и сами файлы сертификатов с официального источника.</p> <p>Круг сайтов, которые используют сертификаты Минцифры, шире, чем кажется на первый взгляд. Это не только сам портал Госуслуг, но и часть банков под санкциями, отдельные страховые компании, некоторые региональные порталы госуслуг и внутренние сервисы организаций, которым отозвали сертификат у прежнего иностранного CA и которые пока не успели или не смогли перейти на альтернативного российского коммерческого поставщика. Актуальный перечень таких доменов публикуется на том же официальном источнике, откуда качаются сами сертификаты.</p> <p>В статье:</p> <ul> <li>почему браузер ругается и что на самом деле означает «недоверенный корень»</li> <li>архитектура доверия и чем системное хранилище отличается от хранилища браузера</li> <li>пошаговая установка сертификата в изолированный профиль на <a class="wpil_keyword_link" href="https://it-apteka.com/category/windows-server/" target="_blank" rel="noopener" title="Windows Server" data-wpil-keyword-link="linked" data-wpil-monitor-id="3341">Windows</a>, Linux и через curl</li> <li>проверка что всё работает и что не работает лишнее</li> <li>частые ошибки и их разбор</li> <li>альтернативы, включая Яндекс Браузер и контейнерную изоляцию</li> <li>что делать, чтобы через полгода не разгребать этот квест заново</li> </ul> <p>Ничего экзотического в рецепте нет — все инструменты уже стоят в системе или ставятся одной командой из штатного репозитория. Экзотика начинается там, где кто-то решает, что «поставить в систему» и «поставить, чтобы работало» — это одно и то же. Это разные задачи, и вторая решается заметно аккуратнее первой.</p> <h2>2. Причины</h2> <p>Почему браузер вообще спорит с сайтом, у которого явно есть валидный сертификат? Разбираем по пунктам.</p> <ul> <li><strong>Иностранные CA отозвали сертификаты у части российских организаций.</strong> Санкции затронули не только банки как бизнес, но и их возможность продлевать TLS-сертификаты у DigiCert, Sectigo и подобных центров. Продлить или перевыпустить сертификат у прежнего CA стало невозможно, а истёкший сертификат для сайта — это тот же красный замок, только по другой причине.</li> <li><strong>Минцифры запустило собственный удостоверяющий центр.</strong> Национальный удостоверяющий центр выпускает бесплатные сертификаты для сайтов российских организаций взамен отозванных, по заявке от юрлица примерно за пять рабочих дней. Корень называется Russian Trusted Root CA, выпускающий сертификат — Russian Trusted Sub CA, и именно эта связка появляется в цепочке у сайтов вроде gosuslugi.ru и части банков.</li> <li><strong>Этого корня нет в списке доверенных ни у одной операционной системы или браузера по умолчанию.</strong> Ни Windows, ни macOS, ни основные <a class="wpil_keyword_link" href="https://it-apteka.com/category/linux/" target="_blank" rel="noopener" title="Linux" data-wpil-keyword-link="linked" data-wpil-monitor-id="3345">Linux</a>-дистрибутивы, ни мобильные ОС не включают Russian Trusted Root CA в базовый набор корней, который обновляется через Windows Update, программу root store у Apple или через пакет ca-certificates в Linux. Это осознанное решение вендоров с их собственными критериями допуска CA в программу доверия, а не забывчивость и не техническая ошибка.</li> <li><strong>Браузер видит цепочку сертификатов, но не находит корень в своём хранилище.</strong> Сервер честно присылает всю цепочку — сертификат сайта, промежуточный Sub CA, иногда даже корень. Формат нормальный, подписи внутри цепочки сходятся. Браузер доходит до последнего звена и не находит в своём списке доверенных корней ничего похожего. Отсюда и красный замок — не потому что что-то сломано, а потому что цепочку некому подтвердить.</li> <li><strong>Есть два варианта сертификата: RSA и ГОСТ.</strong> RSA-вариант работает в любом современном браузере после добавления корня, потому что использует привычный алгоритм подписи. ГОСТ-вариант нужен для шифрования по российским криптоалгоритмам и поддерживается не везде: например, Safari на macOS и iOS его не понимает вообще, что бы ты ни устанавливал.</li> <li><strong>Инструкции в интернете почти всегда советуют системную установку.</strong> Это самый быстрый путь для рядового пользователя, который просто хочет один раз зайти на сайт банка и забыть про проблему. Он же самый широкий по последствиям для доверия системы, потому что расширяет круг доверенных подписантов на всю ОС сразу, а не на один нужный домен. Авторы массовых инструкций редко объясняют разницу и почти никогда не предупреждают про откат.</li> <li><strong>Часть организаций держит оба варианта сертификата параллельно.</strong> Одни и те же домены иногда отдают то RSA, то ГОСТ-сертификат в зависимости от настроек балансировщика или конкретного edge-узла, из-за чего один и тот же сайт может открываться в одном браузере и не открываться в другом на той же машине без видимой причины.</li> </ul> <p>Отдельно стоит понимать, что для любого удостоверяющего центра, включая давно устоявшиеся мировые CA, доверие браузера — это не абстрактная данность, а результат прохождения программы аудита конкретного вендора. У Russian Trusted Root CA такого прохождения через стандартные программы Mozilla, Google или Apple не было и не предполагалось изначально — корень получил доверие не через технический аудит независимо от государства, а административным путём, через прямое включение в конкретные российские браузеры и системы. Для рядового читателя это означает одно: относиться к масштабу доверия этому корню стоит осознанно, а не по умолчанию, что и есть главный аргумент в пользу изоляции вместо системной установки.</p> <h2>3. Архитектура: как работает доверие браузера</h2> <p>Смотри, тут вся соль. У браузера и у операционной системы могут быть разные хранилища доверенных корней. Windows и macOS хранят свой системный список, Chrome и Edge на Windows этим списком пользуются, а вот Firefox — нет. У Firefox своё собственное хранилище NSS, отдельное для каждого профиля пользователя. По умолчанию Firefox даже не заглядывает в системный список Windows, если явно не включить настройку security.enterprise_roots.enabled.</p> <p>Отсюда и рецепт: если добавить корень Минцифры не в системное хранилище, а в NSS-базу конкретного профиля Firefox, доверие останется в границах этого профиля. Все остальные приложения на машине — почтовый клиент, другие браузеры, системные утилиты — вообще не узнают, что этот корень существует.</p> <p>Такое разделение хранилищ не случайность и не недоработка. У Mozilla собственная программа допуска корневых сертификатов с публичным списком требований и открытым реестром решений, и она годами держит курс на независимость от того, чем пользуется конкретная операционная система. Отсюда и побочный эффект, который нам на руку: раз Firefox не наследует системный список автоматически, значит можно управлять его списком отдельно, не трогая всё остальное.</p> <pre class="mermaid">%%{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["Нужен доступ к сайту с сертификатом Минцифры"] --> B{"Разовый визит?"} B --> C["Яндекс Браузер"] B --> D{"Нужна изоляция от системы?"} D --> E["Отдельный профиль Firefox"] D --> F["Контейнер с браузером"] E --> G["Сертификат только в NSS профиля"] 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 </pre> <p>Вот как выглядит проверка доверия во время подключения, когда корень лежит в изолированном профиле, а не в системе.</p> <pre class="mermaid">%%{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 Браузер профиля participant S as Сайт Минцифры participant N as NSS база профиля U->>S: ClientHello S->>U: Цепочка сертификатов U->>N: Проверка корня в базе N->>U: Корень найден, доверие есть U->>S: Соединение установлено </pre> <p>Системные требования проверены на актуальных версиях на момент публикации. Перед установкой проверь свежие релизы браузера и наличие обновлений корневых сертификатов на официальном источнике.</p> <table> <tbody> <tr> <th>Компонент</th> <th>Минимальная версия</th> <th>Комментарий</th> </tr> <tr> <td>Windows</td> <td>10 / 11</td> <td>Не трогаем системное хранилище вообще</td> </tr> <tr> <td>Linux</td> <td>Ubuntu 22.04+ / <a class="wpil_keyword_link" href="https://it-apteka.com/tag/debian/" target="_blank" rel="noopener" title="Debian" data-wpil-keyword-link="linked" data-wpil-monitor-id="3338">Debian</a> 12+</td> <td>Работаем через NSS-базу профиля</td> </tr> <tr> <td>macOS</td> <td>Ventura и новее</td> <td>Тот же принцип, Firefox своя база</td> </tr> <tr> <td>Firefox</td> <td>115 ESR и новее</td> <td>Собственное хранилище NSS по умолчанию</td> </tr> <tr> <td>libnss3-tools (certutil)</td> <td>любая свежая из репозитория</td> <td>Нужен для ручной установки в NSS-базу</td> </tr> <tr> <td>curl</td> <td>7.70 и новее</td> <td>Поддержка флага —cacert без танцев</td> </tr> </tbody> </table> <table> <tbody> <tr> <th>Порт</th> <th>Протокол</th> <th>Назначение</th> <th>Доступен снаружи?</th> </tr> <tr> <td>443</td> <td>TCP/HTTPS</td> <td>Исходящее соединение к сайтам с сертификатом Минцифры</td> <td>Нет, только исходящее с твоей машины</td> </tr> </tbody> </table> <h2>4. Рецепт: подключаемся, не ломая систему</h2> <p>Перед тем как качать файлы, полезно один раз посмотреть, какой именно вариант сертификата отдаёт нужный сайт — RSA, ГОСТ или оба по очереди. Это экономит время: не придётся вслепую тащить оба архива и разбираться, какой из них не подошёл.</p> <pre><code class="language-bash"> openssl s_client -connect www.gosuslugi.ru:443 -showcerts < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -i "signature algorithm" </code></pre> <p>Если в выводе видишь sha256WithRSAEncryption или похожую строку с RSA, значит сайт отдаёт RSA-вариант, и ГОСТ-архив можно вообще не трогать. Если видишь GOST R 34.10-2012 или подобное упоминание, потребуется именно ГОСТ-вариант, а он, напомню, не открывается в Safari ни при каких плясках с бубном вокруг сертификатов.</p> <p>Подготовка. Понадобится сам файл сертификата, скачанный из официального источника, а не с форума трёхлетней давности. Актуальный список сайтов с сертификатами Минцифры и сами файлы для скачивания лежат на портале <a href="https://www.gosuslugi.ru/crt" target="_blank" rel="noopener">Госуслуги в разделе crt</a>. Перед установкой сверь SHA-256 отпечаток скачанного файла с тем, что указан на официальной странице — значения меняются при перевыпуске, поэтому фиксированный хэш в статье через полгода будет враньём.</p> <p>Шаг первый. Проверь отпечаток скачанного файла, прежде чем доверять хоть чему-то.</p> <pre><code class="language-bash"> openssl x509 -in russian_trusted_root_ca_pem.crt -noout -fingerprint -sha256 </code></pre> <p>Результат: строка вида SHA256 Fingerprint=XX:XX:… Сверь её глазами с тем, что написано на gosuslugi.ru/crt. Не совпало — не устанавливай, скачал не то или не оттуда.</p> <p>Шаг второй. Создай отдельный профиль Firefox только для сайтов с сертификатами Минцифры. Это твоя песочница, и она не пересекается с обычным браузингом.</p> <pre><code class="language-bash"> firefox -CreateProfile "mincifry ~/mincifry-profile" </code></pre> <p>Результат: в домашней папке появится каталог mincifry-profile с чистым, пустым профилем Firefox. Никаких твоих закладок, паролей и куки туда не попало.</p> <p>Шаг третий. Найди путь к NSS-базе этого профиля. Firefox создаёт её при первом запуске профиля, поэтому сначала один раз открой профиль и сразу закрой.</p> <pre><code class="language-bash"> firefox -P mincifry -no-remote & sleep 5 kill %1 ls -d ~/mincifry-profile/*.default* </code></pre> <p>Результат: путь вида /home/user/mincifry-profile/xxxxxxxx.mincifry. Это и есть каталог с базой cert9.db, куда сейчас добавим корень.</p> <p>Шаг четвёртый. Добавь корневой и выпускающий сертификаты именно в эту базу, не трогая системный trust store.</p> <pre><code class="language-bash"> 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 </code></pre> <p>Обрати внимание на разницу флагов доверия. Корню даём «C,,» — доверие для валидации сайтов. Выпускающему сертификату оставляем пустые флаги, он просто часть цепочки и сам по себе доверенным центром не становится.</p> <p>Шаг пятый. Запусти профиль и проверь целевой сайт.</p> <pre><code class="language-bash"> firefox -P mincifry -no-remote https://www.gosuslugi.ru </code></pre> <p>Результат: замок зелёный, страница открывается без ругани. При этом твой обычный профиль Firefox и системное хранилище остались нетронуты.</p> <p>Шаг шестой, для тех кто живёт в Chrome или Chromium вместо Firefox. На Linux эти браузеры тоже используют NSS, только базу держат в другом месте — в каталоге ~/.pki/nssdb конкретного пользователя, а не системный store. Изоляция получается не такая полная, как с отдельным профилем Firefox, потому что база одна на всего пользователя и все Chromium-based браузеры её видят, но от системного trust store всё равно не зависит.</p> <pre><code class="language-bash"> 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 </code></pre> <p>Результат: Chrome и Chromium на этом пользователе видят цепочку как доверенную, при этом системный /etc/ssl/certs так и остался без изменений, и остальные приложения, которые не читают NSS, про новый корень ничего не знают.</p> <p>Если проверка сайта живёт не в <a class="wpil_keyword_link" href="https://it-apteka.com/tag/bash/" target="_blank" rel="noopener" title="Bash" data-wpil-keyword-link="linked" data-wpil-monitor-id="3340">bash</a>-скрипте, а в Python-утилите на базе requests, принцип точно такой же: указывай путь к файлу сертификата в параметре verify, а не трогай системный набор корней, с которым работает библиотека certifi по умолчанию.</p> <pre><code class="language-python"> import requests response = requests.get( "https://www.gosuslugi.ru", verify="/opt/certs/chain.pem" ) print(response.status_code) </code></pre> <p>Результат: 200 в консоли, без исключения SSLError, и системный набор сертификатов, с которым работают остальные HTTPS-запросы этого же скрипта к другим сервисам, остаётся нетронутым.</p> <p>Отдельная история — консольные скрипты и <a class="wpil_keyword_link" href="https://it-apteka.com/category/monitoring/" target="_blank" rel="noopener" title="Мониторинг" data-wpil-keyword-link="linked" data-wpil-monitor-id="3343">мониторинг</a>. Если у тебя Zabbix-проверка или curl в крон-джобе долбится в сайт с сертификатом Минцифры, не нужно тащить корень в систему ради одной проверки. Указывай файл напрямую.</p> <pre><code class="language-bash"> curl --cacert /opt/certs/russian_trusted_root_ca_pem.crt \ -I https://www.gosuslugi.ru </code></pre> <p>Результат: HTTP/2 200, без ошибок SSL, и системный trust store снова ни при чём.</p> <p>Шаг седьмой, для владельцев macOS. Логика та же самая: Firefox на macOS тоже использует собственную NSS-базу профиля и не читает системную связку ключей Keychain по умолчанию, поэтому рецепт с profile и certutil переносится один в один, только пути отличаются. Safari и Chrome на macOS, в отличие от Firefox, обращаются к системному Keychain, и там уже приходится выбирать между login-связкой текущего пользователя и системной связкой всех пользователей машины.</p> <pre><code class="language-bash"> security add-trusted-cert -d -r trustRoot \ -k ~/Library/Keychains/login.keychain-db \ russian_trusted_root_ca_pem.crt </code></pre> <p>Обрати внимание на ключ -k с путём именно к login.keychain-db текущего пользователя, а не к System.keychain. Доверие в этом случае распространяется на все приложения этого пользователя, которые читают Keychain, но не затрагивает других пользователей машины и не требует прав администратора, в отличие от системной связки.</p> <h2>5. Проверка</h2> <p>Проверь список сертификатов в профиле Firefox через about:config или графический менеджер сертификатов внутри этого профиля.</p> <pre><code class="language-bash"> certutil -L -d sql:$PROFILE_DIR </code></pre> <p>В выводе должны быть строки «Russian Trusted Root CA» с флагом C и «Russian Trusted Sub CA» без флага C. Если строк нет — установка не прошла, возвращайся к шагу четыре.</p> <p>Проверь, что системное хранилище не тронуто. На Linux:</p> <pre><code class="language-bash"> trust list | grep -i "russian trusted" </code></pre> <p>Результат должен быть пустым. Если что-то нашлось, значит корень всё же попал в систему, и стоит перечитать раздел про рецепт заново.</p> <p>Проверь конкретный сайт curl-ом с указанием файла сертификата, как показано выше. Код ответа 200 и отсутствие ошибок handshake — хороший знак.</p> <p>Полезно посмотреть на саму цепочку сертификатов глазами, а не доверять браузеру на слово. Команда s_client из openssl показывает всю цепочку так, как её реально прислал сервер.</p> <pre><code class="language-bash"> openssl s_client -connect www.gosuslugi.ru:443 -showcerts < /dev/null | grep -E "subject|issuer" </code></pre> <p>Результат: список subject и issuer по каждому сертификату в цепочке. Последняя строка issuer должна упираться в «The Ministry of Digital Development» или похожее имя Национального удостоверяющего центра — если там что-то другое, проблема не в доверии, а в самом сайте.</p> <p>В самом браузере не полагайся только на цвет замка. Открой информацию о сертификате через иконку замка в адресной строке и глазами убедись, что цепочка доходит до Russian Trusted Root CA, а не обрывается раньше. Для Firefox это Просмотр сертификата, для Chromium — вкладка Connection is secure, дальше Certificate is valid.</p> <h2>6. Осложнения</h2> <p>Если что-то из рецепта пошло не так, самый быстрый способ вернуться к чистому состоянию — не чинить на месте, а удалить весь каталог профиля и начать заново с шага создания профиля. Обычный профиль Firefox без сертификатов Минцифры создаётся за секунды, а сломанная NSS-база иногда чинится дольше, чем создаётся заново.</p> <pre><code class="language-bash"> rm -rf ~/mincifry-profile firefox -CreateProfile "mincifry ~/mincifry-profile" </code></pre> <table> <tbody> <tr> <th>Ошибка</th> <th>Причина</th> <th>Решение</th> <th>Команда</th> </tr> <tr> <td>SEC_ERROR_UNKNOWN_ISSUER в Firefox</td> <td>Сертификат добавлен не в ту NSS-базу или не в тот профиль</td> <td>Проверь путь к базе и что Firefox запущен именно с флагом -P mincifry</td> <td><code>certutil -L -d sql:$PROFILE_DIR</code></td> </tr> <tr> <td>curl: SSL certificate problem: unable to get local issuer certificate</td> <td>В —cacert передан только корень без выпускающего сертификата</td> <td>Склей корневой и промежуточный сертификаты в один файл цепочки</td> <td><code>cat russian_trusted_sub_ca.crt russian_trusted_root_ca_pem.crt > chain.pem</code></td> </tr> <tr> <td>Сайт всё равно «не защищён» в Safari</td> <td>Сайт отдаёт ГОСТ-сертификат, а Safari его не поддерживает в принципе</td> <td>Используй Яндекс Браузер для этого конкретного сайта или проси у организации RSA-вариант</td> <td>—</td> </tr> <tr> <td>certutil: command not found</td> <td>Не установлен пакет с NSS-утилитами</td> <td>Поставь пакет с certutil из репозитория дистрибутива</td> <td><code>sudo apt install libnss3-tools</code></td> </tr> <tr> <td>После обновления Firefox профиль «потерял» сертификат</td> <td>Профиль был пересоздан или указан неверный путь после миграции cert8 в cert9</td> <td>Проверь актуальное имя файла базы, начиная с Firefox 58 это cert9.db, а не cert8.db</td> <td><code>ls $PROFILE_DIR/cert9.db</code></td> </tr> <tr> <td>Один и тот же сайт то открывается, то нет</td> <td>Балансировщик сайта отдаёт то RSA, то ГОСТ сертификат на разных запросах</td> <td>Добавь оба варианта сертификата в профиль, RSA и ГОСТ, чтобы браузер был готов к любому из них</td> <td><code>certutil -A -n "RTR CA GOST" -t "C,," -i russian_trusted_root_ca_gost_2025.cer -d sql:$PROFILE_DIR</code></td> </tr> </tbody> </table> <p>Всё не так плохо как кажется на этом месте статьи. Всё намного проще, если не пропускать шаг с проверкой отпечатка.</p> <p>Отдельно про ошибку unknown issuer в curl. Она возникает почти всегда по одной причине: в файл, переданный через —cacert, попал только корневой сертификат, а промежуточный Sub CA остался за бортом. curl, в отличие от браузера, не умеет самостоятельно докачивать недостающие звенья цепочки из интернета, поэтому цепочку нужно собрать руками и передать её целиком.</p> <h2>7. Альтернативы</h2> <p>Системная установка. Самый быстрый путь, годится для одноразовых личных машин, которые не жалко, и для случаев когда пользователь физически не может разобраться с профилями и NSS-базами. Для рабочей станции сисадмина или сервера, где крутится что-то ещё, я бы не рискнул расширять доверие всей системы ради одного сайта банка. Особенно на сервере: там системное доверие может внезапно затронуть автоматизацию, которая ходит по HTTPS куда-то ещё, и никто не вспомнит через год, зачем в trust store лежит российский корень.</p> <p>Яндекс Браузер. У него сертификаты Минцифры уже вшиты в комплект поставки, ничего добавлять не нужно, сайт просто открывается. Плюс — ноль телодвижений и нулевой шанс накосячить с NSS-базой. Минус — придётся держать этот браузер именно для сайтов с такими сертификатами, если основной браузер другой, и он всё равно отдельная точка присутствия в системе с собственными обновлениями и телеметрией, за которой тоже надо следить.</p> <p>Контейнерная изоляция. Для параноиков и корпоративных сценариев — запусти браузер в отдельном <a class="wpil_keyword_link" href="https://it-apteka.com/tag/docker/" target="_blank" rel="noopener" title="Docker" data-wpil-keyword-link="linked" data-wpil-monitor-id="3342">Docker</a>-контейнере с уже настроенным профилем и сертификатами внутри. Полная изоляция от хостовой системы вплоть до отдельного сетевого namespace, но overhead по ресурсам заметен, и для одного захода на сайт раз в месяц это явный перебор.</p> <p>Портативная сборка Firefox. Если не хочется трогать даже установленный Firefox, можно держать отдельную portable-версию в своей папке, полностью независимую от основной установки, с собственным профилем и своей NSS-базой из коробки. Подходит для флешки, которую носишь между машинами, когда нужен гарантированно чистый инструмент для одной задачи.</p> <table> <tbody> <tr> <th>Вариант</th> <th>Изоляция от системы</th> <th>Трудозатраты</th> <th>Когда выбрать</th> </tr> <tr> <td>Изолированный профиль Firefox</td> <td>Полная</td> <td>Средние, разовая настройка</td> <td>Постоянная работа сисадмина с такими сайтами</td> </tr> <tr> <td>Яндекс Браузер</td> <td>Полная</td> <td>Минимальные</td> <td>Разовый или редкий заход рядового пользователя</td> </tr> <tr> <td>Контейнер с браузером</td> <td>Максимальная</td> <td>Высокие</td> <td>Корпоративная политика или полная параноя</td> </tr> <tr> <td>Portable Firefox</td> <td>Полная</td> <td>Средние</td> <td>Работа с чужих или временных машин</td> </tr> <tr> <td>Системная установка</td> <td>Отсутствует</td> <td>Минимальные</td> <td>Личная машина, которую не жалко</td> </tr> </tbody> </table> <pre><code class="language-bash"> 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 </code></pre> <p>Я выбрал вариант с отдельным профилем Firefox как основной рецепт в статье, потому что он не требует ни лишнего софта, ни ресурсов контейнера, а изоляция получается ровно такая же надёжная. Контейнер имеет смысл добавлять поверх этого рецепта, а не вместо него, если политика безопасности организации требует именно физического отделения процесса браузера от хостовой системы, а не только отделения хранилища доверия.</p> <p>Отдельно скажу про вариант «просто игнорировать проблему и открывать сайт в системном браузере другого пользователя без прав администратора». Звучит как изоляция, на деле таковой не является: другой локальный пользователь на той же машине всё равно использует то же системное хранилище сертификатов Windows или Linux, если браузер этого пользователя на него опирается. Разделение пользователей ОС решает вопрос доступа к файлам, но не решает вопрос доверия TLS — для этого нужна именно изоляция на уровне NSS-базы конкретного профиля браузера, как в основном рецепте.</p> <p>Если сертификат нужен не тебе одному, а десятку рабочих станций в отделе, ручная установка через GUI на каждой машине превращается в отдельный ад. Тут пригодится тот же принцип изоляции, просто развёрнутый через автоматизацию вместо мышки.</p> <p>Для парка на Windows готовый профиль Firefox с уже добавленными сертификатами можно упаковать один раз и раскатать через групповую политику как обычный файловый ресурс, скопировав каталог профиля в AppData каждого пользователя при логоне, без единого изменения в системном хранилище сертификатов Windows. Логика та же, что я разбирал в статье про распространение Browser Shortcut Creator через GPO — берём готовый артефакт и копируем его login-скриптом, а не лезем в реестр или системные политики доверия.</p> <pre><code class="language-powershell"> $src = "\\fileserver\deploy\mincifry-profile" $dst = "$env:APPDATA\Mozilla\Firefox\Profiles\mincifry" if (-not (Test-Path $dst)) { Copy-Item -Path $src -Destination $dst -Recurse } </code></pre> <p>Для парка на Linux то же самое решается плейбуком Ansible: копируем готовый каталог профиля с уже собранной базой cert9.db на все машины группы, без единого модуля вроде copy в /usr/local/share/ca-certificates и без последующего update-ca-certificates, который как раз и делает установку системной.</p> <pre><code class="language-bash"> ansible workstations -m copy \ -a "src=/opt/mincifry-profile/ dest=~/mincifry-profile/ mode=0700" </code></pre> <p>Результат один и тот же что для одной машины, что для сотни: доверие живёт в скопированном каталоге профиля, а системный trust store каждой рабочей станции остаётся ровно таким, каким был до раскатки.</p> <h2>8. Безопасность</h2> <p>Главный риск системной установки корня — не в самом Минцифры, а в принципе неограниченного доверия. Любой сертификат, подписанный этим корнем, твоя система примет как настоящий, для любого домена, а не только для gosuslugi.ru. Это классическая архитектура man-in-the-middle, только легальная и добровольная. Изоляция на уровне профиля браузера убирает эту проблему полностью: доверие ограничено границами одного профиля и одного набора сайтов.</p> <p>Если пошёл по пути контейнерной изоляции, держи контейнер без привилегированного режима и без пробрасывания лишних сокетов кроме X11 или Wayland, которые нужны для отображения окна.</p> <p>Ограничивай физический доступ к каталогу с профилем так же, как к любому каталогу с приватными данными браузера — там куки и, возможно, сохранённые пароли для сайтов с этим сертификатом.</p> <p>Отдельно скажу про масштаб риска для организаций, а не для домашней машины. Если разворачиваешь такой профиль на рабочих станциях сотрудников через групповую политику, не превращай задачу в системную установку «для простоты» — это создаёт единую точку, через которую при компрометации самого удостоверяющего центра или при подмене сертификата злоумышленником пострадает весь парк машин сразу, а не только доступ к одному сайту. Изолированный профиль ограничивает этот блаcт-радиус периметром одного приложения.</p> <p>Никогда не скачивай сертификаты Минцифры с зеркал и форумов. Файл сертификата — это не проприетарный дистрибутив, который можно перезалить куда угодно, это криптографический якорь доверия, и подменённая копия на стороннем сайте — готовый вектор атаки. Официальный источник один — портал Госуслуг, раздел crt.</p> <p>Ну и запросы у вас, сказала бы система, если бы могла говорить, глядя на то, сколько инструкций в рунете предлагают решить проблему одного сайта через изменение доверия для всей машины. Разница между «открыть один сайт» и «поверить одному центру во всём» кажется мелочью до первого инцидента, а после первого инцидента с подменой сертификата уже не кажется.</p> <p>Держи в уме и обратную сторону изоляции: если корень добавлен только в один профиль, а не в систему, все остальные приложения, которые ходят на защищённые Минцифры сайты напрямую — толстые клиенты банков, десктопные приложения госорганов, некоторые VPN-клиенты с собственным TLS-стеком — продолжат ругаться на сертификат независимо от настроек браузера. Для них придётся искать собственный параметр доверия к CA-файлу внутри настроек самого приложения, по тому же принципу scoped-доверия, а не тащить проблему обратно в системное хранилище только потому что это единственный способ, который сработал для одного конкретного клиента.</p> <p>Отдельно про HSTS и pinning. Некоторые крупные сайты используют HTTP Strict Transport Security и заранее зашитые в браузер списки допустимых сертификатов. Для доменов Минцифры это обычно не проблема, потому что сами сайты не входят в предзагруженный HSTS-список с жёстким пиннингом, но если работаешь с корпоративным доменом, который такой пиннинг использует, изолированный профиль браузера — единственный безопасный способ протестировать новый корень, не рискуя сломать доверие на боевых машинах пользователей.</p> <h2>9. Профилактика</h2> <p>Резервное копирование. Бэкапь сам каталог профиля mincifry-profile целиком, включая cert9.db — тогда после переустановки системы не придётся заново качать и добавлять сертификаты. Раз в месяц архивируй профиль на внешний накопитель.</p> <pre><code class="language-bash"> tar -czf mincifry-profile-backup.tar.gz ~/mincifry-profile </code></pre> <p>Обновление. Минцифры периодически перевыпускает сертификаты, особенно ГОСТ-варианты с истекающим сроком действия. Проверяй актуальность файлов на gosuslugi.ru/crt раз в квартал и сверяй отпечаток заново перед заменой в NSS-базе. Перед обновлением сохрани текущую базу отдельно, чтобы было куда откатиться, если новый файл окажется битым.</p> <pre><code class="language-bash"> cp $PROFILE_DIR/cert9.db $PROFILE_DIR/cert9.db.bak </code></pre> <p>Восстановление из бэкапа проверяй заранее, а не в момент, когда профиль реально слетел. Разверни архив в тестовый каталог и убедись, что certutil видит те же записи, что и раньше.</p> <pre><code class="language-bash"> tar -xzf mincifry-profile-backup.tar.gz -C /tmp/restore-test certutil -L -d sql:/tmp/restore-test/mincifry-profile/xxxxxxxx.mincifry </code></pre> <p>Результат: та же пара строк с Root CA и Sub CA, что и в рабочем профиле. Если бэкап рабочий, восстановление после переустановки системы занимает пару минут — распаковал архив, запустил Firefox с флагом -profile на распакованный каталог, и сайты снова открываются без единого лишнего клика.</p> <p>Мониторинг. Если сертификат используется в автоматизации, например в curl-проверках Zabbix, добавь алерт на срок действия файла сертификата, а не только на код ответа HTTP.</p> <pre><code class="language-bash"> openssl x509 -in russian_trusted_root_ca_pem.crt -noout -enddate </code></pre> <p>Если сертификатов, использующих файл сертификата, наберётся несколько на разных серверах и в разных крон-джобах, проще собрать маленький <a class="wpil_keyword_link" href="https://it-apteka.com/category/scripts/" target="_blank" rel="noopener" title="Скрипты" data-wpil-keyword-link="linked" data-wpil-monitor-id="3339">скрипт</a>-проверку и повесить его отдельным пунктом в существующий мониторинг, а не держать дату истечения в голове.</p> <pre><code class="language-bash"> #!/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 "Сертификат Минцифры истекает через $DAYS_LEFT дней, пора обновлять" exit 1 fi </code></pre> <p>Капля никотина убивает лошадь. Одна забытая просроченная копия сертификата в проде роняет мониторинг всего отдела в понедельник утром, причём ровно тогда, когда все остальные ушли в отпуск и разбираться приходится тебе одному.</p> <p>Раз в полгода стоит сверять не только сам файл сертификата, но и то, попадает ли твой конкретный сайт всё ещё в перечень организаций, которым Минцифры выдало сертификат. Организация могла успеть перейти на коммерческого российского провайдера TLS-сертификатов и отказаться от НУЦ, и тогда цепочка на сайте однажды сменится сама, без предупреждения, а твой изолированный профиль с устаревшим корнем начнёт ругаться уже на новую, вполне обычную цепочку от другого CA. В этом случае решение обратное: убрать Russian Trusted Root CA из профиля больше не нужно, обычный набор доверенных корней справится сам.</p> <h2>10. FAQ</h2> <h3>Почему сайт с сертификатом Минцифры не открывается после установки?</h3> <p>Чаще всего сертификат добавлен не в тот профиль или не в ту NSS-базу, либо браузер запущен без флага -P с именем профиля. Проверь certutil -L -d с путём к базе и убедись, что видишь обе строки Root и Sub CA.</p> <h3>Как проверить что сертификат Минцифры работает правильно?</h3> <p>Открой целевой сайт в профиле, куда добавлен сертификат, и посмотри на замок в адресной строке. Для скриптов используй curl с флагом —cacert и проверяй код ответа 200 без ошибок SSL handshake.</p> <h3>Что делать если браузер пишет ошибку unknown issuer после установки?</h3> <p>Обычно не хватает промежуточного сертификата Sub CA в цепочке. Добавь его отдельно с пустыми флагами доверия рядом с корневым, либо склей оба сертификата в один файл chain.pem для curl.</p> <h3>Чем изолированный профиль отличается от системной установки?</h3> <p>Системная установка распространяет доверие корню на все приложения, которые используют системное хранилище сертификатов, то есть потенциально на любой сайт в интернете. Изолированный профиль ограничивает доверие конкретным браузерным профилем и не трогает остальную систему.</p> <h3>Безопасно ли вообще пользоваться сертификатами Минцифры?</h3> <p>Само наличие сертификата не опасно — это просто криптографическая подпись сайта конкретным удостоверяющим центром. Риск возникает от масштаба доверия, которое ты выдаёшь этому центру. Ограничивай масштаб через изоляцию, и риск падает до уровня одного конкретного сайта.</p> <h3>Нужно ли устанавливать оба сертификата, и RSA, и ГОСТ?</h3> <p>Не всегда. Если целевой сайт отдаёт только RSA-вариант, ГОСТ можно не трогать вообще. Ставь оба сразу только если заранее знаешь, что сайт использует ГОСТ-шифрование или переключается между вариантами на разных запросах, как иногда бывает у крупных балансировщиков.</p> <h3>Почему на телефоне сертификат ставится иначе, чем на компьютере?</h3> <p>На Android и iOS нет привычной концепции отдельного профиля браузера с собственной NSS-базой в том виде, в котором она есть у десктопного Firefox. На мобильных системах сертификат устанавливается через системные настройки безопасности и де-факто становится доступен всем приложениям на устройстве, поэтому для телефона логичнее выбрать Яндекс Браузер с уже вшитым доверием, а не городить установку в системные настройки iOS или Android.</p> <h3>Можно ли пользоваться сертификатом Минцифры сразу в нескольких браузерах?</h3> <p>Да, ничего не мешает завести отдельный изолированный профиль в каждом браузере, которым пользуешься. Единственное неудобство — сертификаты придётся добавить в каждую NSS-базу отдельно, общего центрального хранилища между Firefox, Chromium и другими браузерами на одной машине нет и не предполагается архитектурой.</p> <h2>11. Прогноз</h2> <p>Сделали то же самое, что и обычная инструкция из топа поиска, только с одной существенной поправкой: доверие корню Минцифры теперь живёт в границах отдельного профиля браузера, а не расползлось по всей системе. Сайты банков и Госуслуг открываются как ни в чём не бывало, а остальная система понятия не имеет, что такой удостоверяющий центр вообще существует. Скрипты мониторинга и curl-проверки работают с тем же файлом сертификата напрямую, тоже без единой строчки, добавленной в системный trust store.</p> <p>Дальше это просто рутина: раз в квартал сверяешь актуальность сертификата на официальном источнике, раз в месяц бэкапишь профиль вместе с базой cert9.db, и забываешь про красный замок до следующего перевыпуска. Единственное, что стоит держать в голове — при полной переустановке системы восстанавливать нужно не систему целиком, а один конкретный каталог профиля, и доступ вернётся за пару минут. Если после всех шагов сайт всё равно не открывается или curl ругается на что-то новое, пиши в комментарии — разберёмся вместе.</p> <p><script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Article", "headline": "Сертификаты Минцифры: как не ставить их в систему и не сойти с ума", "description": "Как получить доступ к сайтам с сертификатами Минцифры через изолированный профиль браузера, не устанавливая корень в системное хранилище доверия.", "author": { "@type": "Person", "name": "Андрей" }, "publisher": { "@type": "Organization", "name": "IT-Apteka.com" }, "mainEntityOfPage": { "@type": "WebPage" } } </script><br /> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Почему сайт с сертификатом Минцифры не открывается после установки?", "acceptedAnswer": { "@type": "Answer", "text": "Чаще всего сертификат добавлен не в тот профиль или не в ту NSS-базу, либо браузер запущен без указания нужного профиля. Нужно проверить содержимое базы командой certutil -L и путь к профилю." } }, { "@type": "Question", "name": "Как проверить что сертификат Минцифры работает правильно?", "acceptedAnswer": { "@type": "Answer", "text": "Открыть целевой сайт в профиле браузера с добавленным сертификатом и проверить значок защищённого соединения, либо выполнить проверку через curl с флагом --cacert и убедиться в коде ответа 200." } }, { "@type": "Question", "name": "Что делать если браузер пишет ошибку unknown issuer после установки?", "acceptedAnswer": { "@type": "Answer", "text": "Обычно не хватает промежуточного сертификата в цепочке. Нужно добавить Sub CA отдельно или объединить оба сертификата в один файл цепочки для использования с curl." } }, { "@type": "Question", "name": "Чем изолированный профиль отличается от системной установки?", "acceptedAnswer": { "@type": "Answer", "text": "Системная установка распространяет доверие на все приложения системы, изолированный профиль ограничивает доверие конкретным браузерным профилем и не затрагивает остальную систему." } } ] } </script></p>

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

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

firefox -CreateProfile "mincifry ~/mincifry-profile"

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

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

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

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

import requests

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

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

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

certutil -L -d sql:$PROFILE_DIR

trust list | grep -i "russian trusted"

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

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

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

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

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

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

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

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

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

openssl x509 -in russian_trusted_root_ca_pem.crt -noout -enddate

#!/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 "Сертификат Минцифры истекает через $DAYS_LEFT дней, пора обновлять"
  exit 1
fi