[SNIP] >> However this looks like the key is encrypted with 3DES, but I "exported" it >> from the Cert+Key with "-aes256" - so I'm puzzled why I'd have a 3DES >> encrypted p12.
DT> You thought you did but you didn't. DT> The doc is a bit subtle, but the -$cipher option is listed under "PARSING". DT> It applies when *reading* a PKCS#12 and extracting the cert(s) and key(s?) DT> to separate files or sections, for (most) other OpenSSL operations, and DT> specifically to encrypting the extracted privatekey section. DT> To specify the PBE algorithm for the key when exporting *to PKCS12*, DT> use -keypbe, as listed on the man page under "EXPORTING". DT> And yes, it isn't very helpful that commandline doesn't warn when you DT> specify a combination of options that doesn't make sense. This is true DT> for most of the commandline functions historically, although a few that DT> have been (re)written recently are better. Ah, that makes sense. A little quibble - not with the answer but with the way the command line tool works. I probably paid less attention to the man page than I should have since it *looked* like in the pkcs12 utility "-aes256" was just like "-v2 aes256" in the pkcs8 utility - but as you state, it's not. As stated, the switch in one is an "input" to the cypher, but an "output" for the other. Gack! [It's probably too late to do something different in the PKCS12 tool, but changing the way the switches work to make the two sub-tools operate in a more consistent way might be a good goal.] I'd guess that, even if I had read the manpage more carefully, I'd never have reached the conclusion that -aes256 wasn't going to do what I wanted. [To me, it was just "obvious" what it did, and I would have never questioned that assumption even though it was obvious it wasn't working like I thought and I was "obviously" wrong!] This was the last piece I needed - I can put this thing to bed now. Thanks again to all for all your great help! -Greg
