Как централизованно установить сертификаты Минцифры на нужные компьютеры: GPO в домене Active Directory, Firefox, Linux, macOS и антивирус

ИТ-руководитель дистрибьюторской компании (90 рабочих мест, домен AD, два филиала): «В понедельник у бухгалтерии не открылся Сбербанк Бизнес Онлайн, у логистов — личный кабинет РЖД. Пятнадцать заявок в HelpDesk за два часа. Раскатали корневой сертификат через GPO — в Chrome заработало, в Firefox нет, а на трёх машинах с Kaspersky сайты по-прежнему блокируются. Плюс четыре ноутбука на Astra Linux и два Mac у директоров».

Ту же картину мы видим по всем клиентам: больше ста обращений в нашу HelpDesk-систему за два месяца, плюс звонки ИТ-руководителей, которым нужно «чтобы у всех открывалось к понедельнику». В компании с доменом каждое такое обращение — сигнал, что сертификаты не раскатаны централизованно.

Эта статья — про то, как сделать всё за один проход и не возвращаться. Она для администраторов; если нужно поставить сертификаты руками на один компьютер, дайте сотруднику пользовательскую инструкцию для Windows.

Что именно раскатываем

С 3 августа 2026 года на сертификаты НУЦ Минцифры перешли крупнейшие банки, а с июля — часть госсервисов (после отзыва сертификатов GlobalSign, HARICA и TrustAsia). Корневой сертификат НУЦ не входит в хранилища Windows, macOS, Linux и браузеров, поэтому его нужно добавить в доверенные централизованно.

Цепочка выглядит так: сертификат сайта ← Russian Trusted Sub CA (выпускающий) ← Russian Trusted Root CA (корневой). Корень в Trusted Root задаёт доверие всему, что он надлежащим образом подписал. Выпускающие сертификаты в Intermediate помогают построить цепочку, но сервер сайта обычно должен передавать нужный Sub CA клиенту сам. По принятой схеме управления можно развернуть оба актуальных выпускающих (2022 и 2024 годов) централизованно, но помещать их в Trusted Root нельзя.

Скачивайте только с gosuslugi.ru/crt (файлы лежат на gu-st.ru). Состав архивов на 4 сентября 2026 года и отпечатки SHA-256 для проверки:

Две ловушки уже здесь. Первая: в архиве windows_russian_trusted_root_ca.zip лежат три файла, но корневой из них один — два других — это выпускающие, и класть их в Trusted Root неправильно (работать будет, но нарушает логику хранилищ и путает проверку). Вторая: ГОСТ-выпускающий подписан отдельным ГОСТ-корнем («Минцифры России НУЦ корневой»), который в Windows-архиве отсутствует; он нужен только машинам с КриптоПро CSP и берётся из архива для ГОСТ на той же странице.

Проверить отпечаток перед раскаткой:

certutil -hashfile Russian_Trusted_Root_CA.cer SHA256

Для DER-файла .cer хеш файла совпадает с отпечатком сертификата — сравнивайте с таблицей. Альтернатива: certutil -dump Russian_Trusted_Root_CA.cer | findstr /c:"Cert Hash(sha256)".

Или через OpenSSL: openssl x509 -inform DER -in Russian_Trusted_Root_CA.cer -noout -fingerprint -sha256.

Прежде чем раскатывать, примите решение на уровне компании: на какие машины ставить. Корневой сертификат в системном хранилище означает доверие ко всему, что им подписано, для всех программ на машине. Для бухгалтерии с банк-клиентом это очевидно нужно. Для ноутбука руководителя, работающего с зарубежными сервисами, разумнее выдать Яндекс Браузер (корень живёт внутри браузера) и ограничить GPO группой. Технически это решается фильтрацией безопасности политики по группе AD — ниже.

Windows: домен Active Directory

Способ 1. GPO (рекомендуемый)

1. Положите файлы .cer в сетевую папку, доступную контроллерам домена на чтение (например, \\dc01\certs\).
2. gpmc.msc → создайте новый объект групповой политики, например Cert-NUC-Mincifry, и привяжите к OU с компьютерами (или к домену).
3. Правой кнопкой → «Изменить» → Конфигурация компьютера → Политики → Конфигурация Windows → Параметры безопасности → Политики открытого ключа.
4. Доверенные корневые центры сертификации → правой кнопкой → «Импорт» → Russian_Trusted_Root_CA.cer → хранилище «Доверенные корневые центры сертификации» → «Готово».
5. Промежуточные центры сертификации → «Импорт» → Russian_Trusted_Sub_CA.cer, затем ещё раз → Russian_Trusted_Sub_CA_2024.cer.
6. Если нужно ограничить область: вкладка «Фильтры безопасности» → удалите «Прошедшие проверку» → добавьте группу компьютеров (например, GRP-Cert-NUC). Ловушка после обновления MS16-072: политика читается от имени компьютера, поэтому на вкладке «Делегирование» верните Прошедшие проверку (или Domain Computers) с правом только «Чтение» — без этого политика не применится вообще. Группе назначения нужны «Чтение» и «Применение групповой политики». После добавления машины в группу нужна её перезагрузка: членство в группах обновляется при входе компьютера в домен.
7. На тестовой машине: gpupdate /force, затем проверка (раздел «Проверка»).

Политика применяется при следующем обновлении (по умолчанию 90 ± 30 минут) или после gpupdate /force. Сертификаты попадают в хранилище «Локальный компьютер», то есть работают для всех пользователей машины и для служб.

Способ 2. Публикация в AD без отдельной GPO

Для корневого сертификата есть более короткий путь — опубликовать его в конфигурации леса:

certutil -dspublish -f Russian_Trusted_Root_CA.cer RootCA
certutil -dspublish -f Russian_Trusted_Sub_CA.cer SubCA
certutil -dspublish -f Russian_Trusted_Sub_CA_2024.cer SubCA

Корневой попадает в контейнер CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,..., выпускающие — в CN=AIA там же, и всё это автоматически распространяется на все компьютеры домена при обновлении политик — без создания GPO. Минус: гранулярно ограничить область нельзя, это «всем». Нужны права Enterprise Admins.

Способ 3. Скрипт (машины вне домена, филиалы без DC, RMM)

certutil -addstore -f Root "Russian_Trusted_Root_CA.cer"
certutil -addstore -f CA   "Russian_Trusted_Sub_CA.cer"
certutil -addstore -f CA   "Russian_Trusted_Sub_CA_2024.cer"

Или PowerShell:

Import-Certificate -FilePath ".\Russian_Trusted_Root_CA.cer"     -CertStoreLocation Cert:\LocalMachine\Root
Import-Certificate -FilePath ".\Russian_Trusted_Sub_CA.cer"      -CertStoreLocation Cert:\LocalMachine\CA
Import-Certificate -FilePath ".\Russian_Trusted_Sub_CA_2024.cer" -CertStoreLocation Cert:\LocalMachine\CA

Удобно раздавать через систему удалённого управления (RMM) или как стартовый скрипт. -f перезаписывает существующий сертификат с тем же отпечатком в том же хранилище.

Chrome и Edge

Ничего дополнительно не нужно: Chrome и Edge на Windows используют системное хранилище. Нюанс: с версии 105 (2022 год) Chrome использует собственный список корневых сертификатов (Chrome Root Store) для публичных УЦ, но локально установленные корни из хранилища Windows по-прежнему признаёт. Для машин вне домена, где системное хранилище трогать не хотите, в актуальных корпоративных версиях Chrome и Edge доступна политика CACertificates, позволяющая задать доверенные корни только для браузера; минимальную поддерживаемую версию сверяйте с документацией административного шаблона перед развёртыванием.

Firefox: системное доверие и отдельное хранилище

У Firefox есть собственное NSS-хранилище, однако Firefox 120+ обычно автоматически доверяет сторонним корням из системного хранилища Windows. Версия, корпоративная сборка или заданные политики могут изменить это поведение, поэтому в управляемом парке его лучше фиксировать явно. См. описание автоматического доверия Mozilla и политику Certificates.

Вариант 1 (одна политика, минимум действий). Установите ADMX-шаблоны Firefox в центральное хранилище (\\домен\SYSVOL\домен\Policies\PolicyDefinitions), затем в GPO: Конфигурация компьютера → Административные шаблоны → Mozilla → Firefox → Certificates → Import Enterprise Roots → Включено. Firefox начнёт доверять корневым сертификатам из хранилища Windows (в том числе установленным через GPO). Это эквивалент параметра security.enterprise_roots.enabled = true.

Вариант 2 (без ADMX). Файл distribution\policies.json в папке установки Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true,
      "Install": ["Russian_Trusted_Root_CA.cer", "Russian_Trusted_Sub_CA.cer", "Russian_Trusted_Sub_CA_2024.cer"]
    }
  }
}

В Install перечислены корень и два выпускающих сертификата. Firefox импортирует перечисленные CA в своё доверенное хранилище; для выпускающего Sub CA это означает доверие ему как самостоятельному trust anchor, а не только как звену до Russian Trusted Root CA. Такая конфигурация расширяет доверие. Используйте только официальные файлы с проверенными отпечатками; по возможности доверяйте корню через ImportEnterpriseRoots, а промежуточную цепочку требуйте от сервера.

Файлы для Install Firefox ищет не где угодно, а в своих каталогах сертификатов: на Windows — %USERPROFILE%\AppData\Local\Mozilla\Certificates и %USERPROFILE%\AppData\Roaming\Mozilla\Certificates, на Linux — /usr/lib/mozilla/certificates, /usr/lib64/mozilla/certificates, ~/.mozilla/certificates. Проще указать в Install полные пути к файлам (например, C:\\certs\\Russian_Trusted_Root_CA.cer) и раздать сами файлы той же GPO (Group Policy Preferences → Files).

Ловушка: установка политики не обновит уже открытые окна — нужен полный перезапуск Firefox. Firefox ESR и обычный Firefox читают policies.json из папки установки; портативные сборки политики не читают.

Linux: Astra, РЕД ОС, Ubuntu

Три отдельных хранилища: системное (для curl, wget, Python, 1С-клиента и т. п.), NSS-хранилище браузеров (Chrome/Chromium/Яндекс Браузер на Linux используют ~/.pki/nssdb) и собственное хранилище Firefox.

Формат файлов. Файлы из Windows-архива — в DER. Для Linux нужен PEM: на странице Госуслуг есть отдельный архив «для Linux» с PEM-версиями (russian_trusted_root_ca_pem.crt, russian_trusted_sub_ca_pem.crt, russian_trusted_sub_ca_2024_pem.crt). Если конвертируете сами: openssl x509 -inform DER -in Russian_Trusted_Root_CA.cer -out russian_trusted_root_ca.crt. Известная особенность файлов с Госуслуг: в PEM-версиях встречаются переводы строк CRLF и отсутствует пустая строка в конце — при склейке в один bundle сертификаты «слипаются». Прогоните через dos2unix и добавьте перевод строки.

Системное хранилище, Debian-семейство (Astra Linux, Ubuntu, Debian):

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

В системные trust anchors добавляйте только корень. Выпускающие Sub CA не должны становиться самостоятельными якорями: нужный промежуточный сертификат обязан передавать сервер. Расширение файла в каталоге Debian должно быть .crt, иначе update-ca-certificates его проигнорирует.

Системное хранилище, RPM-семейство (РЕД ОС, ALT в режиме совместимости, Fedora, RHEL):

sudo cp russian_trusted_root_ca_pem.crt /etc/pki/ca-trust/source/anchors/russian_trusted_root_ca.crt
sudo update-ca-trust extract
trust list | grep -i "Russian Trusted"

Браузеры на Linux (Chromium, Chrome): NSS-база пользователя (Яндекс Браузер корень НУЦ несёт сам):

sudo apt install libnss3-tools   # или dnf install nss-tools
[ -d "$HOME/.pki/nssdb" ] || certutil -d sql:$HOME/.pki/nssdb -N --empty-password
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "Russian Trusted Root CA" -i russian_trusted_root_ca.crt
certutil -d sql:$HOME/.pki/nssdb -A -t ",," -n "Russian Trusted Sub CA" -i russian_trusted_sub_ca.crt
certutil -d sql:$HOME/.pki/nssdb -A -t ",," -n "Russian Trusted Sub CA 2024" -i russian_trusted_sub_ca_2024.crt

Это делается от имени каждого пользователя (скрипт входа или Ansible с become_user). Firefox на Linux — та же политика policies.json (/usr/lib/firefox/distribution/policies.json или /etc/firefox/policies/policies.json), что и на Windows. Для Astra Linux Special Edition есть отдельные инструкции вендора и Kaspersky — используйте их для сертифицированных конфигураций.

Отдельно проверьте Java, банк-клиенты и часть конфигураций 1С: они могут использовать собственное trust store и не увидеть корень, добавленный в системное хранилище. Для Java это обычно cacerts и управление через keytool; для прикладного ПО следуйте документации поставщика.

macOS

Ручная установка через «Связку ключей» требует после импорта ещё и выставить «Всегда доверять» — пользователи об этом забывают. Для парка Mac правильный путь — профиль конфигурации .mobileconfig с корневым и выпускающими сертификатами, доставленный через MDM (Jamf, Apple Business Manager, отечественные MDM). Профиль, установленный через MDM, macOS считает доверенным автоматически; профиль, установленный пользователем вручную, на macOS тоже работает, но на iOS/iPadOS требует ручного включения доверия в «Настройки → Основные → Об этом устройстве → Доверие сертификатам».

На Госуслугах есть готовый russiantrusted.mobileconfig (для iOS/iPadOS) и архив для macOS. Собрать свой профиль с нужным набором сертификатов можно в Apple Configurator или любым MDM. Safari не поддерживает ГОСТ TLS — для ГОСТ-порталов на Mac нужен Яндекс Браузер.

Антивирусы и шлюзы с проверкой TLS

Если на рабочих станциях стоит Kaspersky Endpoint Security, а на периметре — UserGate, Ideco, Traffic Inspector или другой шлюз с SSL-инспекцией, у вас есть вторая точка проверки цепочки, и её нужно настроить отдельно.

Kaspersky Endpoint Security для Windows использует системное хранилище — после GPO должно заработать. Если сообщение «Переход на домен с недоверенным сертификатом» остаётся: проверьте, что установлены и корневой, и оба выпускающих; при необходимости добавьте сертификаты в собственное хранилище KES (Параметры → Общие параметры → Сетевые параметры → «Доверенные корневые сертификаты») через политику Kaspersky Security Center. Для машин без интернета переключите «Политику проверки сертификатов» на локальную проверку.

KES для Linux и Mac системное хранилище не используют — только своё; сертификаты добавляются через политику KSC.

Шлюзы с SSL-инспекцией (UserGate, Ideco, TING): корень НУЦ нужно добавить в доверенные CA самого шлюза, иначе он разорвёт соединение до того, как клиент увидит сертификат. Альтернатива — исключить российские банковские домены из инспекции, но тогда вы теряете контроль над этим трафиком.

Проверка

На любой машине после gpupdate /force:

certutil -store Root  | findstr /i "Russian Trusted"
certutil -store CA    | findstr /i "Russian Trusted"
certutil -verify -urlfetch "путь\к\сертификату_сайта.cer"

Или PowerShell:

Get-ChildItem Cert:\LocalMachine\Root, Cert:\LocalMachine\CA | Where-Object Subject -like "*Russian Trusted*" | Format-Table Subject, NotAfter, Thumbprint

Дальше — открыть в Chrome сайт на НУЦ (например, online.sberbank.ru), через значок сведений о сайте открыть сертификат и проверить «Кем выдан: Russian Trusted Sub CA». Затем то же в Firefox. Затем на машине с KES. Затем на Linux: curl -vI https://online.sberbank.ru 2>&1 | grep -E "issuer|SSL certificate verify".

После изменения хранилища полностью перезапустите браузеры. Обычный кэш доверие не создаёт. Удаление HSTS также не чинит корень или цепочку, а только снимает динамическую HTTPS-защиту домена; для preload-доменов оно не применяется.

Откат

Через GPO: удалите сертификат из политики (правой кнопкой в том же разделе → «Удалить») — при следующем обновлении политики он исчезнет с машин. Если ставили через -dspublish: удалите запись через pkiview.msc («Управление контейнерами AD») или ADSI Edit. Скриптом: certutil -delstore Root "Russian Trusted Root CA" и certutil -delstore CA "Russian Trusted Sub CA" (удалит оба Sub CA с одинаковым именем — выполните дважды или укажите отпечаток). Firefox: отключите политику Import Enterprise Roots и удалите записи Install.

Что делать через год

Выпускающий сертификат 2022 года истекает 6 марта 2027 года; новые сертификаты НУЦ уже выпускаются под Sub CA 2024 (по данным CT-логов на 4 сентября 2026 года), но новые выпускающие Минцифры публикует без громких анонсов — на странице gosuslugi.ru/crt тогда появляется плашка «добавьте новые корневые и выпускающие сертификаты». Заведите в реестре сертификатов компании строку «корни НУЦ на рабочих станциях» с датой проверки раз в квартал и проверяйте страницу gosuslugi.ru/crt. Как собрать такой реестр за день и где взять шаблон — в статье «Аудит сертификатов компании за один день».

Чек-лист

1. Файлы скачаны с gosuslugi.ru/crt, отпечатки сверены с таблицей выше.
2. Решено, на какие машины ставить (все / группа); создана группа AD при необходимости.
3. GPO: Root → Trusted Root; оба Sub CA → Intermediate.
4. Firefox: Import Enterprise Roots (ADMX или policies.json).
5. Linux: системное хранилище + NSS пользователей + policies.json.
6. macOS: профиль через MDM.
7. KES / шлюз с SSL-инспекцией: доверенные CA добавлены.
8. Проверка на 4 машинах: Chrome, Firefox, KES, Linux.
9. Памятка пользователям: «если сайт не открывается — не жмите „перейти всё равно“, обращайтесь в поддержку».
10. Строка в реестре сертификатов с датой пересмотра.

Если рук не хватает

Раскатаем сертификаты на все рабочие станции, серверы и филиалы за один рабочий день, настроим Firefox, Linux, Mac и антивирус, проверим и оставим документацию. Для клиентов Визард-АйТи на ИТ-аутсорсинге это сделано в рамках SLA.

Читайте также:

• Аудит сертификатов компании за один день: чек-лист и шаблон реестра
• Установка сертификатов Минцифры на Windows — инструкция для сотрудников
• Сертификатный кризис 2026: что произошло с SSL-сертификатами в России и что делать бизнесу