Gardening and Weeding Certificate Templates: Private Key Flags

Mismanagement of certificate templates is one of the lowest of the low-hanging fruits when it comes to ADCS threat vectors. Among other things, a misconfigured certificate template can lead to a threat actor obtaining a certificate which could be used for privilege escalation up to and including Enterprise Administrator!
As you can imagine, it’s a good idea to keep an eye on the certificate templates that exist in your Active Directory forest(s). Pay special attention to those that are assigned to the certification authorities in your environment as these are exposed for use!

Managing certificate templates requires a “gardener-style” approach with frequent weeding. In a complex environment, a PKI team is often tasked with fascinating pilots and POCs with unique certificate-related requirements. This, combined with the fire drill-style troubleshooting which often occurs when critical business capabilities are impacted by a PKI-related outage, can often lead to creation and assignment of certificate templates which are unneeded, don’t enforce adequate crypto security or which have ACLs (access control lists) that are far too permissive.

While the Certificate Templates GUI is undoubtably a valuable resource for auditing, it necessitates a human being to manually view and assess template attributes. What’s even more challenging is that this GUI gives no indication of which templates are enabled on one or more CAs. The correlation must, again, be performed manually.

At PKI Solutions, we’ve been working hard to address the challenges of monitoring certificate templates in the upcoming release of PKI Spotlight. While all of the data about the certificate templates in a given Active Directory environment is available in the Public Key Services container, a decent amount of reverse engineering of ADCS (based on publicly-available Microsoft documentation) was required in order to extract the data in a meaningful way.

Many certificate template attributes are stored as flags. Flags are a bit-wise enumeration where the status of each bit in an integer value (when presented in binary format) constitutes an “on/off” switch for a particular setting. One of these flagged attributes is entitled “msPKI-Private-Key-Flag”

This attribute dictates to the CA and the client how the subject’s private key should be handled. For instance: Should the private key be exportable? Should the CA archive the subject’s private key? A full listing of these properties along with their bitwise values, can be found in this Microsoft Open Specification.

While developing the next release of PKI Spotlight, we encountered an interesting problem when dealing with the Private Key Flags enumeration. In .NET, if you have an enumeration defined with all the possible bitwise positions defined, you can then use the .ToString() extension method to automatically convert a value of that type to a comma-separated string containing the names of the bit-wise enumeration members which are “turned on” (1 versus 0). The result is that, when the value changes, we are able to present to the user a text representation of which settings were enabled before and after the value changed.

This works swimmingly for other flagged enumerations such Subject Name flags:

However, we found that with Private Key flags, the raw integer values were returned by .ToString() rather than the list of enabled members. This happens when the enumeration is missing entries corresponding to bit positions which are “turned on” in the indicated value. We defined our enum based on the Microsoft Open Specification, so why did it not work as we expected?

Through trial and error, I determined that the values which were seemingly missing from the enumeration laid out in the Microsoft article were:

0x10000 (65,536 or the 17th bit position, counting from the right)
0x1000000 (16,777,216 or the 25th bit position counting from the right)
Furthermore, I discovered that whenever I duplicated any of the default certificate templates, which are automatically present in an Active Directory forest, the new template always had these two bit positions turned on.

As it turns out, these values have a special meaning. The answer is provided towards the bottom of the Open Specification:

• The bitwise AND of the value of the msPKI-Private-Key-Flag attribute and 0x000F0000 determines whether the current CA can issue a certificate based on this template, as explained in [MS-WCCE] section 3.2.2.6.2.1.4.5.7.
• The bitwise AND of the value of the msPKI-Private-Key-Flag attribute and 0x0F000000 determines whether the current template is supported by the client, as explained in [MS-WCCE] section 3.1.2.4.2.2.2.8.

In simple terms, the CA server and enrollee client use these values, respectively, to determine whether it can support the certificate template. Conversely, for our purposes, we found that we could use this logic to indicate the minimum supported ADCS CA and Windows client versions for any given certificate template.

Credit goes to the great Vadims Podāns for integrating the logic to populate these properties into his incredible PKIX Library.

To determine the minimum supported ADCS CA version for a given certificate template, take the value for Private Key Flags and perform a bitwise AND against the value 0xF0000 (983,040 in decimal). The result of this calculation can be used with the

To determine the minimum supported Windows Client version for a given certificate template, take the value for Private Key Flags and perform a bitwise AND against the value 0xF000000 (251,658,240 in decimal). The result of this calculation can be used with the below lookup table:

Lastly, in order to facilitate the Private Key Flags enumeration to automatically be displayed as human-friendly comma-separated text, each of the values from the tables above, which represent minimum supported CA server and client versions, need to be added to the enumeration. This way, the bit positions in all valid Private Key Flags values are represented. The completed enumeration can be viewed here.

Conclusion: All information about certificate templates can be found in the Public Key Services container of your Active Directory forest, however a decent amount of data transformation is required to make it consumable for a human being. Here at PKI Solutions, we are working hard to ensure that this data can be made available to you in PKI Spotlight so that you can conveniently audit the certificate templates in your environment.