
Введение
В корпоративной среде с ростом количества сотрудников, которым требуется доступ к системам с использованием ЭЦП, возникла необходимость автоматизировать процесс установки сертификатов.
Попытки применить стандартные средства — Import-PfxCertificate
, certutil
и другие — результата не дали: сертификаты не виделись рядом приложений, включая СБИС. Готовых рабочих решений тоже не нашлось. Пришлось разрабатывать собственный метод.
В этой статье описан механизм, применяемый для распространения сертификатов ИФНС. Методы экспорта ключей и сертификатов можно найти в сети, поэтому они здесь не рассматриваются. Вопросы безопасности при передаче приватных ключей также остаются за рамками — предполагается, что всё выполняется во внутреннем доверенном контуре.
За основу была взята статья «Перенос контейнеров закрытых ключей и сертификатов CryptoPro», где описан ручной процесс. Я доработал его и автоматизировал для централизованного распространения через GPO.
Проблема
При переносе сертификатов и ключей между машинами или профилями возникает одна и та же трудность: они «привязаны» к SID пользователя.
Если импортировать .reg
напрямую, записи окажутся связаны с SID другого пользователя и работать не будут.
Поэтому при автоматическом распространении необходимо корректно подставлять текущий SID.
Решение
Я подготовил набор PowerShell-скриптов, которые выполняются от имени пользователя при логоне (через GPO Logon Script).
Сценарий работы такой:
Шаблон реестра
В исходном.reg
файле хранится конфигурация с «старым» SID.-
Подмена SID
Скрипт получает SID текущего пользователя[System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value
и заменяет им статический идентификатор в файле.
Импорт реестра
Обновлённый.reg
файл импортируется в HKCU.-
Копирование сертификатов
Из сетевой папки (\\share\Cert\My
) копируются нужные файлы в профиль пользователя:%APPDATA%\Microsoft\SystemCertificates\My
Готово
При следующем запуске приложений (Outlook, браузеры, CryptoPro) пользователь сразу получает доступ к сертификатам.
Пример кода
Запуск разных скриптов по группам
Этот пример показывает, как можно привязывать разные сценарии к членству пользователя в группах AD. Каждое группа соответствует отдельному сертификату.
# Задаем группы и соответствующие пути к скриптам для каждой группы
$groupScriptMap = @{
"First Group" = "\\path\first_script.ps1"
"Second Group" = "\\path\second_script.ps1"
}
# Получаем информацию о текущем пользователе
$user = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$userGroups = $user.Groups | ForEach-Object {
$_.Translate([System.Security.Principal.NTAccount]).Value.Split("\")[1]
}
# Перебираем каждую группу из маппинга и проверяем, состоит ли в ней пользователь
foreach ($group in $groupScriptMap.Keys) {
if ($userGroups -contains $group) {
Write-Output "Пользователь $($user.Name) принадлежит группе $group."
# Получаем путь к скрипту для этой группы
$scriptPath = $groupScriptMap[$group]
Write-Output "Запускается скрипт для группы: $scriptPath"
# Выполняем соответствующий скрипт
try {
#Start-Process -FilePath "powershell.exe" -ArgumentList "-ExecutionPolicy Bypass -File $scriptPath" -NoNewWindow -Wait
Start-Process -FilePath "powershell.exe" -ArgumentList "-ExecutionPolicy", "Bypass", "-File", "`"$scriptPath`"" -NoNewWindow -Wait
} catch {
Write-Output "Ошибка при выполнении скрипта для группы $[group]: $_"
}
} else {
Write-Output "Пользователь $($user.Name) не состоит в группе $group."
}
}
Данные скрипт производит основные действия по замене SID, импорте reg файла и копировании хранилища личных сертификатов пользователя
# Указываем путь к файлу реестра (исходный шаблон .reg файл)
$regFileSource = "\\path\first_file.reg"
# Определяем временную папку текущего пользователя
$tempFolder = [System.IO.Path]::GetTempPath()
# Определяем SID текущего пользователя
$userSID = (Get-WmiObject -Class Win32_UserAccount -Filter "Name='$env:USERNAME'").SID
# Определяем целевой файл во временной папке
$regFileTemp = Join-Path $tempFolder "modified_registry.reg"
# Читаем содержимое исходного файла реестра
$regContent = Get-Content -Path $regFileSource -Encoding Unicode
# Статический SID, который будем заменять
$oldSID = "S-1-5-21-3734670798-76392145-1373982661-1117"
# Заменяем статический SID на SID текущего пользователя
$updatedContent = $regContent -replace $oldSID, $userSID
# Записываем обновленный файл реестра во временную папку
$updatedContent | Out-File -FilePath $regFileTemp -Encoding Unicode
# Импортируем обновленный файл реестра
reg import $regFileTemp
# Указываем сетевую папку для копирования
$networkFolder = "\\path\My"
# Папка пользователя, куда нужно скопировать сетевую папку
$userFolder = "C:\Users\$env:USERNAME\AppData\Roaming\Microsoft\SystemCertificates"
# Копируем содержимое с заменой конфликтов
Copy-Item -Path $networkFolder -Destination $userFolder -Recurse -Force
Write-Host "Файл реестра был успешно импортирован, и папка скопирована."
Варианты использования
Распространение сертификатов ЭЦП среди сотрудников
Миграция рабочих мест и перенос профилей
Репозиторий
Исходный код доступен здесь. Там же постарался создать подробный и понятный README.
? GitHub — provision_of_certificates_GPO
Заключение
Предложенный метод позволяет автоматизировать раздачу сертификатов через GPO без ручных действий. Он прост в реализации.
При этом стоит помнить о недостатках:
нет централизованного контроля за сроком действия сертификатов;
приватные ключи передаются в файлах, что требует доверенной среды;
метод рассчитан именно на Windows-среду с CryptoPro.
Комментарии (12)
ru4pae
27.08.2025 15:12В целом интересная задача. Не сталкиваюсь по работе с ЭП от ИФНС.
Налоговая выпускают ключи не только для руководителя учреждения (организации)? Или вы копируете ключ руководителя на десяток рабочих мест?
На вскидку, думаю что правильнее выпускать ключи на сотрудников через казначейство и прикладывать к ним МЧД.
Токен с ЭП от налоговой положить в сейф и доставать только для выпуска МЧД.
Выпустить через казначейство экспортируемую ЭП на руководителя юр. лица и горя не знать?
По поводу СБИС, знаю, что они периодически пытаются заставить пользователей купить у них КриптоПро. Система пишет, что подписи нет и предлагает купить КриптоПро. Замечал такое на пятой версии КриптоПро.
С Контуром, ГосУслугами и т.п. сервисами в соседних вкладках работает эта же подпись отлично.
Dyatlovm Автор
27.08.2025 15:12Мы пытались внедрить ключи на сотрудников через доверенности. Столкнулись с двумя проблемами. Первая и решаемая - количество сотрудников которым нужна подпись равнялось около 50, и на каждого примерно по 5-10 ЮЛ. Плюс большая текучка - довольно сложно поддерживать все это в актуальном состоянии и своевременно выпускать. А вторая причина практически нерешаемвая - часть сервисов работает только с подписью ГД. Обойти это нереально. Поэтому уповаем на то, что в ближайшем будущем механизм экспорта неэкспортируемых ключей не прикроется.
arshanskiyav
27.08.2025 15:12А не подозрительно, что сотрудники разных ЮЛ имеют перекрестные доверенности других "не аффилированных" ЮЛ?
arshanskiyav
27.08.2025 15:12Разве ЭП руководителя, выпущенная через казначейство будет иметь ту же силу, что и ЭП выпущенная через ИФН?. ЕМНИП у руководителя в момент времени может существовать только одна подпись.
И да, я уже неоднократно сталкиваюсь с тем, что без подписи ГД нельзя выполнить какие то процедуры. А в некоторых случаях и без ГУ ГД также не обойтись.
А у меня со СБИСом была обратная ситуация, точнее с менеджером, запросил ЭЦП в прошлом году с лицензией (чтоб не покупать лицензию за 70К на терминал), а менеджер и говорит, что ФНС выпускает бесплатно со встроенной лицензией.
Gowa_one
27.08.2025 15:12неплохо, тут есть куда еще развивать эту выдачу? Может с безопасностью поработать?
Dyatlovm Автор
27.08.2025 15:12в целом решение полноценное. можно попробовать разграничить доступ к файлам reg по членству в группе. чтобы пользователи, не состоящие в группе не могли получить доступ и установить руками сертификат. это решается на уровне ntfs.
ru4pae
Или я что то не понял, или у вас решение зачем просто, если можно сложно?
Зачем делать не экспортируемые ЭП и потом возиться с их переносом через реестр?
Вводные: Работаем с КриптоПро. Считаем что КриптоПро уже установлен.
Контейнер с ЭП доступен для КриптоПро. Сертификат и закрытый ключ находиться в контейнере.
Токен, папка с контейнером в директория пятого КритоПро, папка с контейнером в корне диска.
Честно скажу, очень давно, лет пять назад, пробовал вариант переноса через реестр, но на третьем КриптоПро не было проблем с сидами. Экспорт ветки реестра, импорт и ручками через КриптоПро установка сертификата. Думаю КриптоПро всё едино, как контейнер с ЭП попал в учетную запись пользователя. Главное что он доступен.
Да, всё хочу попробовать в пятом КриптоПро создать не экспортируемую ЭП в контейнере который разместить в директории КриптоПро. А потом скопировать папку в другое место. Предполагаю, будет работать.
Итак у нас остаётся одна задача. Установить сертификат ЭП в личное хранилище сертификатов пользователя.
Копирование сертификата ЭП к текущей записи пользователя виндовс делается одной строкой через сertmgr из комплекта КриптоПро. К сожалению нет под рукой точной строки, делал это пол года назад и подзабыл какие там точно там ключи. Кажется сertmgr -install
Контейнер с ЭП может находиться на токене, в реестре, в корне диска.
сertmgr находит ВСЕ доступные пользователю ЭП и устанавливает ВСЕ сертификаты в хранилище пользователя. И эти сертификаты становятся доступны для ВСЕХ программ.
На этом собственно всё. Дальше уже подгоняем под свои условия.
Запускаем поиск и установку сертификата руками пользователя.
"У вас новая ЭП? Подключите токен и два раза кликните мышкой (раз-раз) по ярлыку на рабочем столе с названием "Регистрация ЭП", да, это делать надо один раз, да на каждом новом рабочем месте, и т.д. и т.п.".
У пользователя возникает черное окошко на котором в конце появляться зелёная надпись "Электронная Подпись установлена". Пользователь доволен, он проконтролировал процесс установки ЭП на рабочее место. Он видел зеленую надпись. Значит всё в порядке.
Не хочется доверять пользователю такой важный процесс? Тогда GPO. И настраивать под себя.
В конце еще раз спрошу. Зачем делать не экспортируемые ЭП и преодолевать возникающие из за этого проблемы если вы по факту используете экспортируемые ЭП?
Dyatlovm Автор
Смотрите. Подписи, о которых идет в статье речь, это подпись ИФНС. Они считаются неэкспортируемыми. При помощи утилиты можно обойти этот запрет и получить экспорт данного ключа. Далее, для того чтобы его использовать, необходимо через внешний носитель, либо через subst установить и связать сертификаты в КриптоПро. Если этого не сделать, то часть систем не увидят сертификат. Скажу что помню - в контур при такой установки через certmgr можно зайти, а сбис сертификат не увидит.
Возможно есть действительно более простой и лаконичный способ, но те методы которые я пробовал так и не принесли успеха. Тем более что упор был именно на распространение через группы и GPO.
kfs
А чем не устраивает использование неэкспортируемого ключа на смарт-карте (на отчуждаемом носителе), как это изначально задумано? В таком случае работает служба Certificate propagation service в связке с криптопро и при подключении смарт-карты сертификат автоматически добавляется в хранилище.
Dyatlovm Автор
Необходимо использовать ЭЦП одновременно в территориально разнесенных точках. Физически невозможно это реализовать.
kfs
Имеется ввиду передача ЭП одного сотрудника (или даже ген. директора) другим лицам в разных филиалах? Ну, такое себе решение.
Мы в подобных случаях делаем что-то вроде терминального сервера с доступом к ресурсам, где требуется подпись и на этом сервере/vdi устанавливаем ключ подписи.
Еще более лучшим решением является использование HSM. Но это дорого для небольших организаций.
Dyatlovm Автор
По поводу терминального сервера. Необходимо предоставить одномоментный доступ к подписи большому количеству сотрудников. Физически подпись им не передается. Она хранится в реестре. Конечно при желании ее можно вытащить и при некоторых манипуляциях использовать на других ПК. Это тоже самое как если бы передать им физический токен. В статье акцент больше на автоматизацию предоставления доступа к ЭЦП через групповые политики. По поводу безопасности использования данного метода я предупредил в статье.