The key algorithm of certificate requests is not checked by the certification authority's policy module

Assume the following scenario:

• A certificate template is configured to use elliptic curve based keys (e.g. ECDSA_P256).
• As a result, a minimum key length of 256 bits is configured.
• Nevertheless, certificate requests that use other ECC curves or RSA-based keys are also signed.

One way to identify the key algorithm when issuing a certificate and enforce its correct use is with the TameMyCerts Policy Module for Microsoft Certification Authority given.

As you can see, the "Algorithm Name" is set to ECDSA_P256, so you should expect that only certificate requests using exactly this key algorithm will be accepted.

Behavior review

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.

To test the behavior quickly and clearly, the PSCertificateEnrollment PowerShell Module an.

Install modules PSCertificateEnrollment
Import modules PSCertificateEnrollment

The following command creates a total of seven certificate requests and sends them to the certification authority using the "ADCS Lab WebServer ECC" certificate template.

You use the following parameters:

• Key algorithm ECDSA_P256
• Key algorithm ECDSA_P384
• Key algorithm ECDSA_P521
• Key algorithm ECDH_P256
• Key algorithm ECDH_P384
• Key algorithm ECDH_P521
• Key algorithm RSA (with key size 2048 bit)

(
"ECDSA_P256",
"ECDSA_P384",
"ECDSA_P521",
"ECDH_P256",
"ECDH_P384",
"ECDH_P521",
"RSA"
) | ForEach-Object -Process {
 New-CertificateRequest -Subject "CN=test" -KeyAlgorithm $_ |
  Get-IssuedCertificate `
   -ConfigString "ca02.intra.adcslabor.de\ADCS Lab Issuing CA 1" `
   -CertificateTemplate "ADCSLaborWebServerECC" `
    Select-Object -Property Result
}

As can be seen, all certificate requests are issued by the certification authority without complaint. Thus, a check of the key algorithm used by the certification authority's policy module does not take place.

So the key algorithm is rather (analogous to the Exportability of the private key) should be understood as the default for certificate requests via the Microsoft Management Console (MMC) or AutoEnrollment of clients in an Active Directory forest. However, the default does not apply to manually generated certificate requests, such as those common in the web server case.

Conclusion

A positive aspect of this behavior is that (in the case of certificate requests made away from AutoEnrollment) one may only need a single certificate template for issuing certificates that can use both RSA and ECC keys. It is then sufficient to reduce the key size.

However, this is only possible if all the key algorithms used have the same signature and encryption capabilities as the one configured in the certificate template (ECDSA, for example, can only be used for signing). The key usage extension of the issued certificates adapts to the capabilities of the configured key storage provider.

On the other hand, however, this also means that unwanted misissuances can occur, for example if certificate requests are signed with RSA key sizes that are too small or the wrong key algorithms are requested (for example, ECDH keys for signature certificates).

This can occur in particular when certificate requests are made via the Microsoft Management Console (MMS), as the default settings are selected here.

A corresponding check must therefore be performed upstream. It also makes sense to configure the default setting for the key algorithm to an algorithm based on elliptic curves so that RSA keys with key lengths that are too short are not accidentally signed.