1

When importing a device certificate/private key through CERTLM, the GUI seems to choose a deprecated Cryptography Service Provider (CSP) called "Microsoft Strong Cryptographic Provider"; I'm wondering if there is a way to change this to "Microsoft Software Key Storage Provider" through the wizard or group policy or (other means).

More details: A vendor asked me to import a PFX to a Windows 11 local machine certificate store through the following line command syntax:

certutil -csp "Microsoft Software Key Storage Provider" -importpfx MyPathToCertificate.pfx NoExport

This worked great with their software, however when I had previously tried to import the same PFX, I had used CERTLM (GUI) to import the certificate to same place (local machine / personal store). This seemed to work at the time (certificate appeared there) but caused decryption errors as indicated in the vendor's logs.

Here's how I had imported through the CERTLM:

  1. I launched Command Prompt via UAC / Choose Certificates (local machine)
  2. I imported the PFX using the default options to the Personal store

After running the following command: Certutil -store My

I noticed the certificate had the following line: Provider = Microsoft Strong Cryptographic Provider

whereas the certutil command explicitly chose "Microsoft Software Key Storage Provider"

According to https://www.pkisolutions.com/understanding-microsoft-crypto-providers/ "Microsoft Strong Cryptographic Provider" is a deprecated legacy provider whereas "Microsoft Software Key Storage Provider" is a modern, preferred choice for working with new keys.

The different CSP explains why the vendor's app was not working after the original import, and I understand why MS would choose an "old" provider as a default for backward compatibility, but I'm curious if there are ways to specify the CSP when performing the import through CERTLM going forward.

Improve this question
6
  • Have you verified that this was the reason why it failed with the GUI? For example, use certutil.exe -importPfx without the -csp option to import.
    – garethTheRed
    Nov 26 at 19:41
  • @garethTheRed : The certificate was created for testing via PowerShell using this doc learn.microsoft.com/en-us/azure/vpn-gateway/… and I read somewhere default crypto provider for self-signed via built-in New-SelfSignedCertificate cmdlet was "Microsoft Software Key Storage Provider". When I export the client cert from that walk-thru, it seems to use "Microsoft Strong Cryptographic Provider" instead, as indicated by running certutil to do the import without specifying -csp, then running "certutil -store My" to view the legacy provider
    – tb1
    Nov 27 at 17:26
  • I understand what you're doing. My thoughts are that maybe the issue you're suffering from isn't caused by the CSP vs KSP difference, but rather some other cause. I was wondering if when you import it using certutil.exe but using the CSP, does the application fail or work?
    – garethTheRed
    Nov 27 at 18:14
  • The vendor application fails to decrypt when CSP is "Microsoft Strong Cryptographic Provider".
    – tb1
    Nov 27 at 18:45
  • 1
    I also found out the issue (!!): In learn.microsoft.com/en-us/azure/vpn-gateway/… params: KeySpec = 'Signature' is a LEGACY value and causes the CSP to become "Microsoft Strong Cryptographic Provider". Per learn.microsoft.com/en-us/powershell/module/pki/… "The default value, None, indicates that this cmdlet uses the default value from the underlying CSP." SO: If you omit the KeySpec line or set it NONE, CSP becomes "Microsoft Software Key Storage Provider" on creation (which we want)!!
    – tb1
    Nov 27 at 18:47

2 Answers 2

Reset to default
5

The short answer to your question: no, you cannot specify provider during import in MMC GUI, you have to use certutil.

Certificates MMC (certmgr.msc and certlm.msc) attempts to import keys into same provider as specified in PKCS#12 file as attribute (Windows machines set this attribute during certificate export to PFX and import logic respects this attribute). If provider not specified or not available, keys are imported into legacy CSP. The reason is that in 2023 there are many applications that do not support CNG providers and CERTLM uses the most compatible provider.

If you want to use different provider, you have to use certutil -importPFX with -csp parameter.

Improve this answer
0
1

Crypt32 had the best short answer, but I will try to embellish with some additional gotchas:

Answer: You shouldn't need to choose "Microsoft Software Key Storage Provider" if the original certificate was created with that same provider and exported through CERTLM as a pfx. And if you do need to specify your provider, you can override it (e.g. with certutil -importPFX with -csp parameter).

More details: If you're just starting out like me, you may have read Microsoft's documentation here which provides a way to create self-signed certificates through PowerShell and the New-SelfSignedCertificate command.

Everything I read online suggested that the New-SelfSignedCertificate command creates certificates with "Microsoft Software Key Storage Provider" as the provider by default. However, when you follow the steps in Microsoft's document, you end up with Microsoft Strong Cryptographic Provider as your provider. Why?

The issue is the following line: KeySpec = 'Signature'

According to Microsoft's documentation on the PS command itself, the KeySpec is essentially a legacy property:

"If the private key is managed by a legacy CSP, the value is KeyExchange or Signature. If the key is managed by a Cryptography Next Generation (CNG) KSP, the value is None."

By including a value for KeySpec, we end up creating a certificate that uses the default legacy provider (Microsoft Strong Cryptographic Provider).

How do we fix this? Just replace that property with the following two:

KeyUsage = 'CertSign'
KeyUsageProperty = 'Sign'

Final example looks something like this:

 $params = @{
     Type = 'Custom'
     Subject = 'CN=Your Subject Here'
     KeyExportPolicy = 'Exportable'
     KeyUsage = 'CertSign'
     KeyUsageProperty = 'Sign'
     KeyLength = 2048
     HashAlgorithm = 'sha256'
     NotAfter = (Get-Date).AddYears(2)
     CertStoreLocation = 'Cert:\CurrentUser\My' 
} 
$cert = New-SelfSignedCertificate @params

And if you run this command after that: certutil -user -store My You should see a line that says Provider = Microsoft Software Key Storage Provider after that certificate.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .