Support non-RSA keys in OpenSSL-CAPI interop layer

[anrossi]

Export the desired certificate from the Windows Certificate Store as a PFX and then import the PFX into OpenSSL. This avoids needing to know anything about the certificate, besides its exportability, and simplifies the code nicely.
Also builds the certificate chain and adds it to the PFX for better OpenSSL performance.
Only supports exportable keys using a Key Storage Provider (KSP). Private keys using the older Cryptographic Service Provider (CSP) framework may not work.
Fixes #1942

[nibanks]

How important is this TODO?

[anrossi]

Not important enough for this PR, but a nice-to-have. AFAIK, this only works for software keys (no smartcard or TPM keys), and I think most software keys use the NCrypt Software KSP instead of the old CSP model.
There might be a user out there with a custom software CSP (particularly on pre-Windows 10 devices).

[nibanks]

Do we have the necessary automated tests to validate all these changes? If not, what would it take to get there? There are a lot of changes I don't have the expertise to validate by CR and it'd prefer to have tests do the rest.

[anrossi]

Do we have the necessary automated tests to validate all these changes? If not, what would it take to get there? There are a lot of changes I don't have the expertise to validate by CR and it'd prefer to have tests do the rest.

Our existing tests that run OpenSSL on Windows exercise this code path by loading test certificates from the Windows Certificate Store. The existing PFX loading/parsing logic has validation on Linux, and this now exercises that code path on Windows as well.

We don't have any test certificates with a chain length greater than 1, so the chain building logic is undertested (right now it just builds a chain with the end-entity certificate in it.) The chain building logic could be disabled until more extensive testing is available, if you prefer.