The certificate generated is not applicable for Exchange 2013

[Slamich]

Hi.
Generated a certificate using this module.
I get a PFX file that I import in Exchange 2013
It is imported with an invalid CSP provider:
"Microsoft Software Key Storage Provider"
And you need the provider to be:
"Microsoft Enhanced Cryptographic Provider v1.0"
or
"Microsoft RSA SChannel Cryptographic Provider"

Found a solution to work around this problem
openssl.exe pkcs12 -in certificate.pfx -out certificate.pem -nodes
openssl.exe pkcs12 -export -in certificate.pem -out new_certificate.pfx

After that, the certificate is imported with the desired provider:
"Microsoft Enhanced Cryptographic Provider v1.0"

Can you fix it?

[glatzert]

There might be a possibility during pfx export, but I'm not sure.
Also the CSPs you mention are appearantly "legacy" and MS-centric. The module itself is (or at least should be) x-plat.

If you can provide a PR, which does allow to set the CSP, I'll probably merge it.
I personally will not implement it, and since you have a working solution with openssl, there's no real need to include it in the module.

It'd also be possible to add documentation about import / export needs.

[Slamich]

The fact is that there were no such problems with the previous ASMESharp module.

[glatzert]

Ok. And?

[Slamich]

I do not quite understand what you need to provide so that you can turn on the provider.

[glatzert]

So far I can identify two places, where the provider might be selectable.
The first is the creation of the RSA-Key; the second is the export of the certificate.

This is the RSAKey: https://github.com/PKISharp/ACMESharpCore-PowerShell/blob/master/ACME-PS/internal/classes/crypto/RSAKey.ps1

And this the Export-Certificate internals:
https://github.com/PKISharp/ACMESharpCore-PowerShell/blob/master/ACME-PS/internal/classes/crypto/Certificate.ps1

Just to be clear, about my interests: I'm willing to help on the "merge-into-the-module"-side of things and carry it around in the module until it's not possible anymore, but I have very little interest in digging into the CSP specifics in windows myself - especially when there's already a valid tool (openSSL) to use and solve the problem.

[glatzert]

@GeorgeSchiro I moved you issue - thanks for pointing out. Discussion is welcome.
@Slamich - I'm sorry, if I was hostile, but I read your comment as "it was like that, and now I want you to implement it that way again" - I only assumed that, but since text is without tone, that might be a blatant misinterpretation of your intend.

If you have ideas how to tackle the problem or want to investigate the matter, I'll help if I can.

[phidevz]

@glatzert to me it seems like it is an "issue" coming from how the Microsoft Crypto library processes the "ExportWithPrivateKey" or whatever the function is called.
It seems that it uses the Cryptography Next Generation (CNG) and that might be the issue. Not sure tho. Maybe you can have at it (https://referencesource.microsoft.com/#System.Core/System/Security/Cryptography/X509Certificates/RSACertificateExtensions.cs) and implement it yourself using the "old" crypto API (not CNG)?

thanks in advance :)

[glatzert]

Currently ACME-PS is written as module, running in Windows Powershell as well as Powershell Core - the latter one being "the future" on all systems - especially when .NET 5.0 will be around.

I don't think, the old crypto API is compatible with .NET Core, meaning I'd probably have to build a special code-path to support the legacy crypto provider on WindowsPowershell only. That seems like a lot of work regarding, you can still use openSSL as a workaround.

Is there a prohibitive reason to not use openSSL?

openssl.exe pkcs12 -in certificate.pfx -out certificate.pem -nodes
openssl.exe pkcs12 -export -in certificate.pem -out new_certificate.pfx