Strong key protection for Windows client’s private key encryption operations

During customer visits, I am often asked what is the most secure way to store and handle private key material. As we probably all know, two-factor authentication methods are the ones that are usually described when private key protection is of the utmost importance. So, in case of storing the private key of an Offline or Issuing Certification Authority, a Hardware Security Module (HSM) would be proposed, and for digitally signing emails or documents, a smart card would be ideal to store the key pair. Some companies, however, are reluctant to introduce hardware devices to their environment for two reasons: a) they believe they will add complexity to an already complex IT environment and that would degrade the end-user experience and b) they are not prepared to bear the added cost. In case of smart cards, that would amount to a pretty cheap device (around $20-40 or more, depending on quantity and software used). In both situations, the companies’ IT (or Security) departments do have a point, but they usually still need to have an extra layer of security for their end users. So, is there any “poor man’s added security” for private key usage?

Strong key protection while enrolling a certificate

Strong key protection while enrolling a certificate

Strong key protection password

Strong key protection password window during enrollment

Well, in the client-side of the Windows PKI world, the folks that designed CryptoAPI added an extra security feature called strong key protection. In essence, what strong key protection does, is to force the user to enter a user-defined password which protects the private key whenever (almost, as we are going to see later on) this is going to be used for a cryptographic operation. When such an operation (for example, digitally signing an email) is performed, the user will have to provide this password and only then the underlying client (Outlook, in this case) will be able to have access to they key.


The prerequisites to enable and use this feature are to select the relevant option in the Request Handling tab of the certificate template, and then have the user enter a password during user certificate enrollment. There are two caveats here that are hard to spot: a) there is now way to force a user to select the High security option and b) once you enter the password in Outlook, for example for signing or decrypting, the system will not ask for it again except if you close and re-open the application. Moreover, the password entered by the user if the certificate is generated by a Windows XP client will not conform to the domain policy’s complexity requirements – Windows Vista and later clients, though, will conform to it.

Partly due to the previously mentioned problems, but mainly due to the fact that strong key protection is not an actual two-factor authentication, I do not recommend it as a viable security solution for handling private key material. However, there are organizations where security is not a top priority, and it’s good to have choices 🙂

Certificate template settings for strong key protection

Certificate template settings for strong key protection

Troubleshooting certificate autoenrollment

Troubleshooting one of the most important and versatile parts of the Windows PKI world is a fairly complex process, since it involves a plethora of prerequisites in order for it to work correctly. Most of the times, consultants and administrators create a lab before a PKI deployment where autoenrollment usually works relatively easy – especially if the lab does not resemble the true production environment in anything other than the domain names.

In a very recent Windows PKI lab deployment for a major customer, we had a fairly lengthy autoenrollment troubleshooting session. The lab setup was a close-match replica of the production environment, as the Active Directory has been recreated using a backup of an actual production domain controller, as well as restored Exchange servers. The case was interesting: as it always seems to happen, everything was in place for autoenrollment to work, yet the process would not fire up at all.
To make a long story short, and after finding that no firewall, virtualization or general networking issues were involved, we finally tracked the autoenrollment failure down to two issues: the one is frequently seen in large organizations and has to do with GPO (Group Policy Object) precedence and settings’ overlapping. In our case, a GPO with no autoenrollment configured would prevail in the OU that the auto-enrolled users would reside and thus would not push the relevant settings to the clients. The second issue, however, was much more complex to target: as the environment has been set up many years ago, many administrators and third-party software packages have made a lot of changes in the production. One of the changes we found out that created problems, was the membership of two built-in groups: the Users and the Certificate Service DCOM access group. In the first one, the default membership should consist of Authenticated Users, Domain Users and Interactive (it did not, as you can imagine). In the second one, the Authenticated Users group should exist as a member (again, it was not – the list was empty).

We should say that in cases of autoenrollment failures, one should focus on:

  1. Certificate template security – make sure your users/computers have Read, Enroll and Autoenroll permissions and that the Authenticated Users group has not been deleted (it should be there with Read-only permissions).
  2. GPO precedence – make sure that you create a separate, enforced GPO to enable autoenrollment or, at least, that the GPOs applied to your users/computers finally lead to an enabled state for autoenrollment (RSOP is a great client-side tool to discover such issues).
  3. Group membership – the Issuing CA’s computer account should be a member of the Cert Publishers group in the intended enrollment domain; also, the Users and the Certificate Service DCOM Access built-in groups should have the membership detailed previously in this post.
  4. Server-side certificate issuance errors – a poorly configured certificate template (for example, one that requires an e-mail address in order for certificates to be issued when some user accounts may not have an e-mail address in AD) could lead to a certificate issuance request that is left in a pending or failed status, as seen in the Certification Authority console. Do check this by manually initiating a certificate request through an MMC console or a Web enrollment page (if configured) and make sure that the manual enrollment method actually succeeds in creating the intended certificate.
  5. Networking issues – blocked ports (RPC, HTTPS etc.) as well as problematic networking software or hardware (drivers etc.) could lead to problems in autoenrollment, Again, check if a manual request can succeed.

Update for CTLs in disconnected environments

In June 2013, Microsoft issued an update that makes the update of CTLs (Certificate Trust Lists) easier in disconnected environments. For the purposes of automatic updating, Microsoft considers any environment that does not have access to the Windows Update site as “disconnected.”

The new update enables Windows PKI administrators to:

  • change the update location from the predefined Windows Update URL to an intra-organizational shared folder that is reachable from disconnected clients
  • selectively disable/enable updating of either trusted or untrusted CTLs
  • create a custom set of trusted root certificates and distribute it via Group Policy.

The relevant knowledge base article can be found here, and its supporting documentation here. It is worth noting that the update is included in Windows Server 2012R2 and Windows 8.1, and does not apply to Windows XP and/or Windows Server 2003.

Client-side PKI problems: demystifying the “One of the CA certificates is not trusted by the policy provider” event

I was once contacted by one of our enterprise customers to troubleshoot a strange client-side PKI problem  – an email encryption certificate could not be issued for some specific PCs.
One of the problematic clients was a Windows 7 PC. Upon starting my troubleshooting session, I saw the “One of the CA certificates is not trusted by the policy provider” event.
This usually indicates that the Issuing CA’s certificate is not published in the NTAuth container of the Active Directory. In that case, the solution would be easy and we would just need to run certutil -dspublish -f IssuingCAcert.cer NTAuthCA so as to populate the container with the missing certificate. However, this was not the case, since most clients would successfully autoenroll for an encryption certificate – the problem was present only in specific PCs.

After digging some more into the registry, it was evident that something to that effect was happening – but this time, in the client-side PKI structure. Windows PCs cache whatever certificates are found in the AD NTAuth container at [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates]. This key would contain (cache) all NTAuth certificates which are propagated via group policy, which should also contain autoenrollment settings. What was found in the particular PC is that the client-side NTAuth cache was totally empty, which meant that either the NTAuth AD container
was empty (we rejected this based upon our previous observations) or the client could not successfully process its GPO(s). After running RSOP locally and opening the Group Policy Management console, we saw that the client was in an OU where the autoenrollment & encryption GPOs did not apply.
After we moved the PC to the expected OU and GPOs started “flowing”, the NTAuth client-side setting was populated and the autoenrolled encryption certificate was installed successfully.

Native SCEP support in Windows 8.1

During a session in TechEd 2013, Nelly Porter, Principal Lead Program Manager, Windows Security, announced that Windows 8.1 will natively support the SCEP protocol for mobile device certificate issuance. It is not immediately clear whether the RT version will also get the new feature; it is clear, however, that the RT version would benefit a lot from such an addition.
Microsoft’s SCEP server-side implementation (which goes by the name of NDES) has been introduced long ago by Microsoft in its PKI offering; first as an add-on to Windows Server 2003 and then included in Windows Server 2008/R2/2012. Of note is that several vulnerabilities that were found in the server-side component have now been patched.