When installing a subordinate certificate authority, you may encounter the following behavior:
- One requests a Key Usage extension that is marked as critical, for example, or does not include DigitalSignature.
- However, the certificate issued by the parent certificate authority includes DigitalSignature, and the Key Usage extension is marked as non-critical.
- The parent certification authority is a standalone certification authority, i.e. without Active Directory integration.
Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the Application of regulationsto realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.
The requested Key Usage extension can be displayed during a certificate request with the following command line command:
certutil -dump {certificate request}.req
However, it appears that the requirements are ignored by the standalone Certification Authority.
One reason for wanting to see the described features in the Key Usage extension is that the Common PKI (also known as ISIS-MTT) Certificate profile.
RFC5280, which is relevant to PKI, also recommends that the Key Usage extension be marked as critical:
When present, conforming CAs SHOULD mark this extension as critical.
But why does the Certification Authority ignore the information in the certificate request? Let's first take a look at the request before it is issued by the certification authority. To do this, we click in the Certification Authority Management Console under Pending Requests at All Tasks – View Attributes/Extensions...
In the Extensions tab, we see that the Key Usage extension is not taken from the certificate request at all, but is specified by the Policy module.
With an Active Directory-integrated certificate authority, the settings from the respective certificate templates are used. However, this is not possible with a standalone certification authority due to the lack of certificate templates.
For a standalone certificate authority, when the policy module detects that the request is for a certificate authority certificate, the following bits are enforced for the key usage extension:
- CERT_DIGITAL_SIGNATURE_KEY_USAGE (0x80)
- CERT_KEY_CERT_SIGN_KEY_USAGE (0x04)
- CERT_CRL_SIGN_KEY_USAGE (0x02)
In addition, the Key Usage extension is marked as non-critical.
Responsible for this behavior is the flag EDITF_ADDOLDKEYUSAGE. You can find out if it is set with the following command line command:
certutil -v -getreg Policy\EditFlags
If you want to prevent the described behavior, you can do this with the following command line command.
certutil -setreg Policy\EditFlags -EDITF_ADDOLDKEYUSAGE
The certification authority service must then be restarted for the change to take effect. After that, the certificate request can be resubmitted and should now be issued correctly.
After the change, the Key Usage extension is still set by the Policy module, but now the settings from the certificate request are passed through.
Here is an example of a critical key usage extension without DigitalSignature:
Here is an example of a not-critical Key Usage Extension with DigitalSignature:
Related links:
External sources
- How to make a stand-alone certification authority that is running Windows Server 2003 with Service Pack 1 or an x64-based version of Windows Server 2003 compliant with ISIS-MTT version 1.1 (Microsoft, archive.org)
- Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
- Common PKI (Wikipedia)