Ok, so I know this isn't strictly an OpenSSL question, so I apologize - but I'd
guess someone here knows the answer, or can direct me to the correct resource.
[I've done a lot of searches, but no real luck.]
I'm trying to import both a private key and certificate generated with OpenSSL
into a Windows client. [Lets assume Win7 and 8]
It looks like p12 files are probably the best way to go. [Glad to stand
corrected, but that's what it looks like to me.]
So, I've cranked out a p12 file [converted from seperate PEM files, also
initially generated with OpenSSL] with the client-private-key and client-cert
inside.
(Like so: openssl pkcs12 -keypbe aes-256-cbc -export -inkey infile.key -in
infile.crt -out outfile.p12)
I initially tried encrypting it with "-keypbe aes-256-cbc" - however Windows
barfs on it. [This should encrypt the p12 with AES-256, I think.]
I did it again, using "-descert" [which, AFAICT should encrypt with 3DES]
(Like so: openssl pkcs12 -descert -export -inkey infile.key -in infile.crt -out
outfile.p12)
Windows likes this second one.
While 3DES is probably "good enough" - I'd rather use AES-256.
So the root of my question is:
1) What formats can Windows [7/8] accept? [Pointers somewhere would be good -
google didn't help me find much.]
2) Is there some reasonable way to generate/convert the key/cert using OpenSSL,
to use something better than 3DES that Windows will accept?
TIA for any light you can shed on the situation.
[I have similar questions about OSX - so if you have data about OSX that would
be handy too. However, OSX isn't as critical to me at the moment, so I'm not as
exercised about it. :) ]
-Greg
So, a reply to myself - in hopes of helping someone else on the thread for the
future.
* - Windows indeed will not handle a .p12 cert+key with the PKCS5 v2 [i.e.
aes-256] encryption on it. It appears to only handle 3DES. [I didn't test every
possible PBE - just 3DES and AES256]
While I didn't specifically test it, I believe it will handle both the cert and
the key encrypted with 3DES [i.e. -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES
]
I believe, however, that I only tested the key encrypted with 3DES and the cert
with whatever the default is for -descert, not both with 3DES - but I'm 99%
sure it will work that way.
* - iOS will also not handle a p12 with AES-256, but will handle a key+cert
with 3DES for both. [i.e. -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES ]
* - OSX: I've yet to do any testing on OSX, but I'm glad to get any feedback
that anyone else has on that specific case.
* - Android: No detail.
* - Amiga: You fanbois are on your own! :)
My plan is simply to use the lowest common denominator - which is 3des.
Hopefully these clients will update their p12 import encryption types very
soon, since it's hard to get keys and certificates to devices in closed
environments where security is pretty assured. Using methods that may not be
totally secure would be a lot safer if the encryption methods were better. And
those "less safe" methods are really quite a lot easier.
Hope that helps someone.
-Greg
Oh, a final thing: I should have noted this...
The iOS test case was importing the p12 into the keychain. It might be that
using it directly in something like OpenVPN might well work fine. [But then
you'd probably simply use the PEM files.] Since my use case *is* OpenVPN - this
is relevant, but I felt using the KeyChain was the best route - so p12's are
the only option there.
The same essentially applies to Windows. The test case is using certmgr.msc to
import a p12. Something like OpenVPN using the PEM files directly will handle
AES-256 encrypted keys just fine. [And I've tested that [ASE-256 encrypted PEM
Keys] - and yes, it does work.]
-Greg
