Glad I could help. To be honest, I had to play around with it for a bit before I remembered that RACF can export PEM-encoded PKCS#12, and how I had handled that the last time I went through this myself.
Also, having experience with figuring out what a file is using openssl asn1parse definitely helps. The last time I taught a class on key and certificate handling, we did an entire exercise on this, because we're always getting this sort of thing from customers. "Here's a zip with our key and certificate files", they say, and then there are files in it with names like "file0" and "key1", and it turns out "key1" is actually a certificate. Learning how to match private keys to certificates is also very useful; I actually ended up giving one customer a script to do that, because they'd been copying things from machine to machine and had really confused the situation. Someone needs to write a book like Surviving Cryptography with OpenSSL that covers these things, along the lines of Ivan Ristić's OpenSSL Cookbook. (I'd volunteer but to be honest it'd never get done.) I guess this sort of thing should go on the wiki; maybe some of it's there already. Anyway, back on the subject: I suppose technically this is not really PEM encoding, because the PEM delimiters lie. "----- BEGIN CERTIFICATE -----" claims that what follows is a Base64-encoded DER-encoded X.509 certificate, not a Base64-encoded DER-encoded PKCS#12 structure. Those are rather different things. I suspect RACF supports this because 1) it was easy and 2) it's convenient to have a text representation (that converts cleanly between EBCDIC and ASCII). But it's not technically correct. That's probably why OpenSSL doesn't support it; fake-PEM-PKCS#12 is a RACF idiosyncracy, as far as I know. I'm guessing Windows just takes whatever's between the PEM delimiters, decodes the Base64, parses it as ASN.1 DER, and then decides what to do. You could argue, by Postel's Interoperability Principle, that openssl should have a "-figure-out-the-format" option for every command that takes files. On the other hand, the Interoperability Principle is a security risk; many vulnerabilities are eliminated simply by requiring inputs that satisfy the specification. With a decent scripting language it's pretty easy to recognize one of these files and automatically extract it into something sensible. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Gary L Peskin Sent: Monday, March 13, 2017 10:26 To: openssl-users@openssl.org Subject: Re: [openssl-users] Cannot read exported PKCS12 cert and private key Thanks VERY much Michael. That did the trick. This was a homegrown CA cert and I needed it to sign a certificate request for testing purposes. I didn’t realize that the openssl pkcs12 utility didn’t support PEM encoding for input. I was a little confused I guess by the documentation which shows PEM encoding for “-in filename” but I see now that that’s for when exporting a PKCS#12 file, not for parsing one. Thanks again for clearing this up. It’s weird that MS supports this input format but openssl does not. I thought openssl could do EVERYTHING. 😊
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
