I have a folder with a private key file, certificate file, and a subfolder with several root certificate files.
I have concatenated the latter into the file
If I create a pkcs12 certificate out of this using:
openssl pkcs12 -out WILDCARD_clientco_com.pfx -export -passout file:password.txt -aes256 \ -in WILDCARD_clientco_com.crt -inkey private.key -certfile Root\ Certificates/all.crt \ -name 'Wildcard ClientCo' -caname 'Intertrust' -caname 'RootTrust' -keyex -macalg sha512 -CSP 'Inicorp'
Then it will fail to import on a windows-PC using Microsoft's own tools with the message that the password is invalid. If I instead execute this command:
openssl pkcs12 -out WILDCARD_clientco_com.pfx -export -passout file:password.txt -aes256 \ -in WILDCARD_clientco_com.crt -inkey private.key -certfile Root\ Certificates/all.crt \ -name 'Wildcard ClientCo' -caname 'InterTrust' -caname 'RootTrust' -keyex -CSP 'Inicorp'
Then the pkcs12 cert imports successfully.
Now the default value for the argument
sha1. This has been deprecated as a digest/mac algorithm. Standard recommendation is to now use sha2. Typically sha256 or stronger. Is the fact that Windows certificate import only seems to accept sha1 hashes, failing when I try the value
sha384 or like in the example
- A bug/omission in the windows certificate store?
- A bug in openSSL?
- Does the command need to be modified in some other way to make that work?
- Or is it not used for security, just for e.g. a hash table lookup, and therefore it's fine/better to use the faster sha1 anyway?
Edit: Tried this with multiple versions of openSSL. Both 1.0.2, 1.1.0, and 1.1.1 have the same issue.