По умолчанию, все операционные системы семейства 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 в изолированных сетях, или компьютерах/серверах без прямого подключения к Интернету.
Содержание:
- Управление корневыми сертификатами в Windows 10 и 11
- Включить/отключить автоматическое обновление корневых сертификатов в Windows
- Ручное обновление корневых сертификатов в Windows 10 и 11
- Список корневых сертификатов в формате STL
- Обновление корневых сертификатов в Windows с помощью GPO в изолированных средах
- Обновление корневых сертификатов в Windows 7
- Утилита rootsupd.exe для обновления сертификатов в Windows XP
Примечание. Если ваши компьютеры выходят в Интернет через прокси-сервер, для автоматического обновления корневых сертификатов Microsoft рекомендует открыть прямой доступ (bypass) к веб-узлам Microsoft. Но это не всегда возможно/применимо.
Управление корневыми сертификатами в Windows 10 и 11
Как посмотреть список корневых сертификатов на устройстве Windows?
- Чтобы открыть хранилище корневых сертификатов компьютера в Windows /Windows Server, запустите консоль
mmc.exe
; - Нажмите Файл (File) -> Добавить или удалить оснастку (Add/Remove Snap-in), в списке оснасток выберите Сертификаты (Certificates) -> Добавить (Add);
- В диалоговом окне выберите что вы хотите управлять сертификатами учетной записи компьютера (Computer account);
- Далее -> Ok -> Ok;
- Разверните Certificates (Сертификаты) -> Trusted Root Certification Authorities Store (Доверенные корневые сертификаты). В этом списке содержится список доверенных корневых сертификатов вашего компьютера.
Вы можете вывести список доверенных корневых сертификатов на вашем компьютере со сроками их действия с помощью PowerShell:
Get-Childitem cert:\LocalMachine\root |format-list
Можно вывести список истекших сертификатов, или которые истекут в ближайшие 30 дней:
Get-ChildItem cert:\LocalMachine\root| Where {$_.NotAfter -lt (Get-Date).AddDays(30)} |select NotAfter, Subject
В целях безопасности рекомендует периодически проверять хранилище доверенных сертификатов на наличие поддельных сертификатов с помощью утилиты Sigcheck. Утилита позволяет сравнить список сертификатов, установленных на компьютере со списком корневых сертификатов на сайте Microsoft (можно скачать офлайн файл с актуальными сертификатами authrootstl.cab).
Вы можете вручную перенести файл корневого сертификата с одного компьютера на другой с помощью функцию Экспорта/Импорта.
- Вы можете экспортировать любой сертификат .CER в файл, щелкнув по нему и выбрав “Все задачи” -> “Экспорт”;
- Затем с помощью команды Импорт можно импортировать этот сертификат на другом компьютере.
Включить/отключить автоматическое обновление корневых сертификатов в 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:\Software\Policies\Microsoft\SystemCertificates\AuthRoot' -Name DisableRootAutoUpdate
Если команда вернет, что значение ключа
DisableRootAutoUpdate=1
, значит на вашем компьютере отключено обновление корневых сертификатов. Чтобы включить его, измените значение параметра на 0.
Ручное обновление корневых сертификатов в Windows 10 и 11
Утилита управления и работы с сертификатами Certutil (появилась в Windows 10, для Windows 7 доступна в виде отдельного обновления), позволяет скачать с узлов Windows Update и сохранить в SST файл актуальный список корневых сертификатов.
Для генерации SST файла, на компьютере Windows 10/11 с доступом в Интернет, выполните с правами администратора команду:
certutil.exe -generateSSTFromWU c:\PS\roots.sst
Updated SST file. CertUtil: -generateSSTFromWU command completed successfully.
В результате в целевом каталоге появится файл SST, содержащий актуальный список сертификатов. Дважды щелкните по нему для открытия. Данный файл представляет собой контейнер, содержащий доверенные корневые сертификаты.
В указанном каталоге появится файл SST, содержащий актуальный список сертификатов. Данный файл представляет собой контейнер, содержащий доверенные корневые сертификаты. Дважды щелкните по нему.
В открывшейся
mmc
консоли вы можете экспортировать любой из полученных сертификатов. В моем случае, список сертификатов содержал 436 элементов. Естественно, экспортировать сертификаты и устанавливать по одному не рационально.
Для установки всех сертификатов из SST файла и добавления их в список корневых сертификатов компьютера можно воспользоваться командами PowerShell:
$sstStore = ( Get-ChildItem -Path C:\ps\rootsupd\roots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root
Запустите оснастку 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:\PS\authroot.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:\PS\disallowedcert.stl "
Обновление корневых сертификатов в Windows с помощью GPO в изолированных средах
Если у вас возникла задача регулярного обновления корневых сертификатов в изолированном от Интернета домене Active Directory, есть несколько более сложная схема обновления локальных хранилищ сертификатов на компьютерах домена с помощью групповых политик. В изолированных сетях Windows вы можете настроить обновление корневых сертификатов на компьютерах пользователей несколькими способами.
Первый способ предполагает, что вы регулярно вручную скачиваете и копируете в вашу изолированную сеть файл с корневыми сертификатами, полученный так:
certutil.exe –generateSSTFromWU roots.sst
Затем сертификаты из данного файла можно установить через SCCM или PowerShell логон скрипт в GPO:
$sstStore = ( Get-ChildItem -Path \\dc01\SYSVOL\winitpro.ru\rootcert\roots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root
Второй способ предполагает получение актуальных корневых сертификатов с помощью команды:
Certutil -syncWithWU -f \\dc01\SYSVOL\winitpro.ru\rootcert\
В указанном сетевом каталоге появится ряд файлов корневых сертификатов (CRT) и в том числе файлы (authrootstl.cab, disallowedcertstl.cab, disallowedcert.sst, thumbprint.crt).
Затем с помощью GPP нужно изменить значение параметра реестра RootDirURL в ветке HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate. Этот параметр должен указывать на сетевую папку, из которой клиентам нужно получать новые корневые сертификаты. Перейдите в секцию редактора GPO Computer Configuration -> Preferences -> Windows Settings -> Registry. И создайте новый параметр реестра со значениями:
Action: Update
Hive: HKLM
Key path: Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate
Value name: RootDirURL
Type: REG_SZ
Value data: file://\\dc01\SYSVOL\winitpro.ru\rootcert\
Осталось назначить эту политику на компьютеры и после обновления настроек 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.
После этого вы можете использовать утилиту certutil для генерации SST файла с сертификатами (на этом или на другом компьютере):
certutil.exe -generateSSTFromWU c:\ps\roots.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).
- Скачайте утилиту rootsupd.exe, перейдя по ссылке (по состоянию на 15.07.2019 ссылка не работает, возможно в Microsoft решили убрать ее из общего доступа. На данный момент вы можете скачать утилиту с сайта kaspersky.com — http://media.kaspersky.com/utilities/CorporateUtilities/rootsupd.zip);
- Для установки корневых сертификатов Windows, достаточно запустить файл rootsupd.exe. Но мы попробуем более внимательно рассмотреть его содержимое, распаковав его с помощью команды:
rootsupd.exe /c /t:C:\PS\rootsupd
- Сертификаты содержатся в 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, изолированных от Интернета.
A couple of days ago I had to deal with a situation where our vulnerability tool was complaining that the root certificate store wasn’t updated for a while. This process runs every 7 days, so it takes some time before you will notice any error messages, as was in my case. After doing some research it turned out that the update service for the Microsoft root certificate program was blocked. That in turn triggered me to dig into the more technical side of the Microsoft Root certificate program.
In short the Root Certificate Program makes the end user experience a better one. When you visit an https enabled website a check is done if you trust the root authority that handed out the certificate (or the intermediate ca for that matter). If that root certificate is not in the “Trusted Root Certification Authorities” container a list of known participants of the root certificate program is checked if that Root CA is listed. If it is, the certificate is automatically downloaded and stored in the “Trusted Root Certification Authorities” local certificate store. Although it sounds like a good plan, it can be a bit confusing. In my case I work in a disconnected environment. Read, not being able to connect to Windows update. In that case you can tell Windows to use an internal web of file server to host the certificate list. The process is exactly the same in that case, it just uses a different repository. The confusing part was when I noticed that the location wasn’t reachable however the root certificates where installed regardless. What kind of magic was at play her? Turns out that it isn’t magic after all. Already with the introduction of Windows Vista, long long time ago Microsoft embedded the current list of Root certificates in the crypt32.dll. So if the automatic root certificate process can’t reach Windows update, an internal web or file server, it extracts the certificate from crypt32.dll. It took a while before I figured that one.
Looking at the current Root Certificates
When you have a freshly installed machine, there are already a few basic root certificates installed. Windows needs these to make initial secure communication possible to it’s own servers to provide telemetry information, Windows Activation or Windows updates. To see the initial list use the following PowerShell command. The preview here was done on a Windows Server 2019 machine, so your output could be different depending on the OS version and the time it has been in use:
Get-Childitem cert:\LocalMachine\root | select FriendlynamePowerShell
Note! Don’t make the mistake to remove older root certificates, especially the ones using Authenticode for signing. When signing a binary (as an example), the root certificate must be valid at the time of signing. It doesn’t necessarily need to be valid after that time. If you put that Root Certificate in the Trusted Root Certificate store, the signing will be valid, even after the Root Certificate expires. Just for fun, use the following command to list the expired certificates, which still serve a valid purpose:
Get-ChildItem cert:\LocalMachine\root|Where {$_.NotAfter -lt (Get-Date).AddDays(30)}|select NotAfter, SubjectPowerShell
Certificate validity
As I wrote in the previous paragraph, certificates expire, but certificates can also be revoked, even Root Certificates. This could be because the organization that manages the Root Certificate was breached, but could also have a very different reason. Normally your Certificate Revocation List (CRL) will take care of that, but it’s always a good idea to do an additional check. As far as I know, Windows doesn’t have a build in tool to verify Root Certificates as I have always used the Sysinternal SigCheck tool for this purpose. Lets first get the tool, open a PowerShell Window and use the following to download the tool:
wget https://download.sysinternals.com/files/Sigcheck.zip -OutFile SigCheck.zip -UseBasicParsingPowerShell
Note! the “-UseBasicParsing” must be omitted when IE is no longer installed on the machine (Which it shouldn’t).
Unpack the zip file:
Expand-Archive .\SigCheck.zipPowerShell
CD into the SigCheck directory and execute the following command:
sigcheck64.exe -tv -accepteulaBAT (Batchfile)
If you have a up-to-date system, including your CRL the output should be similar as displayed below.
Manage your internal Root Certificate list
As I said, it’s entirely possible to manage your own Root Certificate list and not rely on the Dynamics of Windows Update. Use the following steps on your server to create an offline verion of the Certificates available on WIndows Update:
- Create a local folder and share it.
- Use: “Certutil -syncWithWU \” This will get all the appropriate data from Windows update site. Being:
- Authrootstl.cab, contains a non-Microsoft Certificate trust List (STL).
- Disallowedcertstl.cab, contains a STL with untrusted certificates.
- Disallowedcert.sst, contains a serialized certificate store (SST) for untrusted certificates.
- Pinrulesstl.cab, contains a STL of certificate pining rules (Windows 10 and higher).
- Pinrulesstl.sst, contains a serialized certificate store (SST) for Certificate pining.
- *.crt, all individual root certificate files.
Download the Root Certificate list in one single file
It can be beneficial to have all the certificate files available in one big file. It will become clear in the paragraph on managing the certificates. For now execute the following command to download the certificates in a *.sst (Serialized Certificate Store) format.
certutil.exe -generateSSTFromWU root.sstBAT (Batchfile)
Note! the name is not relevant and could be anything.
Updates for the Root Certificate List
To take control of the update process, it’s not just downloading the certificates and putting them on a share or webserver, it’s also necessary to disable the update process itself. To do so, you could take advantage of a group policy object or setting the key value pair in the registry directly. The policy is located at:
Computer Configuration -> Administrative Templates -> System -> Internet Communication Management -> Internet Communication -> Turn off Automatic Root Certificates Update
The registry key/value pair is located at:
HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate=[0|1]Windows Registry
Note! Setting this to 1 turns off the whole auto update mechanism for both trusted and untrusted certificates.
Note! There’s a second way of disabling this setting:
Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies -> Certificate Path Validation Settings -> Network Retrieval
Select: “Define these policy settings” and deselect “Automatically update…..”. Just don’t use both methods to avoid confusion.
Distributing the certificates
Now that we have all the available root certificates available, we need a way to distribute them. There are four ways that we could do that:
- Group Policy Object
- Active Directory Container
- File server
- Web server
Group Policy Object
In the GPO Editor, navigate to
Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Public Key Policies –> Trusted Root Certification Authorities
Use the import function to place the *.cer files in the appropriate GPO. As you might have noticed you can only select one file at once, which makes this a lengthy process. However when you have policies in place to allow only a certain number of certificates, this is the way to do it. Remember that, in the previous paragraph we downloaded all the certificates in one *.sst file? This is the moment to import it. In the “Certificate Import Wizard”, select the *.sst file when you browse the file system. Once all certificates are imported, do a multi-select on the files you don’t want to use, far easier than the other way around.
Active Directory Configuration Partition
When the granularity of Group Policy Targeting isn’t necessary, you could always publish the certificates directly to Active directory, much like you would do a publish of your own PKI root certificate.
certutil -dspublish -f <\filename>.crt RootCABAT (Batchfile)
Now, there isn’t a way that the *.sst file can be used with the dspublish parameter, so PowerShell to the rescue!
$certpath = "<path to the root certificate directory>"
$certificates = ( Get-ChildItem -Path $certpath -Filter "*.crt" )
foreach ($certificate in $certificates){
certutil.exe -dspublish -f ($certificate.FullName) RootCA
}PowerShell
Using AdsiEdit and navigating through the configuration partition, in the services node, we can locate the certificates in the “AIA” and “Certification Authorities” containers. On an end-node use gpupdate or wait for the group policy update cycle to process the root certificates.
File or webserver
When the previous methods aren’t a possibility there’s always a way to host the certificate files on a file or webserver. Store the certificate file on a share, for example in a sub directory of the SYSVOL share. Set the following registry key on your Client/Target point to your share:
HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\RootDirURL=file://\\<servername>\SYSVOL\\<domainname>\rootcert\Windows Registry
Note! This can also be an internal webserver location. These setting are effective immediately.
Certificate Trust List
A “CTL” (Certificate trust List) is in essence a file that contains the hash values of certificates that are normally stored in the Trusted Root container. It’s important to remember that this list does not contain all the attributes of the original certificate but can be used for certain cryptographic operations where only the hash needs to be compared, such as signing verification operations. For those of you that are a bit more familiar with Public Key Infrastructure (PKI), a Certificate Revocation List (CRL) is a similar list, it only contains the hash values of the certificate, not the entire binary file. The Windows operating system, per default downloads the CTL every two weeks when there’s an update to download. If you need to manually download the file, use the following url:
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
Or, if you also need to use the Certificate Revocation List for offline purposes, this is the url:
http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab
The unfortunate part of this is that although you can publish the truted stl list by using the “enterprise trust” in a GPO, I don’t know of a method to centrally distribute the disallowed certificate list. What is possible is using scripting around the following command:
certutil.exe -enterprise -f -v -AddStore disallowed <\path to disallowedcert.stl>BAT (Batchfile)
Hint! In case you want to manage the untrusted certificate list from Active Directory, use the disallowedcert.sst instead.
Note! to only turn off the updating of the Disallowed Certificate list, use the following registry key:
HKLM\Software\Policies\Microsoft\SystemCertificates\AuthRoot\EnableDisallowedCertAutoUpdate=0Windows Registry
Hint! To dump the entire certificate Trust list from your computer, use the following command:
certutil.exe -dump <\path\file.stl>BAT (Batchfile)
Troubleshooting
If you are experiencing issues with certificate, don’t worry, you’re not alone. Even with the most reliable systems, unexpected problems can arise. In this section, we’ll go over some common troubleshooting steps to help you diagnose and solve any issues you may encounter with the program. By following these steps, you can quickly get back on track and continue enjoying the benefits of a secure and trusted computing environment.
Clean the local downloaded cache
(Only with the Windows update download) locate the “CryptnetUrlCache” folder and delete the content. Usually in your user profile. (“%userprofile%\AppData\LocalLow\Microsoft\CryptnetUrlCache“)
Enable CryptoAPI 2.0 Diagnostics
Enable the Capi2 event log (located in the “Applications and Services Logs”) to get crypto operations logging.
Start a cryptographic operations
To initiate a crypto operation and see the automatic root certificate at work, browse to a HTTPS enabled website or open one of the certificates from the download mentioned above. Removing the certificate from the store and starting a crypto operation will reinitiate the process.
References
Configure Trusted Roots and Disallowed Certificates | Microsoft Learn
Обновлено:
Опубликовано:
Актуальные системы семейства Windows, подключенные к Интернету, могут автоматически обновлять корневые сертификаты. В противном случае, обновление необходимо выполнять вручную. Если это не делать, мы можем столкнуться с рядом проблем:
- Не открываются или выдают предупреждение безопасности некоторые (или все) сайты, работающие по https.
- Некорректная работа отдельных приложений (например, антивирусных систем).
- Ошибки при подключении по удаленному рабочему столу.
Это пример ошибок, который не претендует на свою полному. Чаще всего, проблемы встречаются на системах, снятых с обслуживания компанией Microsoft (Windows XP, 7, а также Server 2003, 2008).
Пакет обновлений Windows
Экспорт актуальных сертификатов
Импорт сертификатов
Решение возможных проблем
Обновление сертификатов
Обновление доверенных корневых сертификатов выполняется во время обновления операционной системы. Если последнее включено, то нашего участия не требуется, иначе, можно установить обновление вручную. Пример такого пакета — KB931125 (ссылка).
Однако, если операционная система устарела, разработчик прекращает выпуск обновлений, и мы не можем воспользоваться средствами обновления системы. В таком случае, необходимо сделать выгрузку корневых сертификатов на актуальной системе и перенести их на устаревший.
Получение актуальных сертификатов
Для начала, выгрузим сертификаты на компьютере с актуальной версией Windows (10) и подключением к сети Интернет.
Создадим каталог, в который будет выгружен файл с корневыми сертификатами, например, C:\CA (папка CA на диске C).
Открываем командную строку от администратора и вводим команду:
certutil.exe -generateSSTFromWU C:\CA\roots.sst
* где C:\CA — каталог, который мы создали; roots.sst — файл, в который будут выгружены сертификаты.
** если мы получили ошибку Не удается найти указанный файл. 0x80070002, то необходимо убедиться, что каталог CA создан (в нашем примере в корне диска С).
*** необхоидимо убедиться, что каталог, в который мы сохраняем файл roots.sst чистый (в нем нет данного файла).
В папке C:\CA мы должны увидеть файл roots.sst.
Установка/обновление корневых сертификатов
Полученный на предыдущем этапе файл переносим на компьютер, где необходимо обновить доверенные корневые сертификаты, например, также в папку C:\CA. Скачиваем утилиту rootsupd и распаковываем ее в этот же каталог.
Открываем командную строку от администратора и вводим команду:
C:\CA\rootsupd.exe /c /t:C:\CA
* где C:\CA — папка, в которую мы перенесли корневые сертификаты.
В появившемся окне Roots Update:
… выбираем No, чтобы не переписывать наш файл roots.sst.
В папке C:\CA должны появится новые файлы, в том числе, утилита updroots. Вводим теперь команду:
C:\CA\updroots.exe C:\CA\roots.sst
Готово.
Возможные ошибки
Рассмотрим некоторые ошибки, с которыми можно столкнуться.
1. Ошибка 0x5
При вводе команды updroots мы можем получить ошибку:
Error: Save encoded certificate to store failed => 0x5 (5)
Failed
Причина: утилита вносит изменения в систему и ей необходимы права. Данная ошибка, как правило, возникает при нехватке привилегий.
Решение: даже, если мы работает под учетной записью, входящей в группу администраторов, необходимо запускать командную строку от администратора. Для этого можно найти в поиске командную консоль, кликнуть по ней правой кнопкой мыши и выбрать запуск от администратора.
2. Ошибка 0x80070002
При попытке выгрузить корневые сертификаты с помощью команды certutil.exe -generateSSTFromWU мы можем получить ошибку:
Не удается найти указанный файл. 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND) — C:\CA\roots.sst
CertUtil: -generateSSTFromWU команда НЕ ВЫПОЛНЕНА: 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND)
CertUtil: Не удается найти указанный файл.
Причина: мы пытаемся выгрузить данные в каталог, которого не существует.
Решение: в нашем примере выгрузка идет в папку C:\CA. Значит нужно убедиться в наличие данного каталога и, при необходимости, создать его.
1. Introduction
The Microsoft Trusted Root Certificate Program (“Program”) supports the distribution of qualifying root certificates in Microsoft Windows and other Microsoft Products and Services. This page describes the Program’s general and technical requirements, including information about how a Certificate Authority (CA) can contact Microsoft to request inclusion into the Program.
This document lists the details and requirements for the Program. Certification Authorities («CAs») that are current members of the Program are listed at http://support.microsoft.com/kb/931125.
How Root Certificate Distribution Works
Starting with the release of Windows Vista, root certificates are updated on Windows automatically. When a user visits a secure Web site (by using HTTPS SSL), reads a secure email (S/MIME), or downloads an ActiveX control that is signed (code signing) and encounters a new root certificate, the Windows certificate chain verification software checks the appropriate Microsoft Update location for the root certificate. If it finds it, it downloads it to the system. To the user, the experience is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically, behind the scenes.
2. Certificate Authority Intake Process
In order to begin the process to be included in the Program, a CA must fill out the application located at http://aka.ms/rootcertapply and email the completed form to trustcert@microsoft.com. This will begin the onboarding process, outlined below:
- Microsoft will review the application, and may request additional documentation from the CA to determine if the CA meets the Program requirements and whether, in Microsoft’s judgment, the CA’s inclusion into the program will benefit Microsoft’s customers.
- Microsoft will provide preliminary Program approval to the CA and a deadline by which all materials must be completed and returned to Microsoft, for the CA to in included in the next release (typically every four months).
- Upon receipt of preliminary approval from Microsoft, the CA will need to engage an auditor to complete the necessary audit. See, http://aka.ms/auditreqs for more information about the Program’s audit requirements.
-
When the audit is complete, the CA must send the following materials to Microsoft:
- A copy of all of the roots that the CA wishes to have Microsoft include in the Program in .cer file format (contained in a .ZIP file)
- Test URLs for each root, or a URL of a publicly accessible server that Microsoft can use to verify the certificates.
- An electronic copy or URL that contains the most recent audit attestation for each of the roots the CA wishes to have Microsoft include in the Program
-
Information to complete and sign the Program contract, including:
- The name, email address, phone number, and job title of the person who will sign the Program contract
- A second contact’s name, email address, and phone number.
- The company’s principle place of business (street address).
- The company’s place of incorporation (country or state/province).
- Microsoft will send the Program contract to the CA to sign and return to Microsoft.
- Upon receipt of the completed contract, Microsoft will add the CA to the next release, if the CA has returned the materials by the deadline provided to the CA. Otherwise, Microsoft will add the CA’s roots to a subsequent release.
| Note |
|---|
|
Microsoft will determine at its sole discretion which CA certificates are included the Program. Microsoft will not charge any fee for including a CA’s certificates in the Program. Microsoft reserves the right to not include a CA in the Program for any reason or no reason at all, and such decisions are at Microsoft’s sole discretion. |
3. Continuing Program Requirements
All CAs in the Program must comply with these Continuing Program Requirements. If Microsoft determines that a CA is not in compliance with the below requirements, Microsoft may exclude the CA from the Program.
- The CA must provide to Microsoft evidence of a Qualified Audit (see http://aka.ms/auditreqs) for each root, non-limited sub-root, or cross-signed non-enrolled root, before conducting commercial operations and thereafter on an annual basis.
- The CA must assume sole responsibility for ensuring that all non-limited sub-roots and cross-signed, non-enrolled roots meet the Program Audit Requirements.
- The CA must provide Microsoft with updated Program contact information every July, November, and March, as well as upon Microsoft’s request. The CA must designate and disclose to Microsoft at least two contacts to be responsible to receive communications from Microsoft, including contact names, email addresses, and business and mobile phone numbers.
- The CA must disclose its full PKI hierarchy (non-limited sub-roots, cross-signed non-enrolled roots, intermediates, EKUs, certificate restrictions) to Microsoft on an annual basis, including certificates issued to CAs operated by external third parties. More about the depth of sub-CA (define as all below root)
- CAs must inform Microsoft at least 120 days before transferring ownership of an enrolled root to another entity or person, and obtain Microsoft’s written consent prior to transfer, which consent may be granted or denied in Microsoft’s sole discretion.
- CAs must agree to receive notices by e-mail and must provide Microsoft with an email address to receive official notices. If Microsoft sends an email that is undeliverable, Microsoft will send notices to the last-known address for the CA. CAs must agree that notice is effective when Microsoft sends the email or the letter.
- CAs must agree that Microsoft may contact the CA’s customers who Microsoft believes may be substantially impacted by Microsoft’s decision to remove a root from the Program.
- CAs may not enroll a root into the Program that is intended to be used internally within an organization (i.e. Enterprise CAs).
- CAs must publicly disclose all audit reports for non-limited sub-roots.
- If a CA uses a subcontractor to operate any aspect of its business, the CA must assume responsibility for the subcontractor’s business operations.
4. Program Technical Requirements
All CAs in the Program must comply with the Program Technical Requirements. If Microsoft determines that a CA is not in compliance with the below requirements, Microsoft may exclude the CA from the Program.
A. Root Requirements
-
Root certificates must be x.509 v3 certificates.
- The CN attribute must identify the publisher and must be unique.
- The CN attribute must be in a language that is appropriate for the CA’s market and readable by a typical customer in that market.
- Basic Constraints extension: must be cA=true.
-
Key Usage (if present) must be keyCertSign and cRLSign only.
- Root Key Sizes must meet the requirements detailed in “Key Requirements”.
- New roots must be valid for at least eight (8) years from the date of submission.
- Root certificates must expire no more than 25 years after the date of application for distribution.
- The CA may not issue new 1024-bit RSA certificates.
- All certificates issued from a root certificate must support either the CRL distribution point extension or AIA containing an OCSP responder URL
- Private Keys and subject names must be unique per root certificate; reuse of private keys or subject names in subsequent root certificates by the same CA may result in random certificate chaining issues. CAs must generate a new key and apply a new subject name when generating a new root certificate prior to distribution by Microsoft.
- All roots that are being used to issue new certificates, and which directly or transitively chain to a certificate included in the Program, must either be limited or be publicly disclosed and audited.
- Government CAs must restrict server authentication to .gov domains and may only issues other certificates to the ISO3166 country codes that the country has sovereign control over (see http://aka.ms/auditreqs section III for the definition of a “Government CA”).
- Government CAs that also operate as commercial, non-profit, or other publicly-issuing entities must use a different root for all such certificate issuances (see http://aka.ms/auditreqs section III for the definition of a “Commercial CA”).
- Intermediate CA certificates must meet the requirements for algorithm type and key size for Subordinate CA certificates listed in Appendix A of the CAB Forum Baseline Requirements, which can be found at https://www.cabforum.org.
- Intermediate CA certificates under root certificates submitted for distribution by the Program must separate Server Authentication Code Signing and Time Stamping uses. This means that a single issuing CA must not be used to issue both server authentication and code signing certificates. A separate CA must be used for each use case.
- Rollover root certificates, or certificates which are intended to replace previously enrolled but expired certificates, will not be accepted if they combine server authentication with code signing uses unless the uses are separated by application of Extended Key Uses (“EKU”s) at the intermediate CA certificate level that are reflected in the whole certificate chain.
- End-entity certificates must meet the requirements for algorithm type and key size for Subscriber certificates listed in Appendix A of the CAB Forum Baseline Requirements.
-
For Server Authentication certificates, Windows will stop trusting SHA1 certificates on 1 January 2017. This means any SHA1 SSL certificates issued before or after this announcement must be replaced with a SHA2 equivalent by January 1, 2017.
Note Microsoft will not require CAs to replace SHA1 Server Authentication certificates but will no longer trust SHA1 certificates after January 1, 2017. - CAs must use the following OIDs in the end-entity certificate: DV 2.23.140.1.2.1; OV 2.23.140.1.2.2; EV 2.23.140.1.1.; IV 2.23.140.1.2.3; EV Code Signing 2.23.140.1.3; Non-EV Code Signing 2.23.140.1.4.
- End-entity certificates that include a Basic Constraints extension in accordance with IETF RFC 5280 must have the cA field set to FALSE and the pathLenConstraint field must be absent.
B. Key Requirements
| Algorithm | All Uses Except for Code Signing and Time Stamping | Code Signing and Time Stamping Use |
|---|---|---|
|
Digest Algorithms |
SHA1 (may submit until January 1, 2016) SHA2 (SHA256, SHA384, SHA512) |
SHA1 (may submit until January 1, 2016) SHA2 (SHA256, SHA384, SHA512) |
|
RSA |
2048 |
4096 (New roots only) |
|
ECC / ECDSA |
NIST P-256, P-384, P-521 |
NIST P-256, P-384, P-521 |
C. Revocation Requirements
- The CA must have a documented revocation policy and must have the ability to revoke any certificate it issues.
- [Deleted July 2015.]
-
CAs that issue Server Authentication certificates must support the following OCSP responder requirements:
- Minimum validity of 1 day; Maximum validity of 1 week; and
- The next update must be available at an interval of ½ of the validity period. For example, if the maximum validity is 48 hours the next update must be available 24 hours before the current item expires.
- All certificates issued from a root certificate must support either the CRL distribution point and/or AIA containing an OCSP responder URL.
- The CA must not use the root certificate to issue end-entity certificates.
- The CA must operate their own Time Stamp Authority. The Time Stamp Authority must comply with RFC 3161, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).”
D. Code Signing Root Certificate Requirements
- In order to qualify for the code signing EKU, new root certificates submitted for distribution by the Program must be separate Server Authentication from Code Signing and Time Stamping uses at the intermediate certificate level.
- New code signing root certificates must support the SHA2 hash algorithm.
- Root certificates that support code signing use will be removed from distribution by the Program 10 years from the date of distribution of a replacement rollover root certificate, or a shorter deadline on request of the CA.
- Root certificates that remain in distribution to support only code signing use beyond their algorithm security lifetime (e.g. RSA 1024 = 2014, RSA 2048 = 2030) will be limited to code signing use only.
-
Root certificates will be removed from distribution by the Program without regard to any unexpired end entity certificates issued from them, according to the following deadlines:
- Server Authentication certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. Windows will no longer trust certificates signed with SHA-1 after January 1, 2017.
- Code signing certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Windows Server 2008 CAs will be allowed to continue issuing SHA-1 certificates.
- Time-stamping certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Windows Server 2008, CAs will be allowed to continue issuing SHA-1 certificates. Windows will not enforce a policy on time-stamping certificates.
- OCSP signatures: Microsoft requires CAs to start issuing new OCSP signatures using only the SHA-2 algorithm after January 1, 2016. Windows will no longer trust OCSP responses that use SHA-1 for their signature if the corresponding certificate had the Must Staple extension after January 1, 2016
- Time-stamp signature hashes: CAs must start issuing new time-stamp signature hashes using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Server 2008, CAs will be allowed to continue issuing SHA-1 time-stamps.
E. EKU Requirements
- CAs must provide a business justification for all of the EKUs assigned to their root certificate. Justification may be in the form of public evidence of a current business of issuing certificates of a type or types, or a business plan demonstrating an intention to issue those certificates in the near term (within one year of root certificate distribution by the Program).
-
Microsoft will only enable the following EKUs:
- Server Authentication =1.3.6.1.5.5.7.3.1
- Client Authentication =1.3.6.1.5.5.7.3.2
- Secure E-mail EKU=1.3.6.1.5.5.7.3.4
- Code Signing EKU=1.3.6.1.5.5.7.3.3
- Time stamping EKU=1.3.6.1.5.5.7.3.8
- Encrypting File System EKU=1.3.6.1.4.1.311.10.3.4
- Document Signing EKU=1.3.6.1.4.1.311.10.3.12
F. Windows 10 Kernel Mode Code Signing (KMCS) Requirements
Windows 10 has additional requirements to validate kernel-mode drivers, which are appropriately signed by Microsoft and a CA. CAs who wish to become authorized for kernel mode code signing must complete the steps below.
- The CA must send an email to trustcert@microsoft.com with:
-
Microsoft will evaluate whether the CA complies with all of the Program’s requirements.
- A zipped copy of the .cer file of the root that the CA will use kernel-mode code signing; and
- The policy OID that the CA will use to identify kernel-mode code signing.
- Microsoft will evaluate whether the CA complies with all of the kernel mode code signing requirements.
- Microsoft will send the CA the appropriate contract materials.
- Upon receipt of the signed contract materials, Microsoft will add the CA to the list of authorized kernel-mode code signing participants.
5. Technical Best Practices
Though not required by Microsoft, the following represents what Microsoft believes to be the best practices that each CA should follow.
- Microsoft recommends that each CA have an established communication channel to its customers. For example, if Microsoft were to notify the CA that Microsoft was disabling weak file hashes, the CA should have a method to notify its customers to use the updated signtool.exe file.
- Because root certificates will be removed without regard to any unexpired end entity certificates issued from them, the CAs should plan to cease issuing end entity certificates for uses besides code signing such that those certificates expire according to these root removal guidelines.
- While Windows will not enforce specific policies on Secure Email certificates, Microsoft recommends that CAs start issuing new Secure Email certificates using the SHA-2 algorithm.
6. Security Incident Response Requirements
A. Definitions
- “A compromise” means a direct or indirect incident, affecting either the CA or any of the CA’s sub-roots ooor cross-signed, non-enrolled roots, that results in an actual or potential degradation of the security stature of the PKI, which includes hardware, software, or physical building issues.
-
“Security Incident” or “Incident” means any of the following that occur at the CA or a sub-CA:
- A Private Key compromise.
- A mis-issued certificate.
- A known or reasonably knowable, publicly reported compromise.
- Any physical compromise of the CAs infrastructure (e.g. physical access control failure, building compromise, or a failure of the HVAC in the data center).
- Any other issue that Microsoft identifies as calling into question the CA’s integrity or trustworthiness.
- “Exceptional Circumstance(s)” means an Incident(s) the causes Microsoft to reasonably believe that the PKI is compromised; and such Incident affects the security posture of a large number of Microsoft’s customers.
B. Microsoft’s Rights in the Event of an Incident
In the event of a Security Incident, Microsoft may at its sole discretion, do any of the following:
- In an Exceptional Circumstance, immediately revoke any certificate the CA or any sub-CA has enrolled in the Program, otherwise it may revoke any certificate after providing 7 days’ advance notice to the CA.
- Microsoft may take action including, but not limited to marking files signed by compromised certificates as malware, blocking web navigation to sites served with compromised Server Authentication certificates, preventing delivery of mail signed by compromised Secure Email certificates, etc.
- Request that the CA make specific reports at a periodic interval to be determined by Microsoft.
- Specify a due date for the CA to submit to Microsoft a final Security Incident report.
- Communicate with affected third parties.
- Require the CA to employ, at the CA’s expense, a third-party investigator to investigate the Security Incident and prepare the final Security Incident report.
- Disqualify any Qualifying Audit and require the CA to perform a new Qualifying Audit at the CA’s sole expense.
C. Microsoft’s Responsibilities in the Event of a Security Incident
In the event that Microsoft exercises any of the rights described above, Microsoft will:
- Notify the CA, in writing, of its intentions 7 days prior to Microsoft’s action, except under Exceptional Circumstances, in which case Microsoft will make reasonable efforts to communicate with the CA prior to taking action; and
- Allow the CA to propose an alternate course of action, in which case, Microsoft will consider reasonable alternatives but reserves the right to reject such proposals if it deems the proposed course of action not to be in its customers’ best interest.
D. CA Responsibilities in the Event of an Incident
In the event of a Security Incident, the CA must:
-
Notify Microsoft as soon as is practical but no later than 24 hours from the time of the Security Incident by (a) completing the form located at http://aka.ms/rootnotify, and (b) sending the completed form to rootnotify@microsoft.com. The form requires the following information (if known at the time):
- Who detected the Incident.
- If available, the identity of the perpetrator(s) whose actions caused the Incident.
- When the CA discovered the Incident.
- Where the Incident occurred.
- The Roots and, if requested by Microsoft, end-user certificates that were affected by the Incident, if any.
- The sub-CAs that were affected by the Incident, if any.
- What the CA believes to be the underlying cause of the Incident.
- What remedial measures the CA has taken or will take that the CA believes will address the underlying cause of the Incident.
- Any other information the CA believes to be appropriate.
- Any other information requested by Microsoft when it responded to the initial notification.
- At Microsoft’s request, the CA must provide a list of all certificates that were mis-issued as a result of the Incident.
- At Microsoft’s request, the CA must provide Microsoft with periodic reports at an interval specified by Microsoft. If Microsoft does not make a specific request within 24 hours of an initial notification, the CA must provide reports to Microsoft as it discovers any new information.
-
The CA must provide a final Security Incident report to Microsoft that includes:
- A list of certificates and domains involved in the Incident.
- How did the CA detect the Incident? If the CA did not detect the Incident, who did and why did the CA not detect it?
- If the CA has reported conflicting information, why?
- Detailed description of the Incident.
- Details about what infrastructure was compromised.
- Details about how the infrastructure was compromised.
- A detailed timeline of events.
- The CA’s interpretation of who perpetrated the Incident.
- Log files (appendix only).
- Was the Incident detected by the CAs normal operation? If it was not, the CA must explain why.
- If the Incident involved vulnerability, was the vulnerability discovered in the most-recent audit? If yes, then provide information explaining how the vulnerability was remediated. If the vulnerability was not remediated, the CA must provide information about the reason for not doing so.
- What changes to the CP/CPS policies will the CA make?
- Detailed description of how the Incident was closed.
- If requested by Microsoft, a complete investigative and technical report of the compromise.
See Also
Ранее уже приходилось сталкиваться с проблемой невозможности корректного развёртывания ПО из-за того, что на целевых компьютерах с 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:\Temp\WURoots.sst
Полученный в результате выполнения команды SST-файл по сути является контейнером, который содержит в себе все сертификаты для нужного нам обновления системы. Этот контейнер легко открывается в Проводнике Windows загружая ассоциированную с расширением файла оснастку управления сертификатами.
Этот файл удобно использовать, например, когда из всего подмножества доступных сертификатов нужно выбрать лишь некоторый набор и выгрузить их в отдельный SST файл для дальнейшей загрузки, например, с помощью консоли управления локальными сертификатами или с помощью консоли управления групповыми политиками (для импорта в какую-либо доменную политику через параметр Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities).
Однако для интересующего нас способа распространения корневых сертификатов, с помощью модификации работы механизма авто-обновления на конечных клиентских компьютерах, нам потребуется несколько иное представление множества актуальных корневых сертификатов. Получить его можно с помощью всё той же утилиты Certutil, но уже с другим набором ключей.
В нашем примере в качестве локального источника распространения будет использована общая сетевая папка на файловом сервере. И здесь важно обратить внимание на то, что при подготовке такой папки обязательно нужно ограничивать доступ на запись, чтобы не получилось так, что любой желающий сможет модифицировать набор корневых сертификатов, которые потом будут «разливаться» по множеству компьютеров.
Certutil -syncWithWU -f -f \\FILE-SERVER\SHARE\RootCAupd\GPO-Deployment\
Ключи -f -f используются для форсированного обновления всех файлов в каталоге назначения.
В результате выполнения команды в указанной нами сетевой папке появится множество файлов общим объемом примерно в пол мегабайта:
Согласно ранее упомянутой статьи, назначение файлов следующее:
- Файл authrootstl.cab содержит сторонние списки доверия сертификатов;
- Файл disallowedcertstl.cab содержит список доверия сертификатов с недоверенными сертификатами;
- Файл disallowedcert.sst содержит хранилище сериализованных сертификатов, включая недоверенные сертификаты;
- Файлы с именами типа thumbprint.crt содержат сторонние корневые сертификаты.
Итак, файлы необходимые для работы механизма авто-обновления получены, и мы теперь переходим к реализации изменения схемы работы этого самого механизма. Для этого, как всегда, нам на помощь приходят доменные групповые политики Active Directory (GPO), хотя можно использовать и другие инструменты централизованного управления, весь всё, что нам нужно сделать на всех компьютерах — это изменить, вернее добавить, всего один параметр реестра RootDirURL в ветке HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate, который и определит путь к нашему сетевому каталогу, в котором мы ранее разместили набор файлов корневых сертификатов.
Говоря о настройке GPO, для реализации поставленной задачи, опять же, можно использовать разные варианты. Например, есть «олд-скульный» вариант с созданием собственного шаблона групповой политики, так как это описано в уже знакомой нам статье. Для этого создадим файл в формате административного шаблона GPO (ADM), например, с именем RootCAUpdateLocalPath.adm и содержимым:
CLASS MACHINE
CATEGORY !!SystemCertificates
KEYNAME "Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate"
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:\Windows\inf). После этого перейдём в редактор доменных групповых политик и создадим отдельную новую политику, открыв затем её на редактирование. В разделе Computer Configuration > Administrative Templates… откроем контекстное меню и выберем пункт подключения нового шаблона политик Add/Remove Templates
В открывшееся окне с помощью кнопки обзора выберем ранее добавленный файл %SystemRoot%\inf\RootCAUpdateLocalPath.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://\\server1\folder,
например file://\\FILE-SERVER\SHARE\RootCAupd\GPO-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:\localmachine\root | 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-SERVER\SHARE\RootCAupd\GPO-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