Updating the Windows Root CA store

Windows Root CA certificate store is updated automatically, but there are cases where this is not desirable or possible.

In some cases, the Windows CTL Updater functionality might be disabled, e.g. to keep full control over the process on systems where this is a requirement, and in some other cases end systems might lack connectivity to the Microsoft endpoints providing the updates (although these can also be replaced by local endpoints if required).

In such cases, a mechanism to update the Windows Root CA store either on-demand or in an offline fashion might be required.

The certutil command allows for this, providing 2 useful parameters.

The -syncWithWU parameter allows for on-demand update of the Root CA store. This is useful when auto-update is disabled or when troubleshooting the auto-update process (e.g. if we have issues with some Root CA not being present or similar).

The certutil command to be run would be:

certutil -syncWithWU [DestinationDirectory]

Where [DestinationDirectory] will be used to store all downloaded assets. Since this triggers the same process triggered by the auto-update process:

  • It supports both default Microsoft update endpoints and, if configured, local custom update endpoints
  • It can be used to troubleshoot issues with the standard auto-update mechanism
NOTE: This command does not only trigger the update mechanism but as a negative side effect it also makes all the Root CAs "active" in the Windows Root CA certificate store, which will have a negative performance impact. After running the command, the client will have all the Root CAs visible in the certificate store (over 400 with the default Microsoft update mechanism) instead of the default reduced subset of Root CAs.

For example:

certutil -syncwithWU .\wusync\

(where wusync is a directory created to store the download)

A number of assets are downloaded as part of that, one of them being authrootstl.cab, from where authroot.stl can be extracted. We can verify it with:

certutil -verifyctl .\wusync\authroot.stl

and looking at the beginning of the output:

[AuthRootCTL]
SequenceNumber = 1401da11ba19606c20
ThisUpdate = "07.11.2023 21:36"
NextUpdate = EMPTY
SubjectAlgorithm = 1.3.14.3.2.26, "sha1"
  Extensions: 0
ERROR = "Strong signatures: 0"
SignerExpiration = "14.03.2024 19:04", "42,2 Days"
WARNING = "SignerExpiration: Less than 180 Days"
CTLEntries = 480
INFO = 1.3.6.1.4.1.311.10.11.9, "CERT_ENHKEY_USAGE_PROP_ID", "474 of 480 entries present"
INFO = 1.3.6.1.4.1.311.10.11.83, "CERT_ROOT_PROGRAM_CERT_POLICIES_PROP_ID", "164 of 480 entries present"
INFO = 1.3.6.1.4.1.311.10.11.104, "CERT_DISALLOWED_FILETIME_PROP_ID", "170 of 480 entries present"
INFO = 1.3.6.1.4.1.311.10.11.126, "CERT_NOT_BEFORE_FILETIME_PROP_ID", "265 of 480 entries present"
INFO = 1.3.6.1.4.1.311.10.11.127, "CERT_NOT_BEFORE_ENHKEY_USAGE_PROP_ID", "133 of 480 entries present"
INFO = 1.3.6.1.4.1.311.10.11.105, "CERT_ROOT_PROGRAM_CHAIN_POLICIES_PROP_ID", "8 of 480 entries present"
INFO = 1.3.6.1.4.1.311.10.11.122, "CERT_DISALLOWED_ENHKEY_USAGE_PROP_ID", "27 of 480 entries present"

The full output of the command above can be useful to troubleshoot issues with the update process.

If the goal is simply to add the trusted Root CAs to a system with no connectivity to any Windows Update servers, certutil also provides the means to download a copy of the trusted Root CAs so that they can then be copied over to the target system and added to it.
This can be achieved via the -generateSSTFromWU parameter. A certutil command can be run on a system with connectivity to the Microsoft endpoints:

certutil -generateSSTFromWU [DestinationFile]

Where [DestinationFile] is the file that will contain the output SST file (Serialised Certificate Store). In order to make it easy to inspect it and then import its content, the output file should have an .sst extension, so that Windows will recognise it (and open it simply by double-clicking on it).
The output .sst file can then be copied over to the system where the Root CA certificates need to be updated.
On the target system:
  • Open certmgr.msc (for user store) or certlm.msc (for Computer store, as Administrator) depending on the scope
  • Browse on the left panel and select "Trusted Root Certification Authorities"
  • Right click on it and select All Tasks > Import...

  • Select Next in the import wizard and browse to select the .sst file (enable .sst or "All files")
  • As target select "Place all certificates in the following store" and select "Trusted Root Certification Authorities" and Finish the wizard
Since these are Root CA certificates a confirmation dialogue will be displayed for each of them.
The target system would have then the latest Root CAs considered to be trusted by Microsoft. 




Comments

Post a Comment

Popular posts from this blog

Decoding OCSP GET requests

Many clients default to OCSP requests via HTTP GET, encoding the request details as part of the URL. These kind of requests can be found in the logs: http://ocsp.ekaitza.net/ocsp/MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ1uvBCJo3G3TPBvK%2BGVqszOaLAawQUb38ZjesMwNeYLEzdGvP%2FZi9TlkACE3cAEdYaIhMmuymSdxoAAAAR1ho%3D As per RFC 6960 , the request is constructed as: GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest} So in order to find out the details of the request we have to: 1. Remove the URL encoding This can be done with different tools, depending on the OS/platform being used.Given the input above: MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ1uvBCJo3G3TPBvK%2BGVqszOaLAawQUb38ZjesMwNeYLEzdGvP%2FZi9TlkACE3cAEdYaIhMmuymSdxoAAAAR1ho%3D the output would be: MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ1uvBCJo3G3TPBvK+GVqszOaLAawQUb38ZjesMwNeYLEzdGvP/Zi9TlkACE3cAEdYaIhMmuymSdxoAAAAR1ho= We can then create a text file with it, e.g.:  $ echo "MFQwUjBQME4wTDAJBgUrDgMCGgUABBQ1uvBCJo3G3TPBvK+GVqsz
Read more

Signing a CSR with an Enrollment Agent certificate

Image
Often certificate templates in AD CS are configured to require a set of authorised signatures for issuance: This is useful e.g. when issuance approval is delegated to a component outside of AD CS roles, such as some CA management or registration authority portal software. Combined with the template security settings this can prevent requests from being raised directly from the CA without going through a custom standard request process, and depending on the level of security required, multiple signatures can be enforced and optionally also additional CA certificate manager approval. In order to produce each of this signatures an "Enrollment Agent" certificate is used, a certificate with the "Certificate Request Agent (1.3.6.1.4.1.311.20.2.1)"  Enhanced Key Usage. Sometimes it is required to raise requests directly towards the CA, e.g. using the RPC/DCOM interface from the command line, but it is not desirable and/or possible to change the template configuration, so t
Read more

Compacting an AD CS database

Given the healthy trend towards decreasing certificate validity periods, it is very likely that the size of an AD CS Certification Authority database will grow following that same trend. Despite regular maintenance activities including deletion of records such as failed, denied etc. it could be that at some point the CA database reaches a problematic size. Deleting records from an AD CS CA database will internally free up the space previously occupied by those records but will not decrease the size of the database file itself. I.e. new records will reuse the freed up space but the total space used by the database file will not decrease. This helps keeping the database size under control but does not help if the size had already increased over acceptable limits; in this case the database must be compacted. The CA is often a critical resource, so it is recommended to keep various backups of different nature, to try to make sure we can recover it in case something goes wrong. Here a
Read more