A newer version of this documentation is available.

View Latest

Microsoft CryptoAPI CSP


The cryptographic standard interface Microsoft CryptoAPI CSP is available through the name "Net iD – CSP". More information about the standard can be obtained from Microsoft Developer Network http://msdn.microsoft.com.

This allows the product to cooperate with applications, which support this interface, for example Microsoft Internet Explorer.

Container names

CryptoAPI has a limitation of two key pairs for each container. Smart cards or soft tokens may have multiple key pairs and each key pair may have multiple certificates, so each PKCS#11 certificate will be considered as a container. The container name will be generated from the certificate fingerprint (sha-1 digest) followed by the PKCS#11 slot ID. The X.509 extension key usage will be used to set the key type; all certificates with the non-repudiation bit set will get key type AT_SIGNATURE and all other AT_KEYEXCHANGE.

"<certificate fingerprint> (<slot id>)"

The Microsoft container format for smart card readers is also supported:

"\\.\\<smart card reader name>\<id>"

The <id> part is optional and may be used to handle multiple key pairs on same token, but with the limitation of one key type for each <id>.

Certificate request

XEnroll or CertEnroll

The normal case with one AT_SIGNATURE and one AT_KEYEXCHANGE key the container name may be ignored when using XEnroll or CertEnroll for certificate requests. The key type will be used to map to correct key pair and the requests will be sent to first available token.

More advanced requests, for example with multiple smart card readers the container format above must be used, specify the smart card reader to use.

Common implementation mistakes

The main problems are the container name and the limitation of two key types for each container.

Never use container name

Only applications managing the private keys and certificates needs to be concerned about the container name, all other applications should be using the certificate context.

Usually this is not a problem, since the standard way to handle certificates in CryptoAPI is to enumerate all certificate contexts in the user certificate store ("MY") and use the certificate context in the available high-level functions. The application using CryptoAPI will not care which CSP is used to handle the request.

There are some rare scenarios where the application is interested in which CSP that is used. For these scenarios open a context towards a specific CSP, enumerate all containers, and get all certificates available for these containers. The returned contexts may then be used in the same way as those returned from the user certificate store enumeration.


Microsoft has very good documentation with examples published on Internet at Microsoft Developer Network (MSDN), see http://msdn.microsoft.com/.