Help a SME Out – Don’t Guess at Template Settings

One of the areas we spend time on in the PKI In-Depth class is learning about Certificate Templates. There are a lot of tabs in the template manager and a lot of specific settings on those tabs. I can certainly understand the desire to click those pretty checkboxes, toggle radio buttons and get lost in the beauty of a Win32-based GUI form. But this can lead to many issues down the road. We literally spend almost half a day in class going over each and everyone of these options and settings in the template.

But my focus today is on the prevalence of bad tech articles that include bad or worse, incorrect information on using certificate templates. Today’s example is a lovely article from VMWare on creating a template for use with vSphere 6.0 here.

This article is well meaning, intending to help you create a template so that vSphere can use the proper type of certificate. But there are a number of bad things lurking in this article. Some are more nefarious than others, but I’d rather the details be right.

So let’s review what is wrong in the article:

SUBORDINATE CA – WARNING WARNING!

One of the things this article does not cover at all is the security ramification of implementing this solution. This article has you creating subordinate CA templates for use with the product. If you are at all concerned about security in your PKI you should be aware that assigning any application or device a Subordinate CA certificate delegates that device to act just like any other CA in your environment. That means whatever is creates (or is covertly tricked into creating) will be trusted throughout your environment. If you are using Hardware Security Modules for your CAs, when you set up this appliance, how will its key be protected? That key is just as sensative as the key being used by your “standard” CA.

HASH != ENCRYPTION

The first issue you will see in the article is actually an aside that they repeat several times in the article

Note: If you have an encryption level higher than SHA1, select Windows Server 2008 Enterprise.

1. What’s wrong with this? Well, a few things frankly:
2. SHA is a hashing algorithm intended for message integrity and source verification. It does not encrypt anything.
   The version/compatibility of the template has no bearing on the hash that will be used when the certificate is signed by the CA. If the CA is configured to sign certificates with SHA256, that will occur regardless of the template version. PERHAPS they were referring to another misperception that by using a Server 2008 template (V3+) that you can choose to use a Key Storage Provider and as a result you can choose to sign your certificate REQUEST with SHA256, but this only affect the request file being sent to the CA as outlined in this article I wrote. But I seriously doubt that was the case.

NO EKU = ALL PURPOSES

Another area that the article glosses over are these two steps:

Select Server Authentication and click Remove, then OK.
Note: If Client Authentication exists, remove this from Application Policies as well.

The template you are working with ONLY has Server and Client Authentication to begin with. By removing those two EKUs you are left with no defined EKUs. This means ALL Key Usages are allowed.

NonRepudiation for SSL?

Nonrepudiation is a concept of using specific identities to be able to determine that a specific individual was the only one that could have used that identity for a specific task. With an appropriate set of process and controls, the owner of that identity should not be able to challenge the authenticity of their actions. So what does this requirement have to do with VMWare and SSL needs? Excellent question? Why is this step being used?

Select Key Usage and click Edit
Select the Signature is proof of origin (nonrepudiation) option. Leave all other options as default.

Publish Certificate in AD

This one is a common mistake – but no excuse. Checking this box results in no visible change so the user/engineer never really knows what they did was unneeded. In some cases this can cause massive AD replication issues.

1. Ensure Publish certificate in Active Directory is selected.

This option is used for Secure Email and Encrypted File System certificate templates so that the CA will publish a copy of the user’s encryption certificate to AD when the certificate is issued. This is needed so that Secure Email can locate a recipients public key to be able to encrypt a message to that user. EFS can also be used to allow other users to decrypt a file, and to do that, EFS needs to be able to locate the other users public key so the EFS File Encryption Key (FEK) can be protected with that users public key. Publishing any other certificate to AD just serves to bloat AD with unnecessary items that have to be replicated.

Summary

So there you go – one example of an authoritative technical document designed by someone who knows their OWN product but has made a lot of assumptions about certificates and templates to “get it to work”. While I don’t hold anyone specifically responsible, the implementer who is going to find this article is unlikely to question the items as much as they should. So everyone owes it to themselves, the security community and their customers to make sure they are recommending GOOD practices and not quick fixes.

Also, this marks the beginning of the “Documentation Hall of Shame” series as selectable by the blog category aptly named “Documentation Hall of Shame“. Stay tuned for future additions and if you come across suspicious documentation for PKI, send it over along with a pointer to what looks fishy to you.