Understanding Microsoft Cryptographic Service Providers

Crypto Provides PKI

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

Modern Microsoft cryptography providers

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 Use only if creating/using keys in a smart card
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

Legacy Microsoft cryptography 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

Deprecated Microsoft cryptography providers

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!

About ThePKIGuy

President & Founder at PKI Solutions, Leading PKI Cybersecurity Subject Matter Expert, Author, Speaker, Trainer, Microsoft Certified Master.

37 Comments

  1. Mario Alvares on March 9, 2018 at 8:18 pm

    NDES 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 ?

    • The PKI Guy on March 9, 2018 at 8:22 pm

      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.

      • Mario Alvares on March 9, 2018 at 9:12 pm

        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

  2. The PKI Guy on March 12, 2018 at 10:41 am

    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!

  3. Mario Alvares on March 12, 2018 at 2:35 pm

    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.

  4. The PKI Guy on March 12, 2018 at 2:50 pm

    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.

  5. The PKI Guy on March 13, 2018 at 1:56 pm

    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.

  6. SS on July 12, 2018 at 8:52 am

    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?

    • Mark B. Cooper aka "The PKI Guy" on July 12, 2018 at 6:21 pm

      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.

  7. ND on October 29, 2018 at 4:32 am

    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

    • Mark B. Cooper aka "The PKI Guy" on October 29, 2018 at 10:49 am

      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.

  8. Luke on April 1, 2019 at 12:32 pm

    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)”

    • Mark B. Cooper aka "The PKI Guy" on April 1, 2019 at 3:32 pm

      Thanks, actually it was row 3 that was the incorrect line item so I removed it.

  9. Luke on April 1, 2019 at 12:51 pm

    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

    • Mark B. Cooper aka "The PKI Guy" on April 1, 2019 at 3:37 pm

      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.

  10. Sheikh Azharuddin on July 29, 2020 at 4:45 am

    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?

    • Vadims Podāns on July 30, 2020 at 7:13 am

      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.

  11. Bob on October 9, 2020 at 1:35 pm

    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!

    • ThePKIGuy on October 9, 2020 at 2:29 pm

      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.

  12. Kashif Ansari on November 2, 2020 at 5:07 am

    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.”

    • ThePKIGuy on November 2, 2020 at 8:24 am

      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.

      • Kashif Ansari on November 4, 2020 at 12:41 am

        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”?

        • ThePKIGuy on November 4, 2020 at 5:50 am

          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.

        • Tej on May 18, 2021 at 8:52 am

          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”

          • ThePKIGuy on May 18, 2021 at 9:08 am

            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”



  13. CyrAz on January 7, 2021 at 3:53 am

    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

    • ThePKIGuy on January 11, 2021 at 8:55 am

      Let me try to recreate the issue you are seeing in my lab and get back to you.

      • Richard B on April 2, 2021 at 10:12 am

        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.

  14. Aleksey on March 29, 2021 at 11:38 am

    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.

  15. Everett Hubble on July 19, 2021 at 6:17 pm

    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.

    • Vadims Podāns on July 22, 2021 at 4:28 am

      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.

      • Everett Hubble on July 26, 2021 at 7:52 am

        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.

  16. CXMelga on September 20, 2021 at 5:20 am

    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

    • ThePKIGuy on September 22, 2021 at 8:51 am

      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.

  17. Tim on September 21, 2021 at 2:45 am

    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

    • ThePKIGuy on September 22, 2021 at 8:48 am

      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.

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.