Specify PFX Provider type

[dcherry88]

BUSINESS PROBLEM Specific applications within company will not accept certificates unless they have a specific provider specified. The PFX output by the vCert playbook scenario is "Microsoft Enhanced Cryptographic Provider v1.0".

PROPOSED SOLUTION An ability to specify Provider type when specifying the output for PKCS12 installation.

CURRENT ALTERNATIVES certutil can be utilized on import to specify provider type when importing the certificates. Viable workaround, but for simpler end-user experience the ability to do this with vCert output would be beneficial.

VENAFI EXPERIENCE Less than 1 year on TPP and starting to utilize vCert.

[BeardedPrincess]

@dcherry88 ,

Just to clarify, are you referring to the creation of a standalone PKCS#12 certificate bundle, or specifically when vCert is installing the certificate into the MS CAPI store using the vCert playbook functionality? (I'm assuming the latter, since a standalone P12 file doesn't really specify a CSP)

[dcherry88]

This is the standalone output of the pkcs certificate bundle, not the feature of direct install into the MS CAPI store.

[BeardedPrincess]

Could you share how you're determining that the resulting PKCS#12 is using the Microsoft Enhanced Cryptographic Provider? Trying to reproduce the same on my end.

[dcherry88]

After importing the certificate either via powershell/certutil commands or via mmc console, open a terminal and run certutil -store my <thumbprint>

You should see a section on the output specifying Provider. When I examine this it's "Microsoft Enhanced Cryptographic Provider v1.0".

I can force an import of the cert to use "Microsoft RSA SChannel Cryptographic Provider" if I run the following command to import the certificate with certutil. certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -p '<pfx password>' -importpfx '<pfxfilepath>'

While this is an effective method, certutil is actually not recommended for use on production environments by Microsoft. Having vCert return the cert with a specified provider would avoid needing to go against recommended practice from Microsoft on this.

[BeardedPrincess]

@dcherry88

Thanks for the extra information. I did some investigation into how this works. Microsoft allows for a specific attribute to be added to the PKCS#12 private key bag (1.3.6.1.4.1.311.17.1) that is used to provide a hint when importing the PFX into windows. Any other system simply ignores that (or should.. there are instances where some crypto libraries don't like to see that extra attribute).

Since vCert is built to be compiled across multiple OSes, we use standard crypto libraries to accomplish that. As a result, we are not setting the CSP attribute (1.3.6.1.4.1.311.17.1) at all. This forces Microsoft to make a decision about what CSP to use, based on the logic detailed here: https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-pfximportcertstore#remarks . Adding that attribute (which I'm not sure is even possible with the standard go crypto libraries) could create compatibility problems with non-MS applications, and since we are creating a standard PKCS#12 file, it may not be desirable to set that. There are controls (as you mentioned) available upon importing the PKCS#12 file into CAPI to override the resulting CSP that the key will be stored in.

With that said, when I think about the functionality of installing a certificate into the windows CAPI store directly (as vCert does with the CAPI installation section of the playbook functionality) it does make sense to be able to specify the CSP there. In fact, I have done some investigation around this to not only be able to import to a specific CSP, but use a specified CSP to generate the key and CSR. This approach will be required to support TPM key generation and storage.

I'll keep this open as we pursue that functionality in the upcoming releases.