Basics: key algorithms, signature algorithms and signature hash algorithms

When planning a public key infrastructure, the question arises as to which cryptographic algorithms it should use.

The main principles are explained below.

The consideration of cryptographic procedures and their evaluation with regard to their usability can only ever be a snapshot at the time of publication of the article. The evaluation may well be outdated in the future, e.g., due to security incidents or technical progress.

Key algorithm

The key algorithm refers to the algorithm used to generate the cryptographic key pair of the certificate.

The Active Directory certificate services support the following algorithms and bit lengths since Windows Server 2008:

Key algorithmNotes
RSAFreely selectable bit length (in 64 bit steps).
However, key lengths below 3000 bits should not be used nowadays.
See also article "What key lengths should be used for certificate authorities and certificates?„.
ECDSA_P256 / ECDH_P256256-bit key length (nistp256). Part of the NSA Suite B.
ECDSA_P384 / ECDH_P384 384 bit key length (nistp384). Part of the NSA Suite B.
ECDSA_P521 / ECDH_P521521 bit key length (nistp521). Not Part of the NSA Suite B.
(for the rest, it is a matter of 521 Bit not about a typo)

The use of elliptic curves for certificates does not make them "better" or "more secure" than RSA. The decisive factor in terms of cryptographic strength in both cases is the bit length or the enstrpechanting resilience against brute force attacks compared to the bit length of symmetric keys.

Another argument in favor of using RSA is the very good compatibility in the area of end devices.

Cryptography with elliptic curves has the advantage that it is very efficient (especially for larger key sizes) in terms of the computing power required. It is therefore particularly suitable for embedded systems that do not have a large computing capacity.

Meanwhile, the National Security Agency (NSA) recommends against making major investments to convert existing PKIs to elliptic curves due to the approaching standardization for quantum-resistant algorithms. See related article "Basics: Elliptic curves with regard to their use in the public key infrastructure„.

Signature hash algorithm

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 and is available under a free license. It can downloaded via GitHub and can be used free of charge.

The signature hash algorithm is the algorithm used to generate the certificate's checksum to determine its authenticity. It is then encrypted with the private key of the certification authority using the signature algorithm.

Subscribers verifying the certificate use the same algorithm to replicate the checksum and match it with the signature of the certification authority (see also article "Cryptography basics„).

MD5Classified as unsafe, should no longer be used. Working attacks on PKI are known.
SHA1Classified as insecure, should no longer be used. However, no functioning attacks on PKI are currently known.
Default setting until Windows Server 2012 for CA new installations
SHA256Default setting since Windows Server 2016 for new CA installations
Part of the NSA Suite B.
SHA384Part of the NSA Suite B.
SHA512Not Part of the NSA Suite B.

Signature algorithm

The signature algorithm describes the method by which the checksum calculated by the signature hash algorithm was signed by the certification authority using its private key. The verifying side must use the same algorithm to decrypt and verify the checksum using the public key.

The padding scheme used is of particular interest here. The PKCS#1 standard, which is implemented in two versions, is used for this:

  • PKCS#1 Version 1.5 (RFC 2313) is the default setting for Active Directory Certificate Services.
  • PKCS#1 Version 2.1 (RFC 3447) was adopted in 2003, partly due to a security vulnerability found in 1998 (Bleichenbacher), and since Windows Server 2008 it has been implemented with the directive AlternateSignatureAlgorithm supported.

Even though the previous description clearly speaks for the use of PKCS#1 2.1, there is one decisive argument against it: Compatibility. Some manufacturers, such as Cisco, have not implemented version 2.1 in their products, or have not implemented it consistently, so that certificates signed with PKCS#1 2.1 cannot be used with their products. In practice, it usually boils down to continuing to use version 1.5 for compatibility reasons.

However, according to current knowledge, the attack described by Bleichenbacher does not work against certificates anyway, but rather targets TLS connections, so there should be no disadvantage here.

The AlternateSignatureAlgorithm directive is configured as follows:

  • AlternateSignatureAlgorithm = 0 (or omit directive) causes PKCS#1 1.5 to be used
  • AlternateSignatureAlgorithm = 1 causes the use of PKCS#1 2.1

In the last "official" book on Microsoft Active Directory Certificate Services, "Microsoft Windows Server 2008 PKI and Certificate Security" by Brian Komar incorrectly refers to DiscreteSignatureAlgorithm, and the values were exactly reversed. At the time the book went to press, this was also correct, but with the transition from the beta version of Windows Server 2008 to the final version, the directive was renamed to "AlternateSignatureAlgorithm", including the reverse functionality. Thus, PKCS#1 was still used as the default in version 1.5 if the directive was not explicitly configured.

Examples of different combinations

The signature algorithm displayed in the properties dialog of a certificate is determined based on the combination of all three factors:

  • Key algorithm
  • Signature hash algorithm
  • Signature algorithm (PKCS#1 version)
Example: SHA256 with RSA key and PKCS#1 version 1.5
Example: SHA256 with RSA key and PKCS#1 version 2.1
Example: SHA256 with ECC key and PKCS#1 version 1.5
Example: SHA256 with ECC key and PKCS#1 version 2.1


A common enterprise certificate authority hierarchy typically uses the following parameters to ensure maximum compatibility while maintaining a high level of security:

Key algorithm and bit lengthRSA with 4096 bits for certification authority certificates
RSA with 2048 to 4096 bits for end-entity certificates
Signature hash algorithmSHA256
Signature algorithm (PKCS#1 version)PKCS#1 Version 1.5
Example of algorithms used in a common enterprise PKI

Related links

External sources