denetarik

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

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

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

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

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.