Обновление корневых сертификатов windows server 2016

По умолчанию, все операционные системы семейства Windows автоматически получают и обновляют корневые сертификаты с сайта Microsoft. Компания MSFT в рамках программы корневых сертификатов Microsoft Trusted Root Certificate Program, ведет и публикует в своем онлайн хранилище сертификаты для клиентов и устройств Windows. Если проверяемый сертификат в своей цепочке сертификации относится к корневому CA, который участвует в этой программе, Windows автоматически скачает с узла Microsoft Update и добавит такой корневой сертификат в доверенные на вашем компьютере.

Windows запрашивает обновление списка корневых сертификатов (certificate trust lists — CTL) один раз в неделю. Если в Windows отсутствует прямой доступ к каталогу Windows Update, то система не сможет обновить корневые сертификаты, соответственно у пользователя могут быть проблемы с открытием сайтов (SSL сертификаты которых подписаны недоверенными CA, см. статью об ошибке в Chrome Этот сайт не может обеспечить безопасное соединение), либо с установкой запуском подписанных приложений или скриптов.

В этой статье попробуем разобраться, как в Windows вручную обновить список корневых сертификатов в TrustedRootCA в изолированных сетях, или компьютерах/серверах без прямого подключения к Интернету.

Примечание. Если ваши компьютеры выходят в Интернет через прокси-сервер, для автоматического обновления корневых сертификатов Microsoft рекомендует открыть прямой доступ (bypass) к веб-узлам Microsoft. Но это не всегда возможно/применимо.

Управление корневыми сертификатами в Windows 10 и 11

Как посмотреть список корневых сертификатов на устройстве Windows?

1. Чтобы открыть хранилище корневых сертификатов компьютера в Windows /Windows Server, запустите консоль
   mmc.exe
   ;
2. Нажмите Файл (File) -> Добавить или удалить оснастку (Add/Remove Snap-in), в списке оснасток выберите Сертификаты (Certificates) -> Добавить (Add);
3. В диалоговом окне выберите что вы хотите управлять сертификатами учетной записи компьютера (Computer account);
4. Далее -> Ok -> Ok;
5. Разверните Certificates (Сертификаты) -> Trusted Root Certification Authorities Store (Доверенные корневые сертификаты). В этом списке содержится список доверенных корневых сертификатов вашего компьютера.

Вы можете вывести список доверенных корневых сертификатов на вашем компьютере со сроками их действия с помощью PowerShell:

Get-Childitem cert:LocalMachineroot |format-list

Можно вывести список истекших сертификатов, или которые истекут в ближайшие 30 дней:

Get-ChildItem cert:LocalMachineroot|  Where {$_.NotAfter -lt  (Get-Date).AddDays(30)} |select NotAfter, Subject

В целях безопасности рекомендует периодически проверять хранилище доверенных сертификатов на наличие поддельных сертификатов с помощью утилиты Sigcheck. Утилита позволяет сравнить список сертификатов, установленных на компьютере со списком корневых сертификатов на сайте Microsoft (можно скачать офлайн файл с актуальными сертификатами authrootstl.cab).

Вы можете вручную перенести файл корневого сертификата с одного компьютера на другой с помощью функцию Экспорта/Импорта.

1. Вы можете экспортировать любой сертификат .CER в файл, щелкнув по нему и выбрав “Все задачи” -> “Экспорт”;
2. Затем с помощью команды Импорт можно импортировать этот сертификат на другом компьютере.

Включить/отключить автоматическое обновление корневых сертификатов в Windows

Как мы уже упомянули, Windows по умолчанию сама обновляет корневые сертификаты. Вы можете включить или отключить обновление сертификатов в Windows через GPO или реестр.

Откройте локальный редактор групповой политики (gpedit.msc) и перейдите в раздел Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication.

Параметр Turn off Automatic Root Certificates Update в этом разделе позволяет отключить автоматическое обновление корневых сертификатов через сайт Windows Update. По умолчанию это политика не настроена и Windows всегда пытается автоматически обновлять корневые сертификаты.

Если эта политика не настроена, а сертификаты не обновляются автоматически, проверьте не включен ли вручную параметр реестра, отвечающий за эту настройку. Проверьте значение параметра реестра с помощью PowerShell:

Get-ItemProperty -Path 'HKLM:SoftwarePoliciesMicrosoftSystemCertificatesAuthRoot' -Name DisableRootAutoUpdate

Если команда вернет, что значение ключа
DisableRootAutoUpdate=1
, значит на вашем компьютере отключено обновление корневых сертификатов. Чтобы включить его, измените значение параметра на 0.

Ручное обновление корневых сертификатов в Windows 10 и 11

Утилита управления и работы с сертификатами Certutil (появилась в Windows 10, для Windows 7 доступна в виде отдельного обновления), позволяет скачать с узлов Windows Update и сохранить в SST файл актуальный список корневых сертификатов.

Для генерации SST файла, на компьютере Windows 10/11 с доступом в Интернет, выполните с правами администратора команду:

certutil.exe -generateSSTFromWU c:PSroots.sst

Updated SST file.
CertUtil: -generateSSTFromWU command completed successfully.

В результате в целевом каталоге появится файл SST, содержащий актуальный список сертификатов. Дважды щелкните по нему для открытия. Данный файл представляет собой контейнер, содержащий доверенные корневые сертификаты.

В указанном каталоге появится файл SST, содержащий актуальный список сертификатов. Данный файл представляет собой контейнер, содержащий доверенные корневые сертификаты. Дважды щелкните по нему.

В открывшейся
mmc
консоли вы можете экспортировать любой из полученных сертификатов. В моем случае, список сертификатов содержал 436 элементов. Естественно, экспортировать сертификаты и устанавливать по одному не рационально.

Для установки всех сертификатов из SST файла и добавления их в список корневых сертификатов компьютера можно воспользоваться командами PowerShell:
$sstStore = ( Get-ChildItem -Path C:psrootsupdroots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:LocalMachineRoot

Запустите оснастку certmgr.msc и убедитесь, что все сертификаты были добавлены в хранилище Trusted Root Certification Authority. В нашем примере на Windows 11 количество корневых сертификатов увеличилось с 34 до 438.

Чистая копия Windows после установки содержит в корневом хранилище лишь небольшое количество сертификатов. Если компьютер подключен к интернету, остальные корневые сертификаты будут устанавливаться автоматически (по требованию), если ваше устройство попытается получить доступ к HTTPS сайту/SSL сертификату, в чей цепочке доверия есть отпечаток из CTL Microsoft. Поэтому как правило, нет необходимости добавлять в свое локальное хранилище сразу все сертификаты, доверенные Microsoft.

Список корневых сертификатов в формате STL

Есть еще один способ получения списка сертификатов с сайта Microsoft. Для этого нужно скачать файл http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab (обновляется дважды в месяц).С помощью любого архиватора (или проводника Windows) распакуйте содержимое архива authrootstl.cab. Он содержит один файл authroot.stl.

Файл authroot.stl представляет собой контейнер со списком отпечатков (thumbprint) доверенных сертификатов Microsoft в формате Certification Trust List.

Данный файл можно установить в системе с помощью утилиты certutil:

certutil -enterprise -f -v -AddStore "Root" "C:PSauthroot.stl"

Root "Trusted Root Certification Authorities"
CTL 0 added to store.
CertUtil: -addstore command completed successfully.

Также вы можете импортировать сертификаты из консоли управления сертификатами (Trust Root CertificationAuthorities –>Certificates -> All Tasks > Import). Укажите путь к вашему STL файлу сертификатами.

После выполнения команды, в консоли управления сертификатами (
certmgr.msc
) в контейнере Trusted Root Certification Authorities (Доверенные корневые сертификаты) появится новый раздел с именем Certificate Trust List (Список доверия сертификатов).

Аналогичным образом можно скачать и установить список с отозванными сертификатами, которые были исключены из программы Root Certificate Program. для этого, скачайте файл disallowedcertstl.cab (http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab), распакуйте его и добавьте в раздел Untrusted Certificates командой:

certutil -enterprise -f -v -AddStore disallowed "C:PSdisallowedcert.stl "

Обновление корневых сертификатов в Windows с помощью GPO в изолированных средах

Если у вас возникла задача регулярного обновления корневых сертификатов в изолированном от Интернета домене Active Directory, есть несколько более сложная схема обновления локальных хранилищ сертификатов на компьютерах домена с помощью групповых политик. В изолированных сетях Windows вы можете настроить обновление корневых сертификатов на компьютерах пользователей несколькими способами.

Первый способ предполагает, что вы регулярно вручную скачиваете и копируете в вашу изолированную сеть файл с корневыми сертификатами, полученный так:

certutil.exe –generateSSTFromWU roots.sst

Затем сертификаты из данного файла можно установить через SCCM или PowerShell логон скрипт в GPO:
$sstStore = ( Get-ChildItem -Path \dc01SYSVOLwinitpro.rurootcertroots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:LocalMachineRoot

Второй способ предполагает получение актуальных корневых сертификатов с помощью команды:

Certutil -syncWithWU -f \dc01SYSVOLwinitpro.rurootcert

В указанном сетевом каталоге появится ряд файлов корневых сертификатов (CRT) и в том числе файлы (authrootstl.cab, disallowedcertstl.cab, disallowedcert.sst, thumbprint.crt).

Затем с помощью GPP нужно изменить значение параметра реестра RootDirURL в ветке HKLMSoftwareMicrosoftSystemCertificatesAuthRootAutoUpdate. Этот параметр должен указывать на сетевую папку, из которой клиентам нужно получать новые корневые сертификаты. Перейдите в секцию редактора GPO Computer Configuration -> Preferences -> Windows Settings -> Registry. И создайте новый параметр реестра со значениями:

Action: Update
Hive: HKLM
Key path: SoftwareMicrosoftSystemCertificatesAuthRootAutoUpdate
Value name: RootDirURL
Type: REG_SZ
Value data: file://\dc01SYSVOLwinitpro.rurootcert

Осталось назначить эту политику на компьютеры и после обновления настроек GPO на клиенте проверить появление новых корневых сертификатов в хранилище.

Политика Turn off Automatic Root Certificates Update в разделе Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings должна быть выключена или не настроена.

Обновление корневых сертификатов в Windows 7

Несмотря на то, что Windows 7 уже снята с поддержки, есть много пользователей и компаний, в которых она еще используется.

После установки чистой Windows 7 из образа вы может столкнуться, что многие современные программы и инструменты на ней не работают из-за того, что они подписаны с помощью новых сертификатов. В частности, были жалобы, что в Windows 7 64 без обновления сертификатов не удается установить .Net Framework 4.8. или

vs_Community.exe с ошибкой:

installer manifest failed signature validation

Чтобы обновить корневые сертификаты в Windows 7, нужно скачать и установить MSU обновление KB2813430 (https://support.microsoft.com/en-us/topic/an-update-is-available-that-enables-administrators-to-update-trusted-and-disallowed-ctls-in-disconnected-environments-in-windows-0c51c702-fdcc-f6be-7089-4585fad729d6).

После этого вы можете использовать утилиту certutil для генерации SST файла с сертификатами (на этом или на другом компьютере):

certutil.exe -generateSSTFromWU c:psroots.sst

Теперь можно импортировать сертификаты в доверенные:

MMC -> add snap-in -> certificates -> computer account > local computer. Перейдите в раздел Trusted root certification authority, выберите All Tasks -> Import, найдите ваш SST файл (в типе файлов выберите Microsoft Serialized Certificate Store — *.sst) -> Open -> Place all certificates in the following store -> Trusted Root Certification Authorities

Утилита rootsupd.exe для обновления сертификатов в Windows XP

В Windows XP для обновления корневых сертификатов использовалась утилита rootsupd.exe. В этой утилита содержится список корневых и отозванных сертификатов, зашитых в которой регулярно обновлялся. Сама утилита распространялась в виде отдельного обновления KB931125 (Update for Root Certificates).

1. Скачайте утилиту rootsupd.exe, перейдя по ссылке (по состоянию на 15.07.2019 ссылка не работает, возможно в Microsoft решили убрать ее из общего доступа. На данный момент вы можете скачать утилиту с сайта kaspersky.com — http://media.kaspersky.com/utilities/CorporateUtilities/rootsupd.zip);
2. Для установки корневых сертификатов Windows, достаточно запустить файл rootsupd.exe. Но мы попробуем более внимательно рассмотреть его содержимое, распаковав его с помощью команды:
   rootsupd.exe /c /t:C:PSrootsupd
   
3. Сертификаты содержатся в SST файлах: authroots.sst, delroot.sst и т.п. Для удаления/установки сертификатов можно воспользоваться командами:
   updroots.exe authroots.sst
updroots.exe -d delroots.sst

Но, как вы видите, дата создания этих файлов 4 апреля 2013 (почти за год до окончания официальной поддержки Windows XP). Таким образом, с этого времени утилита не обновлялась и не может быть использована для установки актуальных сертификатов. Однако нам чуть позже понадобится файл updroots.exe.

Была информация, что утилиту updroots.exe нежелательно использовать в современных билдах Windows 10 1803+, т.к. она может сломать корневой сертификат Microsoft Root Certificate Authority.

В этой статье мы рассмотрели несколько способов обновления корневых сертификатов на компьютерах Windows, изолированных от Интернета.

В операционные системы семейства Windows встроена система автоматического обновления корневых сертификатов с сайта Microsoft. Компания MSFT в рамках программы корневых сертификатов Microsoft Trusted Root Certificate Program, ведет и публикует в своем онлайн хранилище список сертификатов для клиентов и устройств Windows. Если проверяемый сертификат в своей цепочке сертификации относится к корневому CA, который участвует в этой программе, система автоматически скачает с узла Windows Update и добавит такой корневой сертификат в доверенные.

Много текста

ОС Windows запрашивает обновление корневых сертификатов (certificate trust lists — CTL) один раз в неделю. Если в Windows отсутствует прямой доступ к каталогу Windows Update, то система не сможет обновить корневые сертификаты, соответственно у пользователя могут быть проблемы с открытием сайтов (SSL сертификаты которых подписаны CA, к которому нет доверия).

Примечание. В  том случае, если пользователи получают доступ в интернет через прокси сервер, для того, что работало автоматическое обновление корневых сертификатов на компьютера пользователей, Microsoft рекомендует открыть прямой доступ (bypass)  к узлам Microsoft. Но это не всегда возможно.

Что такое корневой сертификат?
Корневой сертификат (СА) — часть ключа, которым центры сертификации подписывают выпущенные SSL-сертификаты. Выдавая корневой сертификат, каждый такой центр гарантирует, что пользователи или организации, запросившие SSL, верифицированы и действия с доменом или приложением легальны.

Что будет если не обновлять корневые сертификаты?
Если не обновлять корневые сертификаты, то:

•  вы не сможете заходить на сайты, которые используют доверенные центры сертификации, которых у вас нет в системе, или срок которых у вас истёк.
•  при включенной проверке издателя, вы не сможете устанавливать новые программы, которые используют доверенные центры сертификации, которых у вас нет в системе, или срок которых у вас истёк.
•  вы не сможете продолжать полноценно использовать приложения, которые используют доверенные центры сертификации, которых у вас нет в системе, или срок которых у вас истёк.

Обязательно ли обновлять сертификаты?
Нет. В случае если у вас Windows 7, Windows 8, Windows 8.1, Windows 10, и у вас включено автоматическое обновление Windows (Службы криптографии и BITS), то сертификаты обновляются автоматически.

Обновление сертификатов (для всех версий Windows)

На примере сертификатов КриптоПро CSP

Шаг 1. Удаление старых сертификатов из контейнера

В проводнике наберите в адресной строке адрес: «mmc.exe» (без кавычек) и нажмите Enter.

Откроется окно консоли управления Microsoft.

В основном меню консоли, выберите «Файл» — «Добавить или удалить оснастку». Будет открыто окно «Добавление и удаление оснасток».

В левом списке выберите пункт «Сертификаты» и нажмите на кнопку «Добавить». Будет открыто окно «Оснастка диспетчера сертификатов».

Нажмите на кнопку «Готово». Окно «Оснастка диспетчера сертификатов» будет закрыто, Вы вернетесь в окно консоли управления Microsoft.

В левом списке раскройте дерево «Сертификаты — текущий пользователь». Раскройте пункт «Доверенные корневые центры сертификации». Выберите пункт «Сертификаты». В центральной части будут отображены сертификаты выбранного раздела.

В списке сертификатов (центральная часть) найдите сертификаты, выданные УЦ КРИПТО-ПРО (6 сертификатов). Выделите найденные сертификаты и нажмите правую кнопку мыши. В контекстном меню выберите пункт «Удалить».

Будет открыто окно предупреждения. Сертификаты КРИПТО-ПРО не являются ключевыми и могут быть удалены без последствий. Нажмите «Да».

Перед удалением каждого из сертификатов контейнера будет выводиться окно подтверждения на удаление. Во всех окнах следует нажать кнопку «Да»

Шаг 2. Удаление старого сертификата безопасности для веб-узла

В левом списке раскройте дерево «Сертификаты — текущий пользователь». Раскройте пункт «Другие пользователи». Выберите пункт «Сертификаты».

Нажмите правой кнопкой мыши на сертификате. В контекстном меню выберите пункт «Удалить».

Появится окно предупреждения. Нажмите «Да». Сертификат будет удален.

Обновление корневых сертификатов в Windows 10 / Windows Server 2016

Вы также можете получить список доверенных корневых сертификатов со сроками действия с помощью PowerShell:

Get-Childitem cert:LocalMachineroot |format-list

Можно вывести список истекших сертификатов, или которые истекут в ближайшие 30 дней:

Get-ChildItem cert:LocalMachineroot  |  Where {$_.NotAfter -lt  (Get-Date).AddDays(30)}

В консоли mmc вы можете просмотреть информацию о любом сертификате или удалить его из доверенных. В целях безопасности рекомендуем периодически проверять хранилище доверенных сертификатов на наличие поддельных сертификатов с помощью утилиты Sigcheck.

Обновление корневых сертификатов в Windows с помощью GPO в изолированных средах

Если у вас возникла задача регулярного обновления корневых сертификатов в изолированном от Интернета домене Active Directory, есть несколько более сложная схема обновления локальных хранилищ сертификатов на компьютерах домена с помощью групповых политик. В изолированных сетях Windows вы можете настроить обновление корневых сертификатов на компьютерах пользователей несколькими способами.

Этот способ предполагает, что вы регулярно вручную скачиваете и копируете в вашу изолированную сеть файл с корневыми сертификатами, полученный так:

certutil.exe –generateSSTFromWU roots.sst

Затем сертификаты из данного файла можно установить через SCCM или PowerShell логон скрипт в GPO:

$sstStore = ( Get-ChildItem -Path \dc01SYSVOLwinitpro.rurootcertroots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:LocalMachineRoot

Второй способ предполагает получение актуальных корневых сертификатов с помощью команды:

Certutil -syncWithWU -f \dc01SYSVOLrucore.netrootcert

В указанном сетевом каталоге появится ряд файлов корневых сертификатов (CRT) и в том числе файлы (authrootstl.cab, disallowedcertstl.cab, disallowedcert.sst, thumbprint.crt).

Затем с помощью GPP нужно изменить значение параметра реестра RootDirURL  в ветке HKLMSoftwareMicrosoftSystemCertificatesAuthRootAutoUpdate. Этот параметр должен указывать на сетевую папку, из которой клиентам нужно получать новые корневые сертификаты. Перейдите в секцию редактора GPO Computer Configuration ->  Preferences ->  Windows Settings -> Registry. И создайте новый параметр реестра со значениями:

Action: Update
Hive: HKLM
Key path: SoftwareMicrosoftSystemCertificatesAuthRootAutoUpdate
Value name: RootDirURL
Type: REG_SZ
Value data: file://\dc01SYSVOLrucore.netrootcert

Осталось назначить эту политику на компьютеры и после обновления политик проверить появление новых корневых сертификатов в хранилище.

Политика Turn off Automatic Root Certificates Update в разделе Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication settings должна быть выключена или не настроена.

Установка основного сертификата — для Windows 10 (Vista, 7,

На примере сертификатов КриптоПро CSP

Для установки сертификата веб-узла выполните следующие действия. Щелкните правой клавишей мыши по файлу имя_сертификата.cer. В открывшемся контекстном меню выберите команду «Установить сертификат».

При запуске может быть открыто окно предупреждения системы безопасности. Нажмите кнопку «Открыть».

Откроется окно «Мастер импорта сертификатов».

В последующих шагах установки нажимайте на кнопку «Далее», не меняя параметров установки. После завершения установки, на экран будет выведено окно оповещения.

Нажмите на кнопку «ОК», окно будет закрыто. Поздравляем! Вы установили основной сертификат ssl.croinform.cer.

Шаг 3. Установка сертификатов из контейнера

Щелкните правой клавишей мыши по файлу. В открывшемся контекстном меню выберите команду «Установить сертификат».

При запуске может быть открыто окно предупреждения системы безопасности. Нажмите кнопку «Открыть».

Откроется окно «Мастер импорта сертификатов».

Нажмите кнопку «Далее». Мастер перейдет к выбору хранилища для размещения сертификатов

Установите переключатель в положение «Поместить все сертификаты в следующее хранилище» и нажмите кнопку «Обзор». Появится окно «Выбор хранилища сертификатов».

Выберите в списке пункт «Доверенные корневые центры сертификации» и нажмите кнопку «ОК». Окно «Выбор хранилища сертификатов» будет закрыто, и Вы вернетесь в окно «Мастер импорта сертификатов». В поле «Хранилище сертификатов» появится выбранное хранилище сертификатов.

Нажмите кнопку «Далее». Окно «Мастер импорта сертификатов» откроется на шаге «Завершение мастера импорта сертификатов».

Нажмите кнопку «Готово». На экране появится окно предупреждения системы безопасности.

Нажмите на кнопку «ОК», кно будет закрыто. Во всех последующих окнах предупреждения системы безопасности (они будут аналогичны первому) также нажмите кнопку «ОК». После завершения установки всех сертификатов на экран будет выведено окно оповещения.

Нажмите на кнопку «ОК», окно будет закрыто. Сертификаты из контейнера cacer.p7b успешно установлены.

Что такое ЭЦП и сертификат закрытого ключа

Электронная цифровая подпись используется во многих программных продуктах: 1С: Предприятие (и другие программы для ведения хозяйственного или бухгалтерского учёта), СБИС++, Контур.Экстерн (и прочие решения для работы с бухгалтерской и налоговой отчётностью) и других. Также ЭЦП нашла применение в обслуживании физических лиц при решении вопросов с государственными органами.

Как и при подписании бумажных документов, процесс подписания электронных носителей информации связан с «редактированием» первичного источника.

Электронная цифровая подпись документов осуществляется путём преобразования электронного документа с помощью закрытого ключа владельца, этот процесс и называется подписанием документа

На сегодняшний день сертификаты закрытого ключа чаще всего распространяются либо на обычных USB-флешках, либо на специальных защищённых носителях с тем же USB интерфейсом (Рутокен, eToken и так далее).

Если вы используете ЭЦП у себя дома, то каждый раз подключать/отключать токен быстро надоедает. Кроме того, носитель будет занимать один USB-порт, которых и так не всегда хватает для подключения всей необходимой периферии.
Если же вы используете ЭЦП на работе, то бывает, что ключ удостоверяющим центром выдан один, а подписывать документы должны разные люди. Таскать контейнер туда-сюда тоже не удобно, да ещё бывают и случаи, когда в одно время с сертификатом работают сразу несколько специалистов.

Кроме того, и дома, и, особенно, на работе, случается, что на одном компьютере необходимо производить действия с использованием сразу нескольких ключей цифровой подписи. Именно в тех случаях, когда использование физического носителя сертификата неудобно, можно прописать ключ ЭЦП в реестр КриптоПро и использовать сертификат, не подключая носитель к USB-порту компьютера.

Добавление в КриптоПро CSP

Запускаем программу от имени администратора правой кнопкой мыши или из меню самой утилиты на вкладке Общие

Теперь переходим на вкладку Оборудование и нажимаем на кнопку Настроить считыватели…
Если в открывшемся окне нет варианта Реестр, то, чтобы его здесь вывести, жмём на кнопку Добавить…

Далее, следуя командам Мастера установки считывателя поэтапно перемещаемся по окнам:

1. Жмём кнопку Далее в первом окне.
2. Из списка считывателей от всех производителей выбираем вариант Реестр и снова жмём Далее.
3. Вводим произвольное имя считывателя, можно оставить название по умолчанию. Жмём Далее.
4. В последнем окне видим оповещение, что после завершения настройки считывателя рекомендуется перезагрузить компьютер. Жмём кнопку Готово и самостоятельно перезагружаем машину.

Считыватель Реестр добавлен, о чём свидетельствует соответствующий пункт в окне Управление считывателями (напоминаем, что данное окно вызывается по пути КриптоПро — Оборудование — Настроить считыватели…)

Установка сертификата закрытого ключа КриптоПро CSP

В завершении настройки подписи документов без подключения носителя ключа к компьютеру нам остаётся только установить сертификат закрытого ключа из контейнера созданного носителя.

Чтобы установить сертификат в КриптоПро необходимо проделать следующее:

1. В утилите CSP на вкладке Сервис жмём на кнопку Просмотреть сертификаты в контейнере…
2. В открывшемся окне нажимаем на кнопку Обзор, где по заданному нами имени выбираем искомый носитель, подтвердив выбор кнопкой OK. Нажимаем Далее.
3. В завершающем окне проверяем правильность выбора сертификата и подтверждаем решение кнопкой Установить.

Теперь у нас установлен Сертификат закрытого ключа из локального носителя. Настройка КриптоПро завершена, но вам следует помнить, что для многих программных продуктов также потребуется перепрописать новый ключ в настройках системы.
После проделанных действий мы можем подписывать документы без подключения ключа, будь то Рутокен, eToken или какой-то другой физический носитель.

Источники: http://croinform.ru/ — https://winitpro.ru/ — https://miradmin.ru/

А вот и финальная третья часть нашей серии статей о центре сертификации на предприятии. Сегодня рассмотрим развертывание службы сертификатов на примере Windows Server 2016. Поговорим о подготовке контроллера домена, подготовке веб-сервера, установке корневого и издающего центров сертификации и об обновлении сертификатов. Заглядывайте под кат!

Первая часть серии

Вторая часть серии

Словарь терминов

В этой части серии использованы следующие сокращения и аббревиатуры:

• PKI (Public Key Infrastructure) — инфраструктура открытого ключа, набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
• X.509 — стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
• ЦС (Центр Сертификации) — служба выпускающая цифровые сертификаты. Сертификат — это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
• CRL (Certificate Revocation List) — список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем… Приложения могут использовать CRL для подтверждения, что предъявленный сертификат является действительным и не отозван издателем.
• SSL (Secure Sockets Layer) или TLS (Transport Layer Security) — технология обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
• HTTPS (HTTP/Secure) — защищённый HTTP, является частным случаем использования SSL.
• Internet PKI — набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.
• CPS (Certificate Practice Statement) — документ, описывающий процедуры управления инфраструктурой открытого ключа и цифровыми сертификатами.

Общий план развёртывания

Для развёртывания службы сертификатов нам потребуется четыре машины с Windows Server 2016, которые будут выполнять следующие функции:

1. Контроллер домена — необходим для функционирования домена Active Directory;
2. Веб-сервер — будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
3. Корневой ЦС — будет выполнять функции корневого ЦС;
4. Подчинённый ЦС — будет выполнять функции издающего ЦС.

Развёртывание PKI будет проходить поэтапно на каждом сервере в том порядке, в котором они указаны выше. Подготовка контроллера домена будет сводиться к обеспечению функций Active Directory, GPO и учётных записей.

Подготовка контроллера домена

Перед развёртыванием PKI необходимо убедиться в работоспособности домена Active Directory и что все необходимые серверы (а именно, веб-сервер и подчинённый ЦС) введены в домен. А так же, что подготовлены необходимые учётные записи. На данном этапе нам потребуется только учётная запись с правами Enterprise Admins.

Ряд операций на подчинённом ЦС требуют прав Enterprise Admins, поскольку производится запись в раздел configuration naming context. Если это корневой домен леса, то для этих операций достаточно прав Domain Admins.

Следующим шагом будет конфигурирование политики автоматической выдачи сертификатов (autoenrollment). Эта политика нужна будет в процессе эксплуатации служб сертификатов для автоматической выдачи и обновления истёкших сертификатов на клиентах. Политика настраивается в конфигурации компьютера и пользователя:

• Computer ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key InfrastructureCertificate Services Client – Auto-Enrollment
• User ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key InfrastructureCertificate Services Client – Auto-Enrollment

Политика в обоих разделах должна быть сконфигурирована как показано на следующей картинке:

Сконфигурированный объект групповых политик (GPO) должен быть пристыкован к корню домена. Данную процедуру необходимо повторить во всех доменах текущего леса Active Directory.

Далее, необходимо создать запись типа CNAME с именем CDP на сервере ДНС, который будет указывать на веб-сервер (IIS). Эту процедуру необходимо выполнить как на внутреннем, так и на внешнем (который обслуживает зону в интернете) серверах ДНС. Запись можно создать при помощи PowerShell:

Add-DnsServerResourceRecord -CName -Name "cdp" -HostNameAlias "iis.contoso.com" -ZoneName "contoso.сom" 

Подготовка веб-сервера

На веб-сервере нам потребуется выполнить следующее: установить службу IIS (если ещё не установлена), создать общую папку и сконфигурировать веб-сайт на использование этой папки.

• Установка службы IIS

Для установки службы IIS можно воспользоваться следующей командой:

Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools

• Создание папки PKIdata

Согласно нашей конфигурационной таблице (см. часть 2), для хранения сертификатов ЦС и списков отзыва нам потребуется общая папка с сетевым именем PKI по следующему пути: C:InetPubwwwrootPKIdata

New-Item -ItemType Directory -Path C:InetPubwwwroot -Name PKIdata -Force
New-SmbShare -Path C:inetpubwwwrootPKIdata -Name PKI -FullAccess everyone

После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.

• Создание веб-сайта

Теперь нам необходимо создать отдельный веб-сайт с именем “CDP” и хост-именем “cdp.contoso.com”:

New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:inetpubwwwrootPKIdata
New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:inetpubwwwrootPKIdata

• Включение поддержки Delta CRL

В нашем сценарии издающий ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию, IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Для этого необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:

Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

Установка корневого ЦС

Фактическая установка ЦС будет включать в себя несколько этапов:

1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
2. Установка компонента ЦС;
3. Выполнение постустановочной конфигурации;
4. Проверка установки.

Перед установкой корневого ЦС, необходимо ещё раз вернуться к конфигурационным таблицам:

Название параметра	Значение параметра
Сервер ЦС
Класс ЦС	Standalone CA
Тип ЦС	Root CA
Сертификат
Имя сертификата	Contoso Lab Root Certification authority
Дополнительный суффикс	OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
Провайдер ключа	RSA#Microsoft Software Key Storage Provider
Длина ключа	4096 бит
Алгоритм подписи	SHA256
Срок действия	15 лет

В таблице я выделил только те параметры, которые задаются до и в процессе установки. Остальные параметры будут настраиваться после установки.

Предварительная конфигурация

Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work. Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета Install-AdcsCertificationAuthority:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Root Certification Authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType StandaloneRootCA `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -ValidityPeriod "years" `
    -ValidityPeriodUnits 15 `
    -DatabaseDirectory $(Join-Path $env:SystemRoot "System32CertLog")

Итоговая настройка

После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:

Название параметра	Значение параметра
Сервер ЦС
Срок действия издаваемых сертификатов	15 лет
Точки публикации CRT	1) По-умолчанию 2) C:CertDatacontoso-rca<CertificateName>.crt 3) IIS:InetPubPKIdatacontoso-rca<CertificateName>.crt*
Точки распространения CRT	1) cdp.contoso.com/pki/contoso-rca<CertificateName>.crt
Точки публикации CRL	1) По-умолчанию 2) C:CertDatacontoso-rca<CRLNameSuffix>.crt 3) IIS:InetPubPKIdatacontoso-rca<CRLNameSuffix>.crt*
Точки распространения CRL	1) cdp.contoso.com/pki/contoso-rca<CRLNameSuffix>.crt
Сертификат
Состав CRL	Base CRL
Base CRL
Тип	Base CRL
Срок действия	6 месяцев
Расширение срока действия	1 месяц
Алгоритм подписи	SHA256
Публикация в AD	Нет

* — копируется на сервер IIS

Скрипт настройки

Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Root CA post-installation script                               ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=C:CertDatacontoso-rca%%8.crl
SET CDP=http://cdp.contoso.com/pki/contoso-rca%%8.crl
SET AIA=http://cdp.contoso.com/pki/contoso-rca%%4.crt

:: Создаём папку в корне системного диска, куда будут записываться файлы ЦС. Эта папка
:: создаётся для удобства, чтобы не искать папку CertEnroll в глубине папки Windows.
md C:CertData

:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CACRLPublicationURLs "1:%windir%system32CertSrvCertEnroll%%3%%8.crln1:%CrlLocal%n2:%CDP%"

certutil -setreg CACACertPublicationURLs "1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в папку CertData
ren %windir%system32CertSrvCertEnroll*.crt contoso-rca.crt
copy %windir%system32CertSrvCertEnrollcontoso-rca.crt C:CertData

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CAValidityPeriodUnits 15
certutil -setreg CAValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
certutil -setreg CACRLPeriodUnits 180
certutil -setreg CACRLPeriod "Days"
certutil -setreg CACRLOverlapPeriod "Months"
certutil -setreg CACRLOverlapUnits 1

:: Отключаем дифференциальные списки отзыва (или Delta CRL)
certutil -setreg CACRLDeltaPeriodUnits 0

:: Отключаем генерацию кросс-сертификатов
certutil -setreg caCRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

:: Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва
certutil –setreg caCRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS

:: Включаем полный аудит событий на ЦС**
certutil -setreg CAAuditFilter 127

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg cacspCNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «n». Каждый путь начинается с числа и отделяется от самого пути символом двоеточия. Это число в начале пути указывает битовую маску флагов публикации для конкретного пути. Значение каждого бита для расширений CDP и AIA приведено в следующей таблице:

Название галочки в MMC	Числовое значение	Название галочки в MMC	Числовое значение
Publish CRLs to this location.	1	Include in the AIA extension of issued certificates.	2
Include in the CDP extension of issued certificates.	2	Include in the Online Certificate Status. Protocol (OCSP) extension.	32
Include in CRLs. Clients use this to find Delta CRL locations.	4
Include in all CRLs. Specifies where to publish in AD DS when publishing manually.	8
Publish Delta CRLs to this location.	64
Include in the IDP extension of issued CRLs.	128

Если взять путь для CDP: 1:%windir%system32CertSrvCertEnroll%%3%%8.crl, то цифра 1 в начале строки говорит о том, что это путь физического размещения файла (Publich CRLs to this location). Другие опции здесь не используются. Для включения пути, который будет публиковаться в издаваемых сертификатах, мы будем использовать опцию «Include in the CDP extension of issued certificates» с числовым значением 2. Такой же принцип применяется и для остальных путей.

В каждом пути включены переменные с двойным знаком процента «%%». Это переменные, которые ЦС при формировании пути будет автоматически заполнять исходя из типа переменной.

Первый знак процента используется как эскейп-символ, чтобы процессор командной строки воспринял следующий знак процента как литерал. Дело в том, что знак процента в командном процессоре CMD является служебным символом. Сервер ЦС так же использует знак процента для указания, что это переменная. Для исключения конфликта в командном процессоре используется последовательность из двух знаков процента.

Следующая таблица содержит описание всех доступных переменных и их краткое описание:

Переменная в редакторе расширений CDP и AIA	Переменная в скрипте	Где используется	Значение
<ServerDNSName>	%1	CDP/AIA	Полное ДНС имя сервера ЦС
<ServerShortName>	%2	CDP/AIA	Короткое (NetBIOS) имя сервера ЦС
<CaName>	%3	CDP/AIA	Имя ЦС (атрибут CN в сертификате)
<CertificateName>	%4	AIA	Индекс сертификата ЦС. Используется только при обновлении сертификата ЦС.
<ConfigurationContainer>	%6	CDP/AIA	Путь к configuration naming context в Active Directory
<CATruncatedName>	%7	CDP/AIA	Укороченное (санитизированное) имя сертификата ЦС. В общем случае будет совпадать с полным именем ЦС
<CRLNameSuffix>	%8	CDP	Индекс ключа ЦС, которым был подписан данный CRL. Используется при обновлении ключевой пары ЦС.
<DeltaCRLAllowed>	%9	CDP	Добавляет суффикс для Delta CRL (знак «+»).
<CDPObjectClass>	%10	CDP	Класс объекта в Active Directory
<CAObjectClass>	%11	CDP/AIA	Класс объекта в Active Directory

В нашем конкретном случае будут использоваться только две переменные: <CertificateName> и <CRLNameSuffix>. Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(index)», где index — номер сертификата ЦС. Индексирование начинается с нуля. Например, имя файла для последующего сертификата ЦС будет иметь вид: contoso-rca(1).crt. И так далее. То же самое касается и переменной , только здесь будет указываться индекс ключевой пары ЦС.

Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.

Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

Опытные администраторы знают к чему приводит включение Audit Object Access — к лавинному созданию записей в журнале от других компонентов ОС. Например, аудит доступа файловой системы, реестра, других установленных ролей и т.д. В результате, журнал может буквально за день-два заполниться до отказа. Поэтому для эффективного использования аудита необходимы меры по фильтрации ненужных событий, например, при помощи функции подписки на интересующие события. Нет смысла в аудите, если его никто не может прочитать и эффективно проанализировать. Но эта тема уже выходит за рамки этой статьи.

Прочие настройки

После того как корневой ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
• Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.

Если всё хорошо, тогда скопируйте содержимое папки C:CertData на сервер IIS в папку PKIData. Сертификат корневого ЦС уже можно импортировать на все устройства, которые будут использовать нашу PKI.

Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:

Certutil -f -dspublish pathcontoso-rca.crt RootCA

Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:

Certutil -f -addstore Root pathcontoso-rca.crt

Установка издающего ЦС

Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:

1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
2. Установка компонента ЦС;
3. Выполнение постустановочной конфигурации;
4. Проверка установки и конфигурации.

Предустановочная конфигурация

Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:

1. Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
2. Администраторы сами должны определять какие шаблоны будут использовать в организации.

Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:

; заголовок INI файла
[Version]
Signature= "$Windows NT$"

; указываем список политик, которые будут включены в сертификат ЦС. В нашем
; случае будет одна политика под названием AllIssuancePolicies.
[PolicyStatementExtension]
Policies = AllIssuancePolicy
; конфигурируем детали самой политики. Ссылку на документ Certificate Practice
; Statement (CPS) и объектный идентификатор политики
[AllIssuancePolicy]
URL = http://cdp.contoso.com/pki/contoso-cps.html
OID = 2.5.29.32.0
[BasicConstraintsExtension]
IsCA = True
PathLegth = 0
IsCritical = True
; секция прочих настроек ЦС
[certsrv_server]
; отключаем автоматическую загрузку шаблонов сертификатов для выдачи
LoadDefaultTemplates = 0

Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

Название параметра	Значение параметра
Сервер ЦС
Класс ЦС	Enterprise CA
Тип ЦС	Subordinate CA
Автоматическая загрузка шаблонов	Нет
Сертификат
Имя сертификата	Contoso Lab Issuing Certification authority
Дополнительный суффикс	OU=Division Of IT, O=Contoso Pharmaceuticals, C=US
Провайдер ключа	RSA#Microsoft Software Key Storage Provider
Длина ключа	4096 бит
Алгоритм подписи	SHA256
Срок действия	15 лет (определяется вышестоящим ЦС)
Политики выдачи	1) Имя: All Issuance Policies OID=2.5.29.32.0 URL=http://cdp.contoso.com/pki/contoso-cps.html
Basic Constraints	isCA=True (тип сертификата — сертификат ЦС) PathLength=0 (запрещается создание других промежуточных ЦС под текущим ЦС).

В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета Install-AdcsCertificationAuthority:

Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" `
    -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
    -CAType EnterpriseSubordinateCa `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256

После выполнения этой команды будет выведено сообщение о том, что установка ЦС не завершена и для её завершения необходимо отправить сгенерированный запрос (находится в корне системного диска) на вышестоящий ЦС и получить подписанный сертификат. Поэтому находим файл с расширением «.req» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:

 # отправляем запрос на ЦС.
certreq -submit 'C:CA-01.contoso.com_Contoso Lab Issuing Certification authority.req'
# предыдущая команда выведет номер запроса. Укажите этот номер запроса в следующей команде
# в моём случае это номер 2
certutil -resubmit 2
# после выпуска сертификата сохраните его в файл. При этом укажите тот же самый номер
# запроса, который был указан после выполнения первой команды
certreq -retrieve 2 C:subca.crt

Полученный файл (subca.crt) необходимо скопировать обратно на издающий ЦС и завершить инсталляцию:

certutil -installcert c:subca.crt
net start certsvc

Мы устанавливаем на ЦС выписанный сертификат и запускаем службу сертификатов. После успешной установки можно запустить оснастку Certification Authorities MMC (certsrv.msc) и убедиться, что сертификат успешно установлен и ЦС в работающем состоянии. Теперь осталось дело за постустановочной конфигурацией.

Итоговая настройка

По аналогии с корневым ЦС, нам потребуется сконфигурировать ряд параметров на издающем ЦС. Для этого мы снова напишем BATCH скрипт с использованием утилиты certutil.exe. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:

Аналогичная таблица составляется и для издающего ЦС.

Название параметра	Значение параметра
Сервер ЦС
Срок действия издаваемых сертификатов	Максимально: 5 лет (остальное контролируется шаблонами сертификатов)
Публикация в AD (контейнеры)	AIA NTAuthCertificates
Состав CRL	Base CRL Delta CRL
Точки публикации CRT	1) По-умолчанию 2) \IISPKIcontoso-pica<CertificateName>.crt
Точки распространения CRT	1) cdp.contoso.com/pki/contoso-pica<CertificateName>.crt
Точки публикации CRL	1) По-умолчанию 2) \IISPKIcontoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
Точки распространения CRL	1) cdp.contoso.com/pki/contoso-pica<CRLNameSuffix><DeltaCRLAllowed>.crl
Base CRL
Тип	Base CRL
Срок действия	1 неделя
Расширение срока действия	По умолчанию
Алгоритм подписи	SHA256
Публикация в AD	Нет
Delta CRL
Тип	Delta CRL
Срок действия	1 день
Расширение срока действия	По-умолчанию
Алгоритм подписи	SHA256
Публикация в AD	Нет

За основу мы возьмём скрипт с корневого ЦС и изменим только отдельные фрагменты:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Issuing CA post-installation script                            ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=\IISPKIcontoso-pica%%8%%9.crl
SET CDP=http://cdp.contoso.com/pki/contoso-pica%%8%%9.crl
SET AIA=http://cdp.contoso.com/pki/contoso-pica%%4.crt

:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CACRLPublicationURLs "1:%windir%system32CertSrvCertEnroll%%3%%8%%9.crln65:%CrlLocal%n6:%CDP%"

certutil -setreg CACACertPublicationURLs "1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в сетевую папку
ren %windir%system32CertSrvCertEnroll*.crt contoso-pica.crt
copy %windir%system32CertSrvCertEnrollcontoso-pica.crt \IISPKI

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CAValidityPeriodUnits 5
certutil -setreg CAValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
:: базовый CRL
certutil -setreg CACRLPeriodUnits 1
certutil -setreg CACRLPeriod "weeks"

:: Delta CRL
certutil -setreg CACRLDeltaPeriodUnits 1
certutil -setreg CACRLDeltaPeriod "days"

:: Включаем полный аудит событий на ЦС**
certutil -setreg CAAuditFilter 127

:: Включаем наследование расширения Certificate Policies в издаваемых сертификатах 
certutil -setreg PolicyEnableRequestExtensionList +"2.5.29.32"

:: Включаем поддержку расширения OcspRevNoCheck, если планируется установка
:: сетевого ответчика (Online Responder или OCSP сервера)
certutil -v -setreg policyeditflags +EDITF_ENABLEOCSPREVNOCHECK

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg cacspCNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Заметим, что в путях CRLDistribution Points, изменены флаги публикации (добавлена публикация Delta CRL) и добавлена переменная %9 в имя файла для поддержки уникального имени для дельты.

Здесь мы больше не создаём папку в корне системного диска, а используем сетевую папку PKI на сервере IIS, куда напрямую копируем файл сертификата и публикуем списки отзыва.

Прочие настройки

После того как издающий ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям.
• Откройте сетевую папку PKI (на сервере IIS) и убедитесь, что там есть два файла сертификата (корневого и издающего ЦС) и три списка отзыва (один для корневого, два для издающего ЦС). Убедитесь, что поля в сертификатах и списках отзыва соответствуют ожидаемым значениям.

Когда основные параметры проверены, необходимо убедиться в правильной связи иерархии ЦС и доступности всех внешних файлов для клиентов. Для этого на сервере ЦС (а лучше, на рабочей станции, где установлены средства удалённого администрирования ЦС) необходимо запустить оснастку Enterprise PKI Health (pkiview.msc). Оснастка автоматически построит текущую иерархию и проверит доступность всех путей для скачивания сертификатов ЦС и списков отзыва. Никаких ошибок быть не должно. Если есть ошибка, необходимо её точно идентифицировать и устранить. В случае успешной настройки оснастка будет выглядеть следующим образом для корневого ЦС:

И для издющего ЦС:

Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health не показывает ошибок, это может судить о том, что PKI установлена верно.

Рекомендации

После того, как все ЦС установлены, сконфигурированы и их работоспособность проверена, можно приступать к их эксплуатации. В этом разделе я дам несколько полезных рекомендаций, которых следует придерживаться, чтобы предостеречь себя от возможных потенциальных проблем во время эксплуатации PKI.

Шаблоны сертификатов

Наряду с установкой издающего ЦС, в Active Directory устанавливается набор уже готовых шаблонов сертификатов. Их можно просмотреть в оснастке Certificate Templates MMC (certtmpl.msc). Рекомендации по шаблонам сертификатов:

Использование готовых шаблонов сертификатов

Я рекомендую использовать их копии, даже если вы не планируете вносить в них изменения. Для создания копии шаблона выберите в списке подходящий шаблон, в контекстном меню выберите Duplicate Template и создайте его копию. Целесообразно в имя шаблона включить название компании, чтобы отличить предустановленный шаблон от вами созданного. Например, Contoso Web Server, Contoso Smart Card Logon. Это позволит сравнить настройки исходного и вами созданного шаблона в случае неработоспособности шаблона.

Версия шаблона

Начиная с Windows Server 2012, интерфейс создания шаблона несколько изменился. В самом начале появляется окно с выбором версии ОС на ЦС и предполагаемом клиенте:

Если у вас используются современные версии ОС (например, Windows 7 и выше), может появиться желание выставить настройки на максимум. Если вы не уверены, что ваше приложение совместимо с CNG (Cryptography Next Generation), следует использовать настройки, которые приведены на картинке. Если вы выставляете ОС сервера и клиента выше, чем Windows Server 2003/Windows XP, шаблон будет использовать криптографию несовместимую с этими приложениями. Например, большинство приложений, написанных на .NET, семейство продуктов System Center, службы федераций (AD FS) и т.д. не смогут использовать ключи таких сертификатов (но проверять смогут).

Успешно такие сертификаты смогут использовать приложения, которые используют не .NET, а нативные функции CryptoAPI. К таким приложениям можно отнести, например, IIS, Remote Desktop Services.

 
Поля Subject и Subject Alternative Names

Существует два метода заполнения поля Subject и расширения Subject Alternative Names: автоматический и ручной. Это настраивается в настройках шаблона сертификата, во вкладке Subject Name.

Если выбран второй пункт (как на картинке), ЦС игнорирует имя субъекта из запроса сертификата и заполняет эти поля из свойств учётной записи пользователя или устройства, которое запрашивает сертификат. В ряде случаев это не подходит (например, сертификаты для внутренних веб-сайтов) и имя субъекта заполняется из значения в запросе сертификата. Тогда переключатель необходимо выставить в верхнее положение. Дополнительно к этому, на вкладке Issuance Requirements обязательно надо выставить галочку «CA certificate manager approval».

Это необходимо затем, что имя для сертификата никак не проверяется. Если этот момент не контролировать, пользователь может запросить сертификаты на любое имя и скомпрометировать весь лес Active Directory. Вряд ли вы позволите рядовому пользователю получить сертификат на имя администратора. После требования одобрения запроса менеджером сертификатов на ЦС, каждый запрос с явным указанием субъекта сертификата будет попадать на ЦС в папку Pending Requests и не будет подписан, пока оператор ЦС не изучит его содержимое и не примет решение о выпуске. Т.е. каждый такой запрос необходимо вручную проверять на содержимое и убедиться, что в запросе указаны верные и допустимые имена. В противном случае запрос должен быть отклонён.

Права на шаблоны сертификатов

Шаблоны сертификатов в Active Directory хранятся в разделе configuration naming context, который реплицируется между всеми контроллерами домена в лесу. Поэтому для назначения прав на шаблоны сертификатов можно использовать только глобальные и универсальные группы. Избегайте назначения прав отдельным пользователям и устройствам.

Обновление сертификатов ЦС

Периодически необходимо обновлять сертификаты ЦС. Рассмотрим несколько аспектов, связанных с обновлением сертификатов ЦС.

Периодичность обновления сертификата ЦС

Это делается в следующих случаях:

• Срок жизни сертификата ЦС истекает;
• Ключ ЦС скомпрометирован;
• Необходимо изменить длину ключа или алгоритм подписи;
• Слишком большой список отзыва (больше нескольких мегабайт).

Первый вопрос, если всё идёт штатно, за какое время до истечения срока действия сертификата ЦС его нужно обновлять?

Сертификат издающего ЦС должен обновляться за максимальный срок действия издаваемых сертификатов. В нашем случае срок действия сертификата издающего ЦС 15 лет, а максимальный срок действия издаваемых сертификатов 5 лет (см. конфигурационную таблицу). Это означает, что сертификат издающего ЦС необходимо обновить через 10 лет. Если это время затянуть, то мы не сможем обеспечить необходимый срок действия для самого долгосрочного шаблона.

Порядок обновления ЦС

В нашей двухуровневой иерархии сертификаты корневого и издающего ЦС имеют одинаковый срок действия. Поэтому, когда вы принимаете решение об обновлении сертификата любого ЦС, необходимо обновлять их вместе. Первым обновляется сертификат корневого ЦС, затем сертификат издающего ЦС.

Генерация ключей при обновлении сертификатов ЦС

При обновлении сертификатов ЦС вам предлагается две опции: использовать существующую ключевую пару или сгенерировать новую:

В диалоговом окне обновления ключевой пары приведены рекомендации Microsoft по выбору ключевой пары. Однако, практика показывает, что эти рекомендации устарели. Следует всегда генерировать новую ключевую пару. При использовании нескольких сертификатов ЦС клиентский модуль построения цепочки сертификатов иногда может ошибиться и выбрать неправильный сертификат. В базе знаний Microsoft отмечены такие проблемы. Примеры статей:

• Certificate validation fails when a certificate has multiple trusted certification paths to root CAs.
• «0x80092013, CRYPT_E_REVOCATION_OFFLINEA» error message when you try to verify a certificate that has multiple chains in Windows Server 2008 or in Windows Vista.

При генерации новой ключевой пары для каждого сертификата будет гарантирован только один путь к корневому сертификату и модуль построения цепочек сертификатов уже не ошибётся.

Резервное копирование

Вопросы резервного копирования и восстановления после отказа являются отдельной темой. Здесь я лишь отмечу основные моменты, которые следует учесть при планировании стратегии резервного копирования.

Microsoft Active Directory Certificate Services предоставляет инструменты для резервного копирования компонентов ЦС:

• Оснастка Certification Authority MMC (certsrv.msc);
• Утилита certutil.exe с параметром -backup.

С ними можно сделать резервную копию для ключевой пары ЦС и базы данных. Однако эти инструменты не позволяют делать резервную копию настроек ЦС. Эти операции необходимо выполнять вручную. Все настройки ЦС находятся в реестре по следующему пути:

HKLMSystemCurrentControlSetServicesCertSvc

При резервном копировании всегда экспортируйте данную ветку реестра. При восстановлении ЦС сохранённый REG файл импортируется обратно в реестр после установки роли ЦС.

Полный список элементов ЦС, который подлежит обязательному резервному копированию выглядит так:

• Ключи и сертификаты ЦС;
• База данных ЦС;
• Настройки ЦС из реестра;
• Предустановочный конфигурационный файл;
• Установочные и конфигурационные скрипты.

Этот список не зависит от принятой в вашей компании стратегии резервного копирования, он всегда должен быть включён в список резервных копий.

Об авторе

Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.

Обновлено: 24.12.2022
Опубликовано: 03.09.2020

Актуальные системы семейства Windows, подключенные к Интернету, могут автоматически обновлять корневые сертификаты. В противном случае, обновление необходимо выполнять вручную. Если это не делать, мы можем столкнуться с рядом проблем:

• Не открываются или выдают предупреждение безопасности некоторые (или все) сайты, работающие по https.
• Некорректная работа отдельных приложений (например, антивирусных систем).
• Ошибки при подключении по удаленному рабочему столу.

Это пример ошибок, который не претендует на свою полному. Чаще всего, проблемы встречаются на системах, снятых с обслуживания компанией Microsoft (Windows XP, 7, а также Server 2003, 2008).

Обновление сертификатов

Обновление доверенных корневых сертификатов выполняется во время обновления операционной системы. Если последнее включено, то нашего участия не требуется, иначе, можно установить обновление вручную. Пример такого пакета — KB931125 (ссылка).

Однако, если операционная система устарела, разработчик прекращает выпуск обновлений, и мы не можем воспользоваться средствами обновления системы. В таком случае, необходимо сделать выгрузку корневых сертификатов на актуальной системе и перенести их на устаревший.

Получение актуальных сертификатов

Для начала, выгрузим сертификаты на компьютере с актуальной версией Windows (10) и подключением к сети Интернет.

Создадим каталог, в который будет выгружен файл с корневыми сертификатами, например, C:CA (папка CA на диске C).

Открываем командную строку от администратора и вводим команду:

certutil.exe -generateSSTFromWU C:CAroots.sst

* где C:CA — каталог, который мы создали; roots.sst — файл, в который будут выгружены сертификаты.
* если мы получили ошибку Не удается найти указанный файл. 0x80070002, то необходимо убедиться, что каталог CA создан (в нашем примере в корне диска С).

В папке C:CA мы должны увидеть файл roots.sst.

Установка/обновление корневых сертификатов

Полученный на предыдущем этапе файл переносим на компьютер, где необходимо обновить доверенные корневые сертификаты, например, также в папку C:CA. Скачиваем утилиту rootsupd и распаковываем ее в этот же каталог.

Открываем командную строку от администратора и вводим команду:

C:CArootsupd.exe /c /t:C:CA

* где C:CA — папка, в которую мы перенесли корневые сертификаты.

В появившемся окне Roots Update:

… выбираем No, чтобы не переписывать наш файл roots.sst.

В папке C:CA должны появится новые файлы, в том числе, утилита updroots. Вводим теперь команду:

C:CAupdroots.exe C:CAroots.sst

Готово. 

Updating List of Trusted Root Certificates in Windows 10/8.1/7

All Windows versions have a built-in feature for automatically updating root certificates from the Microsoft websites. As part of the Microsoft Trusted Root Certificate Program, MSFT maintains and publishes a list of certificates for Windows clients and devices in its online repository. If the verified certificate in its certification chain refers to the root CA that participates in this program, the system will automatically download this root certificate from the Windows Update servers and add it to the trusted ones.

Windows requests a trusted root certificate lists (CTL) renewal once a week. If Windows doesn’t have a direct access to the Windows Update directory, the system won’t be able to update the root certificates, so a user may have some troubles when browsing websites (which SSL certificates are signed by an untrusted CA – see the article about the “Chrome SSL error: This site can’t provide a secure connection”), or with installing/running signed scripts and apps.

In this article, we’ll try to find out how to manually update the list of root certificates in TrustedRootCA on isolated networks or computers/servers without a direct Internet connection.

Managing Trusted Root Certificates in Windows 10

How to see the list of root certificates of a Windows computer?

You can also get a list of trusted root certificates with expiration dates using PowerShell:

Get-Childitem cert:LocalMachineroot |format-list

You can list the expired certificates, or which expire in the next 30 days:

Get-ChildItem cert:LocalMachineroot | Where

In the mmc console, you can view information about any certificate or remove it from trusted ones.

You can manually transfer the root certificate file between Windows computers using the Export/Import function.

Rootsupd.exe Utility

In Windows XP, the rootsupd.exe utility was used to update computer`s root certificates. The list of root and revoked certificates in it was regularly updated. The utility was distributed as a separate update KB931125 (Update for Root Certificates). Let’s see if we can use it now.

However, as you can see, these certificate files were created on April 4, 2013 (almost a year before the end of official support of Windows XP). Thus, since then the utility has not been updated and cannot be used to install up-to-date certificates. A little later we will need the updroots.exe file.

Certutil: Getting Latest Root Certificates from Windows Update

The latest version of the Certutil.exe tool for managing certificates (available in Windows 10), allows you to download from Windows Update and save the actual root certificates list to the SST file.

To generate an SST file, run this command with the administrator privileges on a computer running Windows 10 and having a direct access to the Internet:

As a result, an SST file containing up-to-date list of root certificates will appear in the target directory. Double-click to open it. This file is a container containing trusted root certificates.

As you can see, a familiar Certificate Management snap-in opens, from which you can export any of the certificates you have got. In my case, there have been 358 items in the list of certificates. Obviously, it is not rational to export the certificates and install them one by one.

To install all the certificates from the SST file and add them to the list of trusted root certificates on a computer, you can use the PowerShell commands:

To install all certificates listed in the file, use the updroots.exe (it is located in the rootsupd.exe file, which was extracted in the previous section).

Run the certmgr.msc snap-in and make sure that all certificates have been added to the Trusted Root Certification Authority.

The List of Root Certificates in STL Format

There is another way to get the list of root certificates from Microsoft website. To do it, download the file http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab (updated twice a month). Using any archiver (or even Windows Explorer) unpack authrootstl.cab. It contains one file authroot.stl.

The Authroot.stl file is a container with a list of trusted certificates in Certificate Trust List format.

You can install this file in the system using the context menu of the STL file (Install CTL).

Or using certutil.exe tool:

After you have run the command, a new section Certificate Trust List appears in Trusted Root Certification Authorities container of the Certificate Manager console (certmgr.msc).

In the same way, you can download and install the list of the revoked (disallowed) certificates that have been removed from Root Certificate Program. To do it, download disallowedcertstl.cab (http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab), unpack it and add to the Untrusted Certificates section using this command:

Updating Root Certificates in Windows with GPO in an Isolated Environment

If you have the task of regularly updating root certificates in an Internet-isolated Active Directory domain, there is a slightly more complicated scheme for updating local certificate stores on domain joined computers using Group Policies. You can configure root certificate updates on user computers in the isolated Windows networks in several ways.

The first way assumes that you regularly manually download and copy to your isolated network a file with root certificates obtained as follows:

certutil.exe –generateSSTFromWU roots.sst

Then the certificates from this file can be distributed via SCCM or PowerShell logon script in GPO:

The second way is to obtain the actual root certificates using the command:

A number of root certificate files (CRT file format) will appear in the specified network shared folder, including files (authrootstl.cab, disallowedcertstl.cab, disallowedcert.sst, thumbprint.crt).

It remains to link this policy on a computer`s OU and after updating the policies to check for new root certificates in the certstore.

In this article, we looked at several ways to renew trusted root certificates on a Windows network that is isolated from the Internet.

Источник

Ручное обновление корневых сертификатов на Windows

Актуальные системы семейства Windows, подключенные к Интернету, могут автоматически обновлять корневые сертификаты. В противном случае, обновление необходимо выполнять вручную. Если это не делать, мы можем столкнуться с рядом проблем:

Это пример ошибок, который не претендует на свою полному. Чаще всего, проблемы встречаются на системах, снятых с обслуживания компанией Microsoft (Windows XP, 7, а также Server 2003, 2008).

Обновление сертификатов

Обновление доверенных корневых сертификатов выполняется во время обновления операционной системы. Если последнее включено, то нашего участия не требуется, иначе, можно установить обновление вручную. Пример такого пакета — KB931125.

Однако, если операционная система устарела, разработчик прекращает выпуск обновлений, и мы не можем воспользоваться средствами обновления системы. В таком случае, необходимо сделать выгрузку корневых сертификатов на актуальной системе и перенести их на устаревший.

Получение актуальных сертификатов

Для начала, выгрузим сертификаты на компьютере с актуальной версией Windows (10) и подключением к сети Интернет.

Создадим каталог, в который будет выгружен файл с корневыми сертификатами, например, C:CA (папка CA на диске C).

Открываем командную строку от администратора и вводим команду:

* где C:CA — каталог, который мы создали; roots.sst — файл, в который будут выгружены сертификаты.
* если мы получили ошибку Не удается найти указанный файл. 0x80070002, то необходимо убедиться, что каталог CA создан (в нашем примере в корне диска С).

В папке C:CA мы должны увидеть файл roots.sst.

Установка/обновление корневых сертификатов

Полученный на предыдущем этапе файл переносим на компьютер, где необходимо обновить доверенные корневые сертификаты, например, также в папку C:CA. Скачиваем утилиту rootsupd и распаковываем ее в этот же каталог.

Открываем командную строку от администратора и вводим команду:

C:CArootsupd.exe /c /t:C:CA

* где C:CA — папка, в которую мы перенесли корневые сертификаты.

В появившемся окне Roots Update:

. выбираем No, чтобы не переписывать наш файл roots.sst.

В папке C:CA должны появится новые файлы, в том числе, утилита updroots. Вводим теперь команду:

Источник

Support for urgent Trusted Root updates for Windows Root Certificate Program in Windows

This article describes an update that enables urgent updates for the Windows Root Certificate Program in Windows 8.1, Windows RT 8.1, Windows Server 2012 R2, Windows 8, Windows RT, Windows Server 2012, Windows 7, and Windows Server 2008 R2. Before you apply this update, see more about this update and check out the prerequisites in this article.

About this update

The Windows Root Certificate Program enables trusted root certificates to be distributed automatically in Windows. Usually, a client computer polls root certificate updates one time a week. After you apply this update, the client computer can receive urgent root certificate updates within 24 hours.

Known issue

After you apply this update, you may encounter error 0x800706f7 when you run Windows Update.

Resolution
To resolve this issue, install update 3024777.

How to obtain this update

Method 1: Windows Update

This update is available from Windows Update.

Method 2: Microsoft Download Center

The following files are available for download from the Microsoft Download Center.

All supported x86-based versions of Windows 8.1

Download the package now.

All supported x64-based versions of Windows 8.1

Download the package now.

All supported x64-based versions of Windows Server 2012 R2

Download the package now.

All supported x86-based versions of Windows 8

Download the package now.

All supported x64-based versions of Windows 8

Download the package now.

All supported x64-based versions of Windows Server 2012

Download the package now.

All supported x86-based versions of Windows 7

Download the package now.

All supported x64-based versions of Windows 7

Download the package now.

All supported x64-based versions of Windows Server 2008 R2

Download the package now.

All supported IA-64-based versions of Windows Server 2008 R2

Download the package now.

The update installer should be run from an elevated command prompt.

The update for Windows RT 8.1 or Windows RT can be obtained only from Windows Update.

For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:

119591 How to obtain Microsoft support files from online services Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.

Method 3: Update rollup for Windows 8.1, Windows RT 8.1, Windows Server 2012 R2, Windows 8, Windows RT, or Windows Server 2012

Install one of the following update rollup packages that are dated December 2014:

Note The update rollup fixes many other issues in addition to the issue that the stand-alone update fixes. The update rollup is larger than the stand-alone update. Therefore, the update rollup takes longer to download.

Update information

Prerequisites

To install this update, you must install update 2919355 in Windows 8.1 or Windows Server 2012 R2. Or, install Service Pack 1 for Windows 7 or Windows Server 2008 R2.

Registry information

To apply this update, you do not have to make any changes to the registry.

Restart requirement

You may have to restart the computer after you apply this update.

Update replacement information

This update does not replace a previously released update.

More Information

For more information, see the following articles in the Microsoft Knowledge Base:

The global version of this update installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows 8.1 and Windows Server 2012 R2 file information and notes

The files that apply to a specific product, milestone (RTM, SP n), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are not listed.

For all supported x86-based versions of Windows 8.1

Источник

Обновление корневых сертификатов в Windows 10 / Windows Server 2016

В операционные системы семейства Windows встроена система автоматического обновления корневых сертификатов с сайта Microsoft. Компания MSFT в рамках программы корневых сертификатов Microsoft Trusted Root Certificate Program, ведет и публикует в своем онлайн хранилище список сертификатов для клиентов и устройств Windows. Если проверяемый сертификат в своей цепочке сертификации относится к корневому CA, который участвует в этой программе, система автоматически скачает с узла Windows Update и добавит такой корневой сертификат в доверенные.

ОС Windows запрашивает обновление корневых сертификатов (certificate trust lists — CTL) один раз в неделю. Если в Windows отсутствует прямой доступ к каталогу Windows Update, то система не сможет обновить корневые сертификаты, соответственно у пользователя могут быть проблемы с открытием сайтов (SSL сертификаты которых подписаны CA, к которому нет доверия, см. статью об ошибке в Chrome «Этот сайт не может обеспечить безопасное соединение«), либо с установкой запуском подписанных приложений или скриптов.

В этой статье попробуем разобраться, как можно вручную обновить список корневых сертификатов в TrustedRootCA в изолированных сетях, или компьютерах/серверах без прямого подключения к Интернету.

Управление корневыми сертификатами компьютера в Windows 10

Как посмотреть список корневых сертфикатов компьютера с Windows?

Вы также можете получить список доверенных корневых сертификатов со сроками действия с помощью PowerShell:

Get-Childitem cert:LocalMachineroot |format-list

Можно вывести список истекших сертификатов, или которые истекут в ближайшие 30 дней:

Get-ChildItem cert:LocalMachineroot | Where

В консоли mmc вы можете просмотреть информацию о любом сертификате или удалить его из доверенных.

Вы можете вручную перенести файл корневого сертификата с одного компьютера на другой через функцию Экспорта/Импорта.

Утилита rootsupd.exe

В Windows XP для обновления корневых сертификатов использовалась утилита rootsupd.exe. В этой утилита содержится список корневых и отозванных сертификатов, зашитых в которой регулярно обновлялся. Сама утилита распространялась в виде отдельного обновления KB931125 (Update for Root Certificates).

Но, как вы видите, дата создания этих файлов 4 апреля 2013 (почти за год до окончания официальной поддержки Windows XP). Таким образом, с этого времени утилита не обновлялась и не может быть использована для установки актуальных сертификатов. Однако нам чуть позже понадобится файл updroots.exe.

Certutil: получение корневых сертификатов через Windows Update

Утилита управления и работы с сертификатами Certutil (появилась в Windows 10), позволяет скачать с узлов Windows Update и сохранить в SST файл актуальный список корневых сертификатов.

Для генерации SST файла, на компьютере Windows 10 с доступом в Интернет, выполните с правами администратора команду:

В результате в целевом каталоге появится файл SST, содержащий актуальный список сертификатов. Дважды щелкните по нему для открытия. Данный файл представляет собой контейнер, содержащий доверенные корневые сертификаты.

В открывшейся mmc оснастке управления сертификатами вы можете экспортировать любой из полученных сертификатов. В моем случае, список сертификатов содержал 358 элемента. Естественно, экспортировать сертификаты и устанавливать по одному не рационально.

Также можно воспользоваться утилитой updroots.exe (она содержится в архиве rootsupd.exe, который мы распаковали в предыдущем разделе):

Запустите оснастку certmgr.msc и убедитесь, что все сертификаты были добавлены в хранилище Trusted Root Certification Authority.

Список корневых сертификатов в формате STL

Есть еще один способ получения списка сертификатов с сайта Microsoft. Для этого нужно скачать файл http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab (обновляется дважды в месяц).С помощью любого архиватора (или проводника Windows) распакуйте содержимое архива authrootstl.cab. Он содержит один файл authroot.stl.

Файл authroot.stl представляет собой контейнер со списком доверенных сертификатов в формате Certification Trust List.

Данный файл можно установить в системе с помощью контекстного меню файла STL (Install CTL).

Или с помощью утилиты certutil:

Также вы можете импортировать сертификаты из консоли управления сертификатами (Trust Root Certification Authorities –>Certificates -> All Tasks > Import).

Укажите путь к вашему STL файлу сертификатами.

После выполнения команды, в консоли управления сертификатами (certmgr.msc) в контейнере Trusted Root Certification Authorities (Доверенные корневые сертификаты) появится новый раздел с именем Certificate Trust List (Список доверия сертификатов).

Аналогичным образом можно скачать и установить список с отозванными сертификатами, которые были исключены из программы Root Certificate Program. для этого, скачайте файл disallowedcertstl.cab (http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab), распакуйте его и добавьте в раздел Untrusted Certificates командой:

Обновление корневых сертификатов в Windows с помощью GPO в изолированных средах

Если у вас возникла задача регулярного обновления корневых сертификатов в изолированном от Интернета домене Active Directory, есть несколько более сложная схема обновления локальных хранилищ сертификатов на компьютерах домена с помощью групповых политик. В изолированных сетях Windows вы можете настроить обновление корневых сертификатов на компьютерах пользователей несколькими способами.

Первый способ предполагает, что вы регулярно вручную скачиваете и копируете в вашу изолированную сеть файл с корневыми сертификатами, полученный так:

certutil.exe –generateSSTFromWU roots.sst

Второй способ предполагает получение актуальных корневых сертификатов с помощью команды:

В указанном сетевом каталоге появится ряд файлов корневых сертификатов (CRT) и в том числе файлы (authrootstl.cab, disallowedcertstl.cab, disallowedcert.sst, thumbprint.crt).

Action: Update
Hive: HKLM
Key path: SoftwareMicrosoftSystemCertificatesAuthRootAutoUpdate
Value name: RootDirURL
Type: REG_SZ
Value data: file://\dc01SYSVOLwinitpro.rurootcert

Осталось назначить эту политику на компьютеры и после обновления политик проверить появление новых корневых сертификатов в хранилище.

В этой статье мы рассмотрели несколько способов обновления корневых сертификатов на ОС Windows, изолированной от Интернета.

Источник

Ранее уже приходилось сталкиваться с проблемой невозможности корректного развёртывания ПО из-за того, что на целевых компьютерах с OC Windows не обновляется хранилище сертификатов доверенных корневых центров сертификации (далее для краткости будем называет это хранилище TrustedRootCA). На тот момент вопрос был снят с помощью развёртывания пакета rootsupd.exe, доступного в статье KB931125, которая относилась к ОС Windows XP. Теперь же эта ОС полностью снята с поддержки Microsoft, и возможно, поэтому данная KB-статья более недоступна на сайте Microsoft. Ко всему этому можно добавить то, что уже даже на тот момент времени решение с развёртыванием уже устаревшего в ту пору пакета сертификатов было не самым оптимальным, так как тогда в ходу были системы с ОС Windows Vista и Windows 7, в которых уже присутствовал новый механизм автоматического обновления хранилища сертификатов TrustedRootCA. Вот одна из старых статей о Windows Vista, описывающих некоторые аспекты работы такого механизма — Certificate Support and Resulting Internet Communication in Windows Vista. Недавно я снова столкнулся с исходной проблемой необходимости обновления хранилища сертификатов TrustedRootCA на некоторой массе клиентских компьютеров и серверов на базе Windows. Все эти компьютеры не имеют прямого доступа в Интернет и поэтому механизм автоматического обновления сертификатов не выполняет свою задачу так, как хотелось бы. Вариант с открытием всем компьютерам прямого доступа в Интернет, пускай даже на определённые адреса, изначально рассматривался как крайний, а поиски более приемлемого решения привел меня к статье Configure Trusted Roots and Disallowed Certificates (RU), которая сразу дала ответы на все мои вопросы. Ну и, в общем то, по мотивам этой статьи, в данной заметке я кратко изложу на конкретном примере то, каким образом можно централизованно перенастроить на компьютерах Windows Vista и выше этот самый механизм авто-обновления хранилища сертификатов TrustedRootCA, чтобы он использовал в качестве источника обновлений файловый ресурс или веб-сайт в локальной корпоративной сети.

Для начала, на что нужно обратить внимание, это на то, что в групповых политиках, применяемых к компьютерам, не должен быть задействован параметр блокирующий работу механизма авто-обновления. Это параметр Turn off Automatic Root Certificates Update в разделе Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings. Нам потребуется, чтобы этот параметр был Выключен, либо просто Не настроен.

Если взглянуть на хранилище сертификатов TrustedRootCA в разделе Локальный компьютер, то на системах, не имеющих прямого доступа в Интернет, набор сертификатов будет прямо так скажем небольшой:

В статье KB2677070 — Доступно автоматическое обновление отозванных сертификатов для систем Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2 можно найти актуальные на данный момент ссылки на файлы, прямой доступ к которым (минуя прокси с требованием аутентификации) может потребоваться для функций авто-обновления:

• http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab
• http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

Но вариант прямого доступа в рамках данной заметки мы больше упоминать не станем и рассмотрим пример локализации процесса обновления в соответствии с ранее упомянутой статьёй.

Первое, что нам нужно сделать, это рассмотреть варианты получения актуальных файлов набора корневых сертификатов для их дальнейшего распространения внутри локальной сети.

Попробуем на компьютере имеющем прямое подключение к Интернету выполнить команду генерации SST файла, который будет в себе содержать актуальный набор файлов корневых сертификатов. В данном случае на компьютере с Windows 10 выполняется команда, вызывающая входящую в базовый состав ОС утилиту Certutil, которая в свою очередь обращается к веб-узлу Microsoft и создаёт по указанному нами пути SST файл:

Certutil -generateSSTFromWU C:TempWURoots.sst

Полученный в результате выполнения команды SST-файл по сути является контейнером, который содержит в себе все сертификаты для нужного нам обновления системы. Этот контейнер легко открывается в Проводнике Windows загружая ассоциированную с расширением файла оснастку управления сертификатами.

Этот файл удобно использовать, например, когда из всего подмножества доступных сертификатов нужно выбрать лишь некоторый набор и выгрузить их в отдельный SST файл для дальнейшей загрузки, например, с помощью консоли управления локальными сертификатами или с помощью консоли управления групповыми политиками (для импорта в какую-либо доменную политику через параметр Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities).

Однако для интересующего нас способа распространения корневых сертификатов, с помощью модификации работы механизма авто-обновления на конечных клиентских компьютерах, нам потребуется несколько иное представление множества актуальных корневых сертификатов. Получить его можно с помощью всё той же утилиты Certutil, но уже с другим набором ключей.

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

Certutil -syncWithWU -f -f \FILE-SERVERSHARERootCAupdGPO-Deployment

Ключи -f -f используются для форсированного обновления всех файлов в каталоге назначения.

В результате выполнения команды в указанной нами сетевой папке появится множество файлов общим объемом примерно в пол мегабайта:

Согласно ранее упомянутой статьи, назначение файлов следующее:

• Файл authrootstl.cab содержит сторонние списки доверия сертификатов;
• Файл disallowedcertstl.cab содержит список доверия сертификатов с недоверенными сертификатами;
• Файл disallowedcert.sst содержит хранилище сериализованных сертификатов, включая недоверенные сертификаты;
• Файлы с именами типа thumbprint.crt содержат сторонние корневые сертификаты.

Итак, файлы необходимые для работы механизма авто-обновления получены, и мы теперь переходим к реализации изменения схемы работы этого самого механизма. Для этого, как всегда, нам на помощь приходят доменные групповые политики Active Directory (GPO), хотя можно использовать и другие инструменты централизованного управления, весь всё, что нам нужно сделать на всех компьютерах — это изменить, вернее добавить, всего один параметр реестра RootDirURL в ветке HKLMSoftwareMicrosoftSystemCertificatesAuthRootAutoUpdate, который и определит путь к нашему сетевому каталогу, в котором мы ранее разместили набор файлов корневых сертификатов.

Говоря о настройке GPO, для реализации поставленной задачи, опять же, можно использовать разные варианты. Например, есть «олд-скульный» вариант с созданием собственного шаблона групповой политики, так как это описано в уже знакомой нам статье. Для этого создадим файл в формате административного шаблона GPO (ADM), например, с именем RootCAUpdateLocalPath.adm и содержимым:

CLASS MACHINE
CATEGORY !!SystemCertificates
    KEYNAME "SoftwareMicrosoftSystemCertificatesAuthRootAutoUpdate"
    POLICY !!RootDirURL
       EXPLAIN !!RootDirURL_help
       PART !!RootDirURL EDITTEXT
             VALUENAME "RootDirURL"
       END PART
    END POLICY
END CATEGORY
[strings]
RootDirURL="URL address to be used instead of default ctldl.windowsupdate.com"
RootDirURL_help="Enter a FILE or HTTP URL to use as the download location of the CTL files."
SystemCertificates="Windows AutoUpdate Settings"

Скопируем этот файл на контроллер домена в каталог %SystemRoot%inf (как правило, это каталог C:Windowsinf). После этого перейдём в редактор доменных групповых политик и создадим отдельную новую политику, открыв затем её на редактирование. В разделе Computer Configuration > Administrative Templates… откроем контекстное меню и выберем пункт подключения нового шаблона политик Add/Remove Templates

В открывшееся окне с помощью кнопки обзора выберем ранее добавленный файл %SystemRoot%infRootCAUpdateLocalPath.adm, и после того, как шаблон появится в списке, нажмём Close.

После проделанного действия в разделе Configuration > Administrative Templates > Classic Administrative Templates (ADM) появится группа Windows AutoUpdate Settings, в которой будет доступен единственный параметр URL address to be used instead of default ctldl.windowsupdate.com

Откроем этот параметр и введём путь к локальному ресурсу, на котором мы расположили загруженные ранее файлы обновления, в формате http://server1/folder или file://\server1folder,
например file://\FILE-SERVERSHARERootCAupdGPO-Deployment

Сохраним проделанные изменения и применим созданную политику к доменному контейнеру, в котором расположены целевые компьютеры. Однако рассмотренный метод настройки GPO имеет ряд недостатков и именно поэтому я назвал его «олд-скульным».

Другой, более современный и более продвинутый метод настройки реестра клиентов  —  это использование Group Policy Preferences (GPP). При таком варианте мы можем создать соответствующий объект GPP в разделе групповой политики Computer Configuration > Preferences > Registry с обновлением параметра (Action: Update) реестра RootDirURL (тип значения REG_SZ) 

При необходимости можем для созданного параметра GPP включить гибкий механизм нацеливания (Закладка Common > Опция Item-level targeting) на конкретный компьютер или группу компьютеров для предварительного тестирования того, что у нас в конечном итоге получиться после применения групповых политик.

Разумеется, нужно выбрать какой-то один вариант, либо с подключением собственного ADM-шаблона, либо с использованием GPP.

После настройки групповых политик на любом подопытном клиентском компьютере выполним обновление командой gpupdate /force c последующей перезагрузкой. После загрузки системы проверим в реестре наличие созданного ключа и попробуем проверить наличие факта обновления хранилища корневых сертификатов. Для проверки воспользуемся простым но действенным примером описанным в заметке Trusted Roots and Disallowed Certificates.

Для примера посмотрим, есть ли в хранилище сертификатов компьютера корневой сертификат, использованный для выпуска сертификата, который установлен на сайте с именем buypass.no (но на сам сайт пока не переходим :)).

Сделать это удобнее всего с помощью средств PowerShell:

Get-ChildItem cert:localmachineroot | Where {$_.friendlyname -like "*Buypass*"}

С большой долей вероятности у нас не окажется такого корневого сертификата. Если так, то откроем Internet Explorer и обратимся к URL https://buypass.no. И если настроенный нами механизм автоматического обновления корневых сертификатов работает успешно, то в event-логе Windows Application при это появится событие c источником (Source) CAPI2, свидетельствующее об успешной загрузке нового корневого сертификата :

Имя журнала:   Application
Источник:      Microsoft-Windows-CAPI2
Дата:          04.08.2016 18:20:45
Код события:   4097
Категория задачи:Отсутствует
Уровень:       Сведения
Ключевые слова:Классический
Пользователь:  Н/Д
Компьютер:     KOM-WS306.holding.com
Описание:
Успешное автоматическое обновление стороннего корневого сертификата:: субъект:  < CN=Buypass Class 3 Root CA, O=Buypass AS-983163327, C=NO > ; отпечаток SHA1:  < DAFAF7FA6684EC068F1450BDC7C281A5BCA96457 > .

После этого мы можем снова выполнить указанную ранее команду запроса к хранилищу корневых сертификатов и увидим, что теперь в нём действительно появился новый корневой сертификат, именно тот который фигурировал в событии event-лога Windows:

Как видим, механизм авто-обновления работает и теперь всё, что остаётся, это организовать поддержку в актуальном состоянии файлов в сетевой папке, запланировав, например на ночное время, ежесуточное выполнение задания обновления ранее упомянутой командой:

Certutil -syncWithWU -f -f \FILE-SERVERSHARERootCAupdGPO-Deployment

На этом всё.

Дополнительные источники информации:

• TechNet Library — Configure Trusted Roots and Disallowed Certificates (RU)
• TechNet Wiki — Microsoft Trusted Root Certificate Program Updates
• adevis Blog — Trusted Roots and Disallowed Certificates