A common question I often get from customers and students is about Microsoft’s Cryptographic Service Providers (CSP). The CSPs are responsible for creating, storing and accessing cryptographic keys – the underpinnings of any certificate and PKI. These keys can be symmetric or asymmetric, RSA, Elliptical Key or a host of others such as DES, 3DES, and so forth. Selecting a cryptographic provider determines what type, size and storage of key will be used – in our case, for a certificate. There are also 3rd party providers for devices such as smart cards and hardware security modules. For the purposes of this article, I will be addressing the standard Microsoft CSPs and the newer Crypto-Next Generation KSPs, their capabilities and the primary purposes you may use them.
Discover why seeing is securing with revolutionary PKI monitoring and alerting.
Learn More About PKI Spotlight®Let me start by saying there are many more CSPs than you will typically ever need to use. To that end, in the comparison tables below, I have broken the providers into three tables. Modern Crypto-Next Generation (CNG) providers that are recommended, followed by legacy CAPI (RSA only) providers and the last table is deprecated providers seldom used anymore. In reviewing this list, the primary things we are evaluating are what types of keys can be used, their size, protections, and compatibility.
For the short answer, refer to ThePKIGuy Recommendations for each provider to see where and why you may use a specific provid
A common question I often get from customers and students is about Microsoft’s Cryptographic Service Providers (CSP). The CSPs are responsible for creating, storing and accessing cryptographic keys – the underpinnings of any certificate and PKI. These keys can be symmetric or asymmetric, RSA, Elliptical Key or a host of others such as DES, 3DES, and so forth. Selecting a cryptographic provider determines what type, size and storage of key will be used – in our case, for a certificate. There are also 3rd party providers for devices such as smart cards and hardware security modules. For the purposes of this article, I will be addressing the standard Microsoft CSPs and the newer Crypto-Next Generation KSPs, their capabilities and the primary purposes you may use them.
Let me start by saying there are many more CSPs than you will typically ever need to use. To that end, in the comparison tables below, I have broken the providers into three tables. Modern Crypto-Next Generation (CNG) providers that are recommended, followed by legacy CAPI (RSA only) providers and the last table is deprecated providers seldom used anymore. In reviewing this list, the primary things we are evaluating are what types of keys can be used, their size, protections, and compatibility.
For the short answer, refer to ThePKIGuy Recommendations for each provider to see where and why you may use a specific provid
| Provider Name & Type | Description | Purposes | Crypto | Default Microsoft Templates | ThePKIGuy Recommendations |
|---|---|---|---|---|---|
| Microsoft Software Key Storage Provider (CNG) | Standard windows software based RSA and ECC provider. | Key Exchange Digital Signature Data Encryption | RSA ECC SHA1 SHA2 | OCSP Response Signing (KSP Required, Provider not specific) | Use this for any modern CNG supported key storage and creation |
| Microsoft Smart Card Key Storage Provider (CNG) | Supports smart card key creation and use | Key Exchange Digital Signature Data Encryption | RSA ECC SHA1 SHA2 | None | None |
| Microsoft Platform Crypto Provider (CNG) | Supports smart card key creation and use | Key Exchange Digital Signature Data Encryption | RSA ECC SHA1 SHA2 | None | Use only if creating/using keys in a smart card |
| Microsoft Platform Crypto Provider (CNG) | Generates and stores keys in Trusted Platform Modules. Supports Key Attestation to allow CA to ensure key is created in TPM/Virtual smart card | Key Exchange Digital Signature Data Encryption | RSA ECC SHA1 SHA2 | None | Use only if creating/storing keys in a Trusted Platform Module |
Comparison of modern Microsoft providers
| Provider Name & Type | Description | Purposes | Crypto | Default Microsoft Templates | ThePKIGuy Recommendations |
|---|---|---|---|---|---|
| Microsoft RSA SChannel Cryptographic Prodvider (CAPI) | Supports hashing, data signing, and signature verification. The algorithm identifier CALG_SSL3_SHAMD5 is used for SSL 3.0 and TLS 1.0 client authentication. This CSP supports key derivation for the SSL2, PCT1, SSL3 and TLS1 protocols. | Key Exchange | RSA SHA1 | CEP Encryption Computer Directory Email Replication Domain Controller Domain Controller Authentication IPSec IPSec (Offline) Kerberos Authentication RAS and IAS Server Router (Offline request) Web Server Workstation Authentication | Use this for any network/SSL/TLS when you must use a CSP provider |
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider (CAPI) |
Supports Diffie-Hellman key exchange (a 40-bit DES derivative), SHA hashing, DSS data signing, and DSS signature verification. Derived from Base DSS and Diffie-Hellman Cryptographic Provider. Adds support for RC2/4, DES and 3DES encryption | Digital Signature | RSA SHA1 | Authenticated Session Basic EFS CA Exchange Code Signing EFS Recovery Agent Enrollment Agent Enrollment Agent (Computer) Exchange Enrollment Agent (Offline request) Exchange Signature Only Exchange User Key Recovery Agent Trust List Signing User User Signature Only |
If using legacy CSP and you have no need for encryption this is fine. |
| Microsoft DSS and Diffie-Hellman/Schannel Cryptographic Provider (CAPI) | Supports hashing, data signing with DSS, generating Diffie-Hellman (D-H) keys, exchanging D-H keys, and exporting a D-H key. This CSP supports key derivation for the SSL3 and TLS1 protocols. This CSP supports key derivation for the SSL3 and TLS1 protocols. | Key Exchange | RSA SHA1 | Web Server | Legacy – Don’t use unless you are needing to support the built in Web Server temp |
| Microsoft Base Cryptographic Provider (CAPI) | A broad set of basic cryptographic functionality that can be exported to other countries or regions. No 3DES support. RC2/4 limited to 40bits. | Digital Signatures Data Encryption |
RSA SHA1 | Administrator Authenticated Session Basic EFS Code Signing EFS Recovery Agent Enrollment Agent Enrollment Agent (Computer) Exchange Enrollment Agent (Offline request) Exchange Signature Only Exchange User Trust List Signing User User Signature Only |
Legacy – Don’t Use |
| Microsoft DSS Cryptographic Provider (CAPI) | Provides hashing, data signing, and signature verification capability using the Secure Hash Algorithm (SHA) and Digital Signature Standard (DSS) algorithms. | Digital Signatures | RSA SHA1 | Authenticated Session Code Signing Enrollment Agent Enrollment Agent (Computer) Exchange Enrollment Agent (Offline request) Exchange Signature Only Trust List Signing User Signature Only |
Legacy – Don’t Use |
Providers still used out of the box, but are limited in abilities are generally not used
| Provider Name & Type | Description | Purposes | Crypto | Default Microsoft Templates | ThePKIGuy Recommendations |
|---|---|---|---|---|---|
| Microsoft Base Smart Card Crypto Provider (CAPI) | Derived from Microsoft Strong Cryptographic Provider. Communicates with Smart Card Modules (minidriver). | Digital Signatures Data Encryption | RSA SHA1 | None | Use only if your smart card supports CSP and not CNG. Otherwise this is |
| Microsoft Strong Cryptographic Provider (CAPI) | An extension of the Microsoft Base Cryptographic Provider available with Windows XP and later. Default RSA CSP. Derivative of Microsoft Enchanced Cryptographic Provider. Supports all the same key lengths, but lacks configurable Salt length for RC encryption algorithms. | Digital Signatures Data Encryption |
RSA SHA1 | None | Deprecated – Don’t Use |
| Microsoft Enhanced Cryptographic Provider (CAPI) | Derived from Base Cryptographic Provider. The Enhanced Provider supports stronger security through longer keys and additional algorithms. Can only generate 128bit RC2/4 keys, can import smaller | Digital Signatures Data Encryption |
RSA SHA1 | None | Deprecated – Don’t Use |
| Microsoft RSA and AES Cryptographic Provider (CAPI) | Microsoft Enhanced Cryptographic Provider with support for AES encryption algorithms. | Digital Signatures Data Encryption |
RSA SHA1 | None | Deprecated – Don’t Use |
| Microsoft Base DSS and Diffie-Hellman Cryptographic Provider (CAPI) | A superset of the DSS Cryptographic Provider that also supports Diffie-Hellman key exchange, hashing, data signing, and signature verification using the Secure Hash Algorithm (SHA) and Digital Signature Standard (DSS) algorithms. | Diffie Hellman (Key Exchange) Digital Signatures |
RSA SHA1 | None | Deprecated – Don’t Use |
Deprecated providers that are seldom used and should be avoided unless compatibility or business requirements define otherwise
Have a specific scenario where one of these providers was needed for another purpose? Have you been explicitly told to use a provider to support an application? If so, let me know so we can sort through the data and get it added to the list!
President & Founder at PKI Solutions, Leading PKI Cybersecurity Subject Matter Expert, Author, Speaker, Trainer, Microsoft Certified Master.
View All Posts by Mark B. CooperNDES on Windows Server 2012 R2 only supports the following CSPs:
1) Microsoft Strong Cryptographic Provider (Default)
2) Microsoft Enhanced RSA and AES Cryptographic Provider
3) Microsoft Base Smart Card Crypto Provider
4) Microsoft DH SChannel Cryptographic Provider
5) Microsoft Enhanced Cryptographic Provider v1.0
6) Microsoft Base Cryptographic Provider v1.0
All of these are listed as either legacy or deprecated in your table. Thoughts ?
NDES was never updated to support CNG providers so when using NDES you have no choice. But you can secure the NDES signing keys with a legacy CSP with and HSM. Clients are free to use whatever provider you choose unless you are performing key attestation. Also the NDES installer is hard coded to using specific v1 templates configured with these legacy providers. So if you want to use a HSM or alternate provider you have to change the certificates manually after install.
Thanks for your insight, Mark.
I have another NDES question that you might be able to help with. When installing NDES, I selected the default ‘Microsoft Strong Cryptographic Provider’ for both the RA signing and encryption certificate key providers. The NDES server successfully enrolled an RA certificate using the default ‘Exchange Enrollment Agent’ v1 certificate template. However, the ‘Exchange Enrollment Agent’ template does NOT have ‘Microsoft Strong Cryptographic Provider’ checked under the ‘Request Handling’ tab, CSPs section. (There are other providers such as ‘Microsoft Enhanced Cryptographic Provider v1.0’ and a few others checked in the CSPs section)
Per your other blog post at https://pkisolutions.com/certificate-template-request-hash-the-real-story/ : “Well, many properties of a template are hard and fast rules, such as if a Cryptographic provider is specified, that provider must be used”
How was the RA certificate enrollment succesful using a CSP (i.e. Microsoft Strong Cryptographic Provider) that wasn’t specified in the certificate template ?
Thanks,
Mario
Excellent question and to be frank, I haven’t looked at the install process close enough to notice this. I am going to repro this in my lab and see if I can track down what is going on. Stay tuned!
Thanks for looking into this, Mark. FWIW, I noticed the same thing for other certificate templates in our environment as well, so this may behavior may not be isolated to NDES.
I do have a hunch. The providers in the templates are suggestions. The CA really has no way of verifying or enforcing a specific provider. The intent is an AutoEnroll client or a manually enrolled request using the default will use the provider list in the template as the selection. However, if you choose to use another provider the CA has no way to know. So my suspicion is that even though those templates are specifying providers, the NDES install is hard coded to use the provider you select during the install.
The only way a CA knows which provider you use is if you perform Key Attestation.
I was right, the provider is hard coded in the install. The CA has no way to enforce a specific provider, nor does it know what a client used. So the NDES installer is using the provider specified in the UI during the install process. If a client used that template for something else, it would be told it SHOULD use that provider and the Microsoft UIs will only show those providers. But if you were writing your own code (or using someone else’s – Microsoft), then you are free to use any provider.
Thanks for looking into this, Mark.
Per Microsoft, AD FS cannot be configured with CNG provider SSL certificate. They recommend to use legacy Cryptographic Service Providers provider keys for SSL certificate. Thoughts? Will it be secure enough to use in a secure environment like PCI or HIPPA?
Yes several Microsoft products were never updated to use Crypto Next Gen (Key Storage Provider). Network Device Enrollment Service (NDES) is an example of another service that is unable to use KSP to create and store it’s keys. CSPs are as secure as KSP, but the downside is that CSP doesn’t support Suite-B. That means the certificate you will wind up with must be RSA encryption keys and only SHA1. Neither PCI nor HIPPA have any specific recommendations against SHA1, but SHA1 is no longer considered acceptable by commercial standards.
Another question around these and NDES, if I am configuring Windows 2016 Offline Root and Issuing CAs to be Suite B compliant, are the following how to articles still relevant:
and
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff829847(v=ws.10)#BKMK_ConfigCrypto (certainly the second one is quite old).
If I have configured my CAs as per those articles e.g. with ECDSA_P384#Microsoft Software Key Storage Provider does this mean I need to do anything different or change anything when or after installing NDES?
I’ve got a lab with a root and issuing CA configured with ECDSA_P384#Microsoft Software Key Storage Provider, and an NDES server installed choosing the default strong cryptographic provider. It seems to work as I can see the NDES enrolment and
admin pages and has enrolled for its own certs from the Suite B CA (but I haven’t got any further than that e.g. integrating with intune and deploying to devices). Not sure I undestand the above comments, if I have NDES in this config which certificates will be RSA/SHA1 and therefore not fit the Suite B profile?
Thank you, ND
NDES is capable of facilitating end-entity certificates and CAs that are using Suite-B. NDES is just unable to use CNG-based Key Storage Providers (KSP) for it’s own Signing and Encryption certificates. Thus the NDES server certificates can’t be Suite-B. But otherwise the CA and the end-entities can use KSP and Suite-B if you wish.
hey, Mark.
The 1st matirx table,Microsoft Platform Crypto Provider (CNG) repeated twice , I think you can remove row#4 ( aka the 1st Microsoft Platform Crypto Provider (CNG)). #4 is just a duplicate of #3. In fact it is talking about “Microsoft Smart Card Key Storage Provider (CNG)”
Thanks, actually it was row 3 that was the incorrect line item so I removed it.
Hi,
We have HSM with PKCS#11 interface, how can we create a Microsoft EKM provider ? We want to use HSM to store the encryption keys. HSM is not having EKM provider , HSm has only PKCS#11 provider.
If your can guide if there can be any way HSM pkcs#11 can be extended with Miscrosoft EKM provider by ways ?
Since you are using a HSM, it is up to the manufacturer to support various formats. If they don’t support EKM you will not be able to achieve your goal. You may need to explore option HSMs.
former line 3 still available :
Microsoft Platform Crypto Provider (CNG) Supports smart card key creation and use Key Exchange
Digital Signature
Data Encryption RSA
ECC SHA1
SHA2 None Use only if creating/using keys in a smart card
Real question is for Microsoft Software Key Storage Provider (CNG)
Is this statement correct?
When we create\customize User template, we can select the software KSP, in that case client will try to use TPM KSP first, if that is not available or does not work, the client will move on to use software KSP.
here is the reference: https://social.technet.microsoft.com/wiki/contents/articles/13964.creating-a-certificate-template-that-includes-the-microsoft-platform-crypto-provider-on-a-ca-with-no-tpm.aspx
If it is true, is that mean we can always select “Microsoft Software Key Storage Provider (CNG) “, it will automatically accommodate TPM’s availability, if TPM is present on client device it will use TPM KSP ( AKA Microsoft Platform Crypto Provider (CNG)), if TPM is NOT present on client device, it will use software KSP.
Thanks Mark
When using a certificate template that specifies a specific provider, the client will generally require that specific provider to be available. However, the CA has no way to enforce which provider was actually used without attestation. So if a user or the end-entity program reads the template but chooses not to follow the provider configuration and selects another compatible provider and generates a key of the appropriate type, the CA will not know of the change and will process the request the same. However, if you are talking about auto-enrollment in Windows, where it’s not a 3rd party app and the user isn’t involved, the client will fail. The article you reference speaks to selecting both the Platform provider AND the Software KSP:
We can also select the software KSP, in that case client will try to use TPM KSP first, if that is not available or does not work, the client will move on to use software KSP.
So in this case, yes the client will try the TPM first and if it fails, will try the Software KSP.
I have one query… my ADFS SHA256 certificate is stored in Microsoft Strong CRyptographic Provider CSP but still the SAML token generated by ADFS server has SHA256 in the signature… so how is it possible? Also for Websites if certificate is stored in Old CSP they don’t show any error.. what is the purpose of CSPs then?
ADFS token generation uses different API to sign data which is not limited to legacy SHA1 algorithm (as if it would use CAPI1 APIs).
> Also for Websites if certificate is stored in Old CSP they don’t show any error.. what is the purpose of CSPs then?
why it should show errors? CSPs are designed to store, protect and access keys via API. SChannel requires very basic features from CSP to establish a TLS session and even legacy CSPs meet modern web requirements for TLS handshake.
Hi, I presume you obtained the info from Microsoft web site correct? Can you please provide the Microsoft site URL(s)? I checked https://docs.microsoft.com/en-us/windows/win32/seccrypto/cryptographic-service-providers but it doesn’t say which CSPs are deprecated or not. Thanks!
Microsoft doesn’t publish an official list of deprecated CSPs. We have denoted older CSPs that are seldom used or have been replaced by newer, more modern providers.
Hi,
How you can say that these are deprecated without the author publishing that these are deprecated?
You found any specific security vulnerabilities in these providers, that’s why you are saying these are deprecated?
They are deprecated as they are part of the older Microsoft CSP library that is no longer actively developed. Microsoft has moved to the Crypto Next Generation library with Windows Server 2008 and is no longer actively developing or enhancing these older legacy providers.
Hi,
When trying to generate CSR via MMC on a Windows Server 2019, what determines the list of CSPs available to be selected?
We have selected CNG Key in the Template option but the Provider we want “Microsoft Enhanced RSA and AES Cryptographic Provider” is not selectable. The message says:
“The selected cryptographic service provider(CSP) cannot be used because a cryptography next generation (CNG) provider is required. Select a CNG Provider and try again. Provider type does not match registered value.”
How are you creating the CSR? With Personal/Right-Click/All Tasks/Advanced Operations/Create Custom Request? If so, on the third screen of the dialog, you need to select (No Template) Legacy Key as the provider you want is not a CNG provider. The dialog defaults to (no template) CNG Key.
Yes thats how we are generating the CSR but the problem is when it defaults to Legacy key, the Hashing algorith defaults to SHA1. And the certs being issued by our supported 3rd party CA is now enforcing SHA256 so we got error when we did Legacy Key.
And the problem is even using the default CSP with CNG, we are getting error becasue the vendor product we are working on wants the CSP “Microsoft Enhanced RSA and AES Cryptographic Provider”.
Is it possible to get the cert issues with CNG defaulted CSP and then change the Provider in the cert to “Microsoft Enhanced RSA and AES Cryptographic Provider”?
What do you mean by “Hashing algorith defaults to SHA1”? The hashing algorithm you see during an enrollment is only relating to the hash of the car file. A CA configured to issue SHA256 will always issue certificates signed SHA256 regardless of which provider you use or which hash you use to sign your request. https://pkisolutions.com/certificate-template-request-hash-the-real-story/
If you want to use “Microsoft Enhanced RSA and AES Cryptographic Provider” you must select the legacy provider.
Pardon me if i am wrong; we too had the same requirement recently where one of our development teams wanted CSP as Microsoft Enhanced RSA and AES Cryptographic Provider and for our 3rd party CA we do not have any option to modify templates so we issued the cert with default CSP and then changed the provider in the cert to Microsoft Enhanced RSA and AES Cryptographic Provider by following below steps with openssl;
Following steps were taken to do this
Using Openssl
1) Create CSR and private key using below command
openssl req -new -newkey rsa:2048 -nodes -out cert.csr -keyout private.key -subj “/C=US/ST=NC/L=Raliegh/O=xxx /OU=IT Services/CN=xxx.com”
2) Convert .key into true.pem by using below command
openssl rsa -in private.key -text > privatekey.pem
3) if need the cert to be in .pem format and then Convert the Cryptographic Service Provider Type by using below command
openssl pkcs12 -export -inkey key.pem -in cert.pem -out new-idp.pfx -CSP “Microsoft Enhanced RSA and AES Cryptographic Provider”
Actually this can be done much easier. Once the certificate is issued, export it to a PFX file. Then delete the certificate and reimport the certificate and specify the provider you want. So in this case you could have done:
certutil -importpfx -csp “Microsoft Enhanced RSA and AES Cryptographic Provider”
Hi,
The table states that Microsoft Platform Crypto Provider can be used with ECDH certificates, and I would be interested in that because I’d like to use the TPM to store ECDH certificates.
However I’m unable to create a certificate template with Microsoft Platform Crypto Provider and ECDH algorithm : as soon as I select ECDH_P256 in the cryptography tab, Microsoft Platform Crypto Provider disappears from the list of providers.
Do you know if what I’m trying to do is possible?
Thanks 🙂
CyrAz
Let me try to recreate the issue you are seeing in my lab and get back to you.
I can confirm that I encounter the same issue. When customizing the certificate template on my CA, the “Microsoft Platform Crypto Provider” option disappears, if the algorithm name select is anything but RSA.
I’m having an issue with certificate private key files getting deleted somehow.
This only happens on one of the servers and we have the same certificates installed the same way on all the servers.
The certificates are used for WCF message security and are SHA256RSA certificates using “Microsoft Enhanced Cryptographic Provider v1.0” with the private keys marked as non-exportable.
Older MD5RSA certificates that we used for WCF message security (had to replace them because MD5 is outdated and doesn’t work with .NET 4.7 and WCF message security) are using “Microsoft Strong Cryptographic Provider” and the private keys are exportable. And there’s no such issue with the older certificates.
I wonder if this loss of private key is related to the type of the cryptographic provider or the exportability of the private keys.
Wonder if it’s even an option to use “Microsoft Strong Cryptographic Provider” with these new SHA256RSA certs.
CNG is not supported with WCF / .NET as far as I understand
I’m trying to do something which should be almost trivial, which is open a mutually authenticated SSL/TLS connection as the client where there is a smartcard connected to the system and working fine with web browsers, etc, on a system with .NET framework 4.8. I’ve been able to poke around and find the X509 certificate I’d like to use, but I don’t know how to get Windows to take care of signing the request data from the server by getting the user to enter their PIN and then having the card sign/encrypt the data using the private key associated with the certificate.
This looks like a programming question. I would suggest to address your issue on StackOverflow.com site and provide relevant information: what is your environment, what is your goal, what have you tried so far and post relevant pieces of code that doesn’t work.
I’m not sure why it looks like a programming question. I’m certainly not hoping to need to write a program. I’d like to think I can run openssl s_client or something like that.
I have a question please regarding this post and in particular, the CPSs listed under the “CEP Encryption” template (for NDES), thanks in advance.
By default, this template has a single CPSs ticked/checked which is the “Microsoft RSA SChannel Cryptographic Provider”
There are several others listed that are unticked, I assume the above one is ticked as it is the ‘lowest common denominator’? i.e. most compatible with a broad range of clients (if that is not the reason please let me know, thanks)
My question is, is there any harm or point in selecting one or more of the other available CPSs like the “Microsoft Strong Cryptographic Provider” ?
My thought is if a client requesting a certificate via SCEP can utilize this CSP locally it would be a more secure local storage option?
Therefore could it be worthwhile selecting more or more additional CSPs, so a client can use their preferred one and if it does not support it will simply use one of the other on the list it does support like the default one?
I would be grateful for some general advice/clarity for my understanding of the above
Thanks
Many of the list providers are incompatible with one or more desired settings in the template. So its possible for you to select a provider that could be used by a client but result in an incompatible request. You are better off selecting “any provider” then randomly selecting more providers. If there isn’t a specific business or crypto case to use something other than the default providers, I wouldn’t recommend making changes to the providers.
Hi
I came across your post and I am trying to understand something here, can you help?
If the CPS/KSP is client side, meaning where the client creates and stores it’s keys, and is only sending a certificate signing request to the CA for signing. Why should the CA (via the template) care about what CSP/KSP the client is using? Is the idea to try and enforce some good practice by trying to tell the client please only use these CSPs (as they are better) ?
Cheers
The majority of the time a CA doesn’t care what crypto provider a client uses. However, in some cases the CA will care – such as if the intent of a certificate is to be used for Smartcard authentication, the CA would want to instruct the client to use a Smartcard, or a TPM. So in that case the CA can use the provider list in the template to indicate to the client which provider to use. However, without key attestation, the CA doesn’t know for sure it was generated there. So the template is simply to provide the default/recommended instruction for which provider(s) to use. Ultimately the client will choose which to use. With Key Attestation, the device that was used (TPM for instance) countersigns the CSR request and the CA can determine WHERE (which provider) was used to create the keypair.
Thank you folks. Was debugging a problem and this page helped me to understand, that it depends on the provider, what hashing method is used/available. Had the issue, that my application did not like sha1. However
Microsoft Base Smart Card Crypto Provider (CAPI)
seems to use for the challenge-response steps only sha1.
Hello, our vpn vendor (strongswan/pfsense) told us, only sha2 is allowed for use in EAP-TLS authentication by now. I do not understand, why my self-signed certificates working fine, if vpn is setup to use user certs. But when loading this certs into a TPM or virtual smartcard (on top of TPM) or into a real smartcard (yubikey, nitrokey) i always see a protocol/algorithm mismatch.
Is there some kind of limitation in windows when using smartcards and certs?
These types of crypto compatibilities issues are driven by specific vendor implementations. If Strongswan/pfsense doesn’t support specific algorithms or hashes, that is their product limitation.
Good Evening
If I want to reduce the number of times a user is prompted for the smart card PIN, would I need to look at Crypto providers? I am trying to narrow down where to look. I cannot see it being controlled by GPO anywhere.
(Edit)
This is called Pin caching and can usually be managed through the smartcard mini driver if you are using a third party or may have some limited capabilities in GPO.
Hi, thanks for your prompt reply – its by yubikey. I’ve pinged them a message but may not get a reply yet.
I just wanted to confirm (if possible) that pin caching is not dependent of the crypto that is chosed – in my case the Smart card one you have in the CNG section.
I’m a bit confused by about your statement that the “Microsoft Strong Cryptographic Provider” is deprecated and should not be used. The docs you link to state: “The Microsoft Strong Cryptographic Provider is used as the default RSA Full cryptographic service provider (CSP).”
If you create a key with certutil and you do not change the storage provider to the “Microsoft Software Key Storage Provider”, it get’s stored in the “Microsoft Strong Cryptographic Provider”.
Also “certutil -key” dumps the “Microsoft Strong Cryptographic Provider” by default, unless explicitly telling it to dump the KSP.
If you add the ADCS role and install the service using the GUI, the newly created key is also stored there.
Do you have documentation to substantiate that claim? Where would you store the key of a root or intermediate certificate key-pair?
Kind Regards
Daniel
Deprecated doesn’t mean unsupported or discontinued. Microsoft has many products and features that get deprecated and simply means they are no longer being updated, developed, or having new improvements. When Microsoft developed the CNG, the KSP provider became the new provider type which is the active development cycle. So you can continue to use the deprecated CSP without issue, but other than security related fixes, it will not have any future development to it.
When you install ADCS, you are prompted to choose which provider you wish to use, but default it is the CNG based Key Storage Provider and has been since Server 2008.
Hi,
A year later I’m having the opportunity to give another try at this issue, and I figured out that it does work when the Purpose of the certificate is set to Signature only : in that case, I can select ECDSA_P256 algorithm with MS Plateform Crypto Provider.
I’m actually pretty confused at what would be the difference since as far as I understand it the key itself is not different, only its usage…
… even more confusing : what I described above works in my lab but not in my production environment, in which I get the same behavior as a year ago even with Signature purpose only.
And I finally have the answer to that mystery : the computer from which you run the Certificate Template console needs to have a TPM for the ECDSA+MS Crypto Provider to be available.
It was that simple 😀
I have a question. As I could see NDES doesn’t CAPI Next Generation (CNG) based Key Service Providers (KSP) for its keys. We have installed HSM KSP. Installed HSM is not listed during NDES configuration. So it supports only CSP though its external key storage provider. Please clarify
That is correct, you must use the older CSP based provider when securing the NDES server role certificate keys. So for your HSM, you will want to install the CSP provider.
Is there a way to disable the usage of the legacy CSPs like Microsoft Strong Cryptographic Provider (CAPI)?
No, it is not possible, because it will break a lot and a lot of apps.
Microsoft IIS tool allows to generate CSR file with “Microsoft RSA SChannel Cryptographic Provider” as CSP however our application uses only “Microsoft Enhanced RSA and AES Cryptographic Provider” format. How can we generate CSR with this CSP. Any idea?
The IIS UI does not let you choose a cryptographic provider. You would want to use certreq or the certlm.msc interface to create a certificate request.
Currently Using “Microsoft Base Smart Card Crypto Provider (CAPI)” with a smart card that only supports CSP.
I am getting the following error at the API level NCryptFinalizeKey() Failed with 0x80100022…Which would indicate that a feature is not supported. Currently I believe this is is trying to create a Key Pair. Could the fact that I want to use SHA256 be causing the issue…As I note that above this shows as not supported…However certutil -v -csplist…Appears to list SHA256, 284 and 512 for this provider. Confused!!
Hi Amit & All
Recently some of our servers that interfaces with the Luna 7 HSMs are having problem generating CSR for certificate renewal via IIS at Win2019 servers. Whenever trying to generate the CSR, it crashes the IIS.
No issue for older Win2012 servers (before we tech refreshes these servers). I.e., we had upgraded the servers to the latest but HSM still the same units.
After troubleshooting with Microsoft (Vicky@Shanghai & Jose Ortega) & internally yesterday, the interim solution is as the following & maybe it can help you too 🙂
1) Goto this path at the Windows Registry.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Cryptographic Provider v1.0
2) Manually backup/export these keys first (IMPORTANT! Later you need to insert back!). You can save the .reg file locally.
– Luna Cryptographic Services for Microsoft Windows
– Luna enhanced RSA and AES provider for Microsoft Windows
– Luna SChannel Cryptographic Services for Microsoft Windows
3) Manually delete all these 3 keys/entries
4) Proceed to generate the new CSR for your certs via the IIS’s UI
5) Double click on the backup .reg files to insert back the keys safely back to the Windows registry.
Re-check your registry entries to ensure in order.
Health check the hand-shaking with the HSMs.
6) Proceed with certs renewal process like usual.
**If you hit issue with the Luna HSM’s provider(s) again, may need to temporary backup, delete, and add back later.
Sounds like a hack/work-around that likely indicates a deeper issue is at play with the HSM. If this is a webserver, why was the luna software/providers installed? It would be unusual for a web server to be using a HSM.
Only a quick question regarding the ‘Microsoft Enhanced RSA and AES Cryptographic Provider’ CSP. You have it as Deprecated – Don’t Use and with supported Crypto as RSA and SHA1 only, and suggest using the ‘Microsoft RSA Schannel Cryptographic Provider’ for any network/SSL/TLS when you must use a CSP provider (e.g. ADFS, NDES, Microsoft SQL Server).
However on the Microsoft ‘CryptoAPI Cryptographic Service Providers’ documentation it appears to say that the Enhanced RSA and AES provider supports SHA256, SHA384 and SHA512 (while the RSA Schannel provider still only supports SHA1) and this appears to be corroborated by an old Microsoft blog post:
https://learn.microsoft.com/en-us/windows/win32/seccertenroll/cryptoapi-cryptographic-service-providers
https://web.archive.org/web/20190121132617/https://blogs.msdn.microsoft.com/alejacma/2009/01/23/sha-2-support-on-windows-xp/
Do you have a reference for the deprecation of the ‘Enhanced RSA and AES Cryptographic Provider‘ provider (aka ‘Microsoft AES Cryptographic Provider’) or could it perhaps be recommended in some situations over the ‘Microsoft RSA Schannel Cryptographic Provider’ since it appears to supports more recent hashing algorithms? Here are a couple of websites that suggest this may be the case:
https://support.secureauth.com/hc/en-us/articles/360021301651-How-to-support-signing-with-a-SHA256-certificate
https://learn.microsoft.com/en-us/windows/win32/seccrypto/aes-provider-algorithms
https://stackoverflow.com/questions/37626505/microsoft-rsa-channel-cryptographic-provider-not-available-during-creating-certi
Alternatively any references it’s deprecation would be welcome!
Schedule a Demo
