FYI - PKS bundled certificates do not natively work with OpenSSL v3.x

Site Feedback
1

Hi @webprofusion,

This is more FYI rather than anything to think about immediately.

When using OpenSSL v3 (certain in Windows, but I guess also other OS) to analyse and covert a pks file generated through Certify the Web, you see an error due to the way it is packaged. Apparently, OpenSSL v3 doesn’t like older security algorithms. For example, if trying to extract the certificates from a “normal” pfx file, you may see the following error using OpenSSL 3.x:

PS C:\OpenSSL-Win64\bin\openssl.exe pkcs12 -in "my_old.pfx" -nodes
....
Error outputting keys and certificates
74800000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto\evp\evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()

Running info against this pfx give us some more, er, info :slightly_smiling_face:

C:\OpenSSL-Win64\bin\openssl.exe pkcs12 -in "my_old.pfx" -info -nokeys -nocerts
Enter Import Password:
MAC: sha1, Iteration 1024
MAC length: 20, salt length: 20
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1024
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 1024
Error outputting keys and certificates
8C9D0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto\evp\evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()

It appears as if you need to tell OpenSSL to use the legacy provider, however (and certainly in Windows) by default it doesn’t know where to get this provider dll. You, therefore, need to tell it where this is using the provider-path parameter, something like this:

PS C:\OpenSSL-Win64\bin\openssl.exe pkcs12 -in "my_old.pfx" -nodes -legacy -provider-path "C:\OpenSSL-Win64\bin"

However, you can be super cool and make things a bit simpler by adding an environment variable called OPENSSL_MODULES and pointing it to C:\OpenSSL-Win64\bin into the installer, so all you need to specify is the legacy option, which is at least not as much to remember and to type :slightly_smiling_face:

image

1 Like
2

I should say, there are mitigations in Certify the Web which perhaps means you do not need to worry about this. Back in the day, Certify didn’t have the ability to convert and export different certificate formats. This is now possible using a “Task”.

When I started using Certify, I converted certificates using OpenSSL as part of a PS script, for example (with the legacy option):

& C:\OpenSSL-Win64\bin\openssl.exe pkcs12 -in $result.ManagedItem.CertificatePath -out $CertPEMFile -nodes -passin pass: -legacy

This one line means I do not have to set a task on each managed certificate. and the file name is handled automatically. I use a simple line to take the PEM and export it back to a pks file, but with a password (something I could see as an option in the Task to export a certificate).

& C:\OpenSSL-Win64\bin\openssl.exe pkcs12 -in $CertPEMFile -export -out $CertPFXFile -passout pass:secret_password -legacy

TBH, not sure if I should actually use the legacy option here.

3

Interesting! Thanks for raising that. Our PFX build is via the Certes library which in turn uses the BouncyCastle library (a popular crypto/pki library). Looks like that defaults to sha1 etc which is probably great for compatibility but less so for modern security. I’ll look into that.

Yes, using the Deploy to Generic Server task is usually the easiest if all you want is a fullchain.pem and privatekey.pem (etc, there’s a few options or you can do more specific stuff using multiple Export Certificate tasks).

4

I’ve been looking at this more today and do have an possible update which would resolve the issue with OpenSSL but I need to decide what the best defaults should be going forward. Pkcs12StoreBuilder with AES256-SHA256 · Discussion #372 · bcgit/bc-csharp · GitHub

1 Like
5

Np @webprofusion - glad to give back a little :slight_smile:

FWIW, the Task to Create a PFX doesn’t allow you to specify a password (or at least I couldn’t see that option). Further, the saved PFX’s in the “Assets” folder are saved with blank passwords (hence my script lines above had to specify -passin pass: ). The script line to export a PFX at least allows me to define a password, albeit it is currently in plain text in the script :man_facepalming:. I would probably work around this.

Given these things contain private keys, it might be nice to allow user to specify a default password for the PFX’s stored in the Assets folder, and individual (or default) password of exported PFX (and I guess PEM bundle) certs.

1 Like
6

Yep, if you look under Certificate > Advanced > Signing & Security there is a password option at the bottom :slight_smile:

Once you set a password you need to re-request the certificate (or use the option to re-download the cert) in order to re-build the PFX, then run your task again.

7

Ahhhhhh - missed it :sweat_smile:

1 Like