So I have something I can’t explain and am hoping you guys can!
If I use the ‘Export Private Key’ Deployment Task for a particular certificate, I end up with a different private key from that extracted (using Open SSL) from the PFX that Certify automatically deployed to my local store (which I exported using the Windows Certificate Export Wizard).
To be clear, this is after I have decrypted the key that I extracted from the exported PFX. Surely they should be the same should they not?
FYI, the Primary and Intermediate certificates are the same when using the ‘Export’ Deployment Task and extracting them from the PFX, it is just the private keys that are different.
Also: I have tried to use the ‘Export PFX Deployment Task’ to save a local copy of the PFX certificate and then use Open SSL to extract the key from that file (to check it against the key in the ‘Windows exported’ PFX file) however I get an “Error outputting keys and certificates” error. There is no PFX password set in the Signing & Security section (either now or when I generated the certificate).
Please can you help me unravel this?
I want to be certain which Private Key I should be using: the one extracted from the ‘Windows’ PFX file or the one exported directly in PEM from Certify?
Would be grateful of an early reply if possible as this is in relation to an expired certificate which I obviously want to correct ASAP!
It depends how you are extracting the private key from the PFX (what command you are using and how exactly are you checking the key) as there are different PKCS versions and they may look different?
Double check you are using the current version (6.0.18), we do have a new release coming this week or next that has a fix for PEM export over SSH but if this is not a copy over SSH then it won’t be affected.
Yes, the private key should be the same type (e.g. RSA or EC) and should verify as being the private key for your certificates public key. We don’t have any general reports of key export issues.
The real test is to try both and see which one works.
The PFX exported from the certificate store is not the binary equivalent of the PFX we build and store under C:\ProgramData\certify\assets (and the one that gets exported by the Certiicate Export task when you select PFX).
The PFX archive exported from the local machine certificate store is reformed by windows using their code, and ours is built in .net using a library called bouncycastle so things like archive order will be different. However the public and private keys etc will be the same information.
A thing to remember with OpenSSL is that v3 onwards considers typical windows PFX files to be their --legacy format due to the older algorithm choices for encryption and hashing.
Thank you very much for your helpful response. That absolutely put me on the right path to resolving my issue!
For anybody else with a similar question in the future:
I used the -legacy -provider -path option (for my install the legacy.dll file was at: C:\Program Files\OpenSSL-Win64\bin) to specify the legacy provider in openssl and used that to extract the key (using pkcs12 command) from the ‘deployment task exported’ version of the PFX as well as the version stored in c:\ProgramData\certify\assets.
I then compared the modulii of both of these .KEY files (using command: openssl rsa -in [filename].key -noout -modulus) and the modulii of the ‘deployment task exported’ private_key.KEY file and the .KEY file extracted from the ‘windows certificate store’ PFX with the modulii (command: openssl x509 -in [filename].crt -noout -modulus) of the .CRT files extracted from the aforementioned three .PFX files and the ‘deployment task exported’ .CRT file.
The modulii from ALL of the above where exactly the same. Therefore proving (I believe! - correct me if I am wrong) that however the private key is obtained and even if the binary format text of the KEY file is different (see my OP), the extracted/exported keys will all work with the extracted/exported certificates.
Reading this back, it all seems rather garbled and complicated but I think it should make sense to anybody who has been on a similar journey to me (or just knows about this stuff!).
Glad it’s working for you! For anyone who happens to use an Elliptic Curve private key instead of RSA you’ll find you need slightly different technique (which does both RSA and EC keys), most examples assume RSA, which is becoming a little dated:
