GNOME Bugzilla – Bug 649326
Cannot handle PKCS#8 encrypted key
Last modified: 2011-05-18 22:23:33 UTC
Keys created with OpenSSL 1.0.0 onwards look like this: -----BEGIN ENCRYPTED PRIVATE KEY----- MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIupYn7Jb+t6YCAggA ... 7NvQH+Nw9HfQJQSGagEqvHTUr9aFABOZccSbWIAcXoiBM46R/0eDTOGv -----END ENCRYPTED PRIVATE KEY----- NetworkManager doesn't seem to handle these, when trying to use them for WPA2-TLS authentication. ** (nm-connection-editor:19410): WARNING **: Error: couldn't verify private key: 3 Unable to determine private key type.
Created attachment 187154 [details] [review] patch for nm-applet This fixes nm-applet but it still fails when libnm can't load the key.
Yeah, we need to get NSS and gnutls handling them as well in the libnm-util crypto code, so that we can make sure the given private key decrypts the shrouded PKCS#8 file, etc. It should be pretty close to the handling for PKCS#12 files, but that's also going to require some changes in nm-applet since for wifi for PKCS#12 (and probably #8) you need to ensure that the client cert and private key are always the same file, which is a wpa_supplicant restriction.
*** Bug 616910 has been marked as a duplicate of this bug. ***
So this is fun... All we really care about for PKCS#8 is whether a given file is a PKCS#8 file and if that key is encrypted, if the given password decrypts that key. But: 1) NSS doesn't handle PKCS8 natively; apparently you convert it to a PKCS#12 file and then import that 2) gnutls doesn't like the standard openssl key I made, with certtool bailing out with: certtool -k -8 --infile ~/Development/fdo/NetworkManager/libnm-util/tests/certs/pkcs8-enc-key.pem --password 1234567890 |<1>| PKCS encryption schema OID '1.2.840.113549.1.5.3' is unsupported. .libs/certtool: import error: The cipher type is unsupported. So fun fun fun. It's easy enough to tell if the file purports to be PKCS#8, but apparently not easy to verify that the given password unlocks the key itself.
Created attachment 187716 [details] [review] Patch to detect and check PKCS#8 private keys
Created attachment 187717 [details] [review] applet patch for pkcs#8 key detection
RH bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=702358
(In reply to comment #4) > 1) NSS doesn't handle PKCS8 natively; apparently you convert it to a PKCS#12 > file and then import that Hm. Isn't PKCS#8 support *added* to NSS by the patch at https://bugzilla.redhat.com/show_bug.cgi?id=614532#c0 ? > So fun fun fun. It's easy enough to tell if the file purports to be PKCS#8, > but apparently not easy to verify that the given password unlocks the key > itself. Well, we already do the decryption manually for the old-style OpenSSL encrypted PEM files; couldn't we do the same for PKCS#8? It's the *same* data and encryption, isn't it? But instead of the crypto algorthm and salt being given in an extra header, they're encoded in the ASN1 blob?
Yes, that patch apparently adds some support for PKCS8, but it's unclear right now how to actually use that and what calls we'd need to make to do so. I was hoping to create a temporary in-memory NSS database, and then simply import the private key into that database using the given password and if the operation returned success, consider the password + key valid. Update: (12:50:16 PM) richm: that patch doesn't add pkcs8 support to NSS, it just allows the libnsspem module to read pkcs8 files For the manual decryption question, the problem is that we can't get the stuff out of it that we need to decrypt it *because* it's ASN1. We don't have an ASN1 parser, and I don't really want to link to one either. The other problem is that PKCS#8 can use a whole bunch of ciphers, and we'd have to implement support for most of them, which means duplicating a bunch of code that I'd rather have in gnutls or NSS anyway.
nm commit: 5deb993ff6c1af007358038cb797d03456b34557 (master) applet: 9b30279c0a76f7ffb770cbce5e22d9644923b6ef (master) I'll backport to 0.8.x when I get a chance, it's a bit more involved there.