The certificate generated is not applicable for Exchange 2013

[pkisharp]

The certificate generated is not applicable for Exchange 2013

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

[GeorgeSchiro]

First, I don't mean to pile on because I think the work you've done here is terrific Tom. Thank you for making such a valuable contribution to the developer community. And please let me know if my next comments would be more appropriate elsewhere.

I have seen the same issue reported by Slamich and I independently arrived at the same solution (ie. "openssl.exe"). I am fine with leaving it at that.

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

This is my real concern.

I am sure there are many others who migrated to "ACME-PS" from "ASMESharp" (who are also very grateful for your efforts Tom). With that migration in mind I have been wondering about something else.

One nice feature of "ASMESharp" was its "stateless" implementation (ie. it saved 100% of its own state to disk). That approach allowed its various commands to be run independently in multiple (ie. separate) Powershell sessions (one after another) without concern for losing state.

"ACME-PS" does not allow this. While "ACME-PS" saves some of its state to disk, the balance requires the use of temporary in-memory PS variables. That means users must complete the entire process in a single Powershell session.

Can you please explain that design choice Tom? Is there an easy way to arrive at a similar "stateless" approach (ie. similar to how "ASMESharp" manages 100% of its own state itself) ?

[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