Ondrej Sevecek's English Pages

Veeery good. The new EAP-TLS and PEAP client in Windows 8 and Windows 2012 now supports CNG certificates finally. CNG is an abbreviation for Cryptography Next Generation, the new library of cryptographic functions built in Windows Vista and Windows 2008.

Since Windows NT, cryptography functions have been provided by technology called CSP - Cryptographic Services Providers. This library is still available even in Windows 2012 and Windows 8, but has some characteristics that do not meet current trends. It is more complicated to use by application developpers, is not extensible in such a simpler way as CNG is. CNG is also the only technology that evolves and is actively developped by Microsoft.

If you want to list all CSP and CNG providers, you can do it from command line with CERTUTIL:

certutil -csplist

Simply to distinguish between the two types - if there is Provider Type value, it is CSP. CNG providers do not have Provider Type.

CNG supports the newer algorithms such as ECDH and ECDSA public key algorithms and provide better process isolation as required by Common Criteria. Private keys should not share the same process memory with applications that use their cryptographic services. With CNG, private key operations are isolated to a separate process running the CNG Key Isolation service (actually sharing the LSASS - Local Security Authority Sub System process).

For these reason, applications designed for newer Windows are slowly beginning to support the CNG library. To my knowledge, there is yet no application that would require only the CNG library, while all support both CSP and CNG in parallel. Yet there are many that do not support CNG at all and still can use CSP only - such as SQL Server 2012 for example.

What is the difference from administrator's perspective? It is quite important. Because when you enroll a certificate, generate a request or just import a certificate with its associate private key into your operating system, the private key is always strictly managed by a certain CSP or CNG provider.

Although the certificate GUI does not give it too much importance and shows nothing in this regard, you can always determine the exact provider by using CERTUTIL from command line:

certutil -user -repairstore my *
certutil -repairstore my *

The two previous commands display information about certificates and their associated private keys for user and computer certificates respectively. If a certificate has an associated private key, the command displays the name of its handling CSP or CNG provider - the Provider = value. You cannot simply move a private key from one CSP to another nor to a CNG or wiceversa either.

If the Provider is called <something> Key Storage Provider, then it is the CNG provider. Others are CSP.

The problem with applications is, that their developpers must be able to handle each particular CSP or CNG provider and the application must support it. For example, if an application does not have code to work with Microsoft Software Key Storage Provider, then it cannot use certificates whos private keys are stored in the provider.

A good example of a wrong implementation gives System Center Configuration Manager 2007 which supports only the Strong Cryptographic Services Provider and nothing else. If you need client/server certificates with the SCCM Native Mode, you must enroll the certificates into this particular CSP, or SCCM will not use them.

The case with EAP-TLS or PEAP (used for VPN or 802.1x authentication) with client certificates on Windows 7 was that it didn't support CNG certificates. So if you enrolled users with certificates into some Key Storage Provider, the VPN client on Windows 7 just returned the following error:

Network Connections
Cannot load dialog
Error 798: A certificate could not be found that can be used
with this Extensible Authentication Protocol.

Evolution table

The following table summarizes my investigations about what applications support CNG and since when. You can see that although CNG is available since Windows Vista (circa 2006), not even all Windows internal components support it:

Certificate templates and AD CS

How do you determine what CSP or CNG will enroll a certificate if you use Active Directory Certificate Services (AD CS)? ADCS in Enteprise CA mode (AD integrated DCOM online CA) issues certificates only on bases of certificate templates.

Certificate templates currently have four versions available (the msPKI-Template-Schema-Version attribute). Different CA versions support different certificate template versions. The templates can specify which CSP or CNG provider should the resulting certificates go into, but there are some restrictions. The easiest way is to look at the following table.

So if you create a certificate based on the Windows 2008 version template, it will definitely be a CNG certificate. Application that do not support CNG will not be able to use its private key.

If you compare the support table above with the CNG/CSP template version table, you can quickly understand why the default option, when creating a new certificate template, is set to Windows 2003 compatibility, although you may be doing this with Windows 2012 GUI on a brand new Windows 2012 certification authority.