Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's English Pages


Engineering and troubleshooting by Directory Master!
MCM: Directory

Quick Launch

Ondrej Sevecek's English Pages > Posts > CSP, CNG and their application support
April 30
CSP, CNG and their application support

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:

Application Supports CNG since
HTTPS and Schannel TLS server and client certificates Windows Vista and Windows 2008
EFS Windows 7 and Windows 2008 R2
Kerberos KDC certificates Windows 7 and Windows 2008 R2
EAP-TLS and PEAP client certificates Windows 8 and Windows 2012
IPSec computer certificates Windows Vista and Windows 2008
Outlook S/MIME certificates Outlook 2007 running on Windows Vista or Windows 2008

ISA Server or ForeFront Threat Management Gateway server certificates

never will
SQL Server

SQL Server 2016 does not support it yet

System Center Operations Manager server and client certificates SCOM 2012 R2 version does not support it yet
System Center Configuration Manager server and client certificates SCCM 2012 R2 does not support it yet
digitally signing VBSCript or EXE code or arbitrary data into PKCS#7 format with Signer COM object (CAPICOM) never will
digitally signing data into PKCS#7 format with .NET Framework CMSSigner class NET Framework 3.5 on Windows Vista and Windows 2008
Forefront Identity Manager - Certificate Management FIM 2010 does not support it
​AD FS - Active Directory Federation Services the built-in version on Windows 2012 R2 does not support it yet​
AD ​RMS - Active Directory Rights Management Services does not support CNG/KSP yet on Windows 2012 R2​

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.

Template version Version number CA that can use it CSP or CNG
Windows 2000 1 Windows 2000 and newer CSP only
Windows 2003 2 Windows 2003 and newer CSP only
Windows 2008 3 Windows 2008 and newer CNG only
Windows 2012 4 Windows 2012 and newer CSP or CNG choice

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.




thank you so much for this info!  it helped me soooo much.
 on 28/03/2014 16:29

Any info about Microsoft Office?

Does anyone knows what version of Microsoft Office started supporting CNG for digitally signing documents? I do know Office 2013 works fine.
 on 13/06/2014 12:51


Thanks a lot for this excellent article on CSP and CNG.  I cleared a lot of confusion.
 on 03/09/2014 21:45

Add Comment

Sorry comments are disable due to the constant load of spam *

This simple antispam field seems to work well. Just put here the number.


You do not need to provide any value this column. It will automatically fill with the name of the article itself.

Author *

Body *