Posts

Updating the Windows Root CA store

Image
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  [DestinationDir
Post a Comment
Read more

Windows automatic Root CA updates

Image
Microsoft runs its own Trusted Root Program , defining which Root CAs are considered trusted in Microsoft products. The list of trusted Root CAs and/or the corresponding metadata is updated regularly (updates are published here and made available for download in the form of a Certificate Trust List (CTL) here . Windows systems can be configured to automatically update their list of trusted Root CAs, via " Automatic Root Certificates Update ", a setting that can be configured via policy: gpedit.msc > Local Computer Policy > Computer Configuration > System > Internet Communication Management > Internet Communication Settings > Turn off Automatic Root Certificates Update According to the description of the policy setting, having it disabled or not configured will trigger automatic updates via the Windows Update website. The policy editor, especially when it comes to policies not configured, is not always a trustworthy source, so in case of doubt check the corr
Post a Comment
Read more

Automatically removing expired certificates from the CRL

Image
By default, AD CS will automatically remove expired certificates from the CRLs it publishes. Once a certificate expires, whether it was revoked in the past or not is generally not relevant, since the certificate is not time valid anymore it should be rejected. This default behaviour can be modified via one of the CRL flags in the CA configuration, called  CRLF_PUBLISH_EXPIRED_CERT_CRLS . By default the flag is not set, meaning expired  revoked certificates will be removed from the CRL, but it can be set running: certutil -setreg CA\CRLFlags + CRLF_PUBLISH_EXPIRED_CERT_CRLS Once set, expired revoked certificates will remain in the subsequent CRLs even after expiring. To unset the flag simply run: certutil -setreg CA\CRLFlags - CRLF_PUBLISH_EXPIRED_CERT_CRLS There are some cases, though, where it is required to keep certain revoked certificates in the CRL even after those have expired. Classic example for this is code signing certificates: when code is signed using a code signing certifi
Post a Comment
Read more

Querying and deleting certificate requests from an AD CS database

Image
Certificate request information in an AD CS database is stored in 3 different tables  The glue between those 3 tables is the RequestID  in the Default table, that corresponds to the AttributeRequestID column in the Attrib table and the ExtensionRequestID column in the Ext table. Whenever a certutil -view command is issued, it will default to the Default table, querying the Attrib and Ext tables requires them to be specified, e.g.: certutil -view Attrib will dump the content of the Attrib table and certutil -view Ext will dump the content of the Ext table Remember that certutil [Options] , such as restrict and out , which can be used to filter the output of the queries above, must always be present before the -view command: certutil [Options] -view The default usage of certutil -view without specifying the table extracts data from the Default table, but it also includes the data contained in the Attrib and Ext tables, presenting it altogether in a convenient format. if we qu
Post a Comment
Read more

AD CS database CRL table

Image
The Microsoft AD CS database has a specific table for Certificate Revocation Lists (CRLs). By default, CRLs are kept in the database for some time after expiration and then they are deleted, so that the CRL table usually contains a reduced number of entries and does not grow as time goes by. This default behaviour can be controlled via one of the CRLFlags in the AD CS configuration, called  CRLF_DELETE_EXPIRED_CRLS . When the flag is set expired CRLs will regularly be deleted from the CRL table in the database, if the flag is unset CRLs will be kept in the database. To modify the flag the usual commands can be used. To set the flag (default after deployment): certutil -setreg CA\CRLFlags +CRLF_DELETE_EXPIRED_CRLS And to unset the flag: certutil -setreg CA\CRLFlags -CRLF_DELETE_EXPIRED_CRLS The AD CS service must be restarted for those configuration changes to take effect.
Post a Comment
Read more

Enable debug level for the AD CS Certification Authority

The error messages an AD CS Certification Authority displays are often not very useful. Errors, for instance, when trying to start the Certificate Services are sometimes generic and make troubleshooting difficult. One option to get additional information regarding the problem is to set the CA to debug level. This can be achieved running the following command: certutil -setreg ca\debug 0xffffffe3 When restarted, a debug log file is written to %windir%\certsrv.log , with its content being something like: ======================================================================== Opened Log: 21.11.2023 00:23 38.237s GMT + 1,00 certca.dll: 6.3:9600.17415 retail certsrv.exe: 6.3:9600.21062 retail 503.1945.0:<2023/11/21, 0:23:38>: 0x0 (WIN32: 0) 508.1341.0:<2023/11/21, 0:23:38>: 0x2 (WIN32: 2 ERROR_FILE_NOT_FOUND): DBMaxReadSessionCount 513.17174.0:<2023/11/21, 0:23:38>: 0x80070490 (WIN32: 1168 ERROR_NOT_FOUND): CAExchange 508.1734.0:<2023/11/21, 0:23:38>: 0x80070490 (W
Post a Comment
Read more

Java and the Windows certificate store

Image
Java includes its own Root CA trusted certificate store, regularly updated via its  Root Certificate Program  and implemented via its cacerts certificates file (by default under  $JAVA_HOME\lib\security ). In addition to its own trusted certificate store, it is also possible to configure clients to make Java trust the certificates present in a browser's certificate store (limited to Internet Explorer and Mozilla Firefox). This can be achieved via a setting within Control Panel > Java > Advanced > Advanced Security Settings called " Use certificates and keys in browser keystore ": The setting is enabled by default, and it is documented  here . According to its description, in particular on Windows platforms " On Windows, browser keystore is supported through Internet Explorer. Certificates and keys in Internet Explorer are automatically recognized by Java Plug-in and Java Web Start when Java and JavaFX applications are deployed on Windows ". Microsoft W
Post a Comment
Read more