Automatically removing expired certificates from the CRL

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 certificate, it usually includes a signed timestamp as well, the idea being that parties verifying the signature can check when the signature was generated. If the code signing certificate was valid at the point in time where the code was signed, the signature remains valid even after the code signing certificate expires.

Therefore, if a code signing certificate has been revoked, that is relevant information for relying parties even after the certificate has expired. Using the timestamp in the signature, a relying party can determine whether the signature was generated before or after the certificate was revoked, and thus decide whether the signature is trustworthy or not. In order to enable this it is essential to ensure that revocation information for code signing certificates is available and accurate even after they expire.

AD CS provides another configuration setting to enables this, in the form of a list of EKU OIDs that, when present in a certificate, will prevent it from being removed from a CRL upon expiration,

The configuration setting is called EKUOIDsForPublishExpiredCertInCRL, and it defaults to a list containing 2 EKUs. To check its value via certutil:

certutil -getreg CA\EKUOIDsForPublishExpiredCertInCRL


So by default, certificates with Code Signing (1.3.6.1.5.5.7.3.3) or Kernel Mode Code Signing (1.3.6.1.4.1.311.61.1.1) EKUs will not be removed from the CRL if they are revoked, even after they expire.

The list of OIDs can be modified via certutil, adding EKUs to the list:

certutil -setreg CA\EKUOIDsForPublishExpiredCertInCRL +[OID]

or removing them from the list:

certutil -setreg CA\EKUOIDsForPublishExpiredCertInCRL -[OID]

As usual, configuration changes such as the ones mentioned above require AD CS to be restarted to take effect.


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