GNOME Bugzilla – Bug 657247
Support encrypted PEM key files in GTlsCertificate
Last modified: 2018-05-29 06:45:18 UTC
And use g_tls_interaction_ask_password() to prompt for their password when needed. Need to look at how this would be done in the gnutls backend.
It turns out that gnutls doesn't support the specific encrypted format that openssl uses (which nobody else really supports). So we would need to use PKCS#8, which is the standard anyway (and gnutls uses that). We should support both the encrypted and non-encrypted PKCS#8. Looking this over quickly. Here's what this would involve in glib: * Extending parse_private_key() in gtlscertificate.c to detect the new PEM header(s) as a valid private key type. And here's what it would involve in glib-networking: * Change g_tls_certificate_gnutls_get_key(), to accept a GTlsInteraction and be able to return an error. * Changing around GTlsCertificateGnutls so it doesn't try to import the key into gnutls until the key is asked for via g_tls_certificate_gnutls_get_key() * In g_tls_certificate_gnutls_get_key() use the GTlsInteraction ask_password() to prompt for a password if it's an encrypted key, and pass that password to gnutls_x509_privkey_import_pkcs8() Hmmm, but it looks like there is a showstopper. Unlike libgcr's GcrParser which automatically detects the format, gnutls_x509_privkey_import_pkcs8() wants the exact encryption format of the key. This makes it pretty much unusable. Groan... I'll have to think about this some more. Maybe the best solution is just to use the PKCS#11 database for anything but the simplest of use cases (ie: which would be the current unencrypted keys).
(In reply to comment #1) > So we would need to use PKCS#8, which is the standard anyway (and gnutls uses > that). We should support both the encrypted and non-encrypted PKCS#8. PKCS is good. Might want PKCS#12 support at some point too. > Hmmm, but it looks like there is a showstopper. Unlike libgcr's GcrParser which > automatically detects the format, gnutls_x509_privkey_import_pkcs8() wants the > exact encryption format of the key. This makes it pretty much unusable. Well, you can just try parsing it with each format until you don't get back a "can't parse" error? > Maybe the best solution is just to use the PKCS#11 database for anything but > the simplest of use cases (ie: which would be the current unencrypted keys). Random (possibly dumb) thought: could you import PKCS#8/12 files as GTlsDatabases instead of as GTlsCertificates?
(In reply to comment #2) > > Maybe the best solution is just to use the PKCS#11 database for anything but > > the simplest of use cases (ie: which would be the current unencrypted keys). > > Random (possibly dumb) thought: could you import PKCS#8/12 files as > GTlsDatabases instead of as GTlsCertificates? Yes, that might be possible. I've actually been tossing around the idea of a simple PKCS#11 module that exposes multiple PKCS#8/#12/PEM files as different slots. But a GTlsDatabase might work well too. In fact we could extend GTlsFileDatabase with support for loading files other than the anchors.
We now at least support unencrypted PKCS#8 keys (bug 664321)
I think GnuTLS does now support the OpenSSL encrypted format. If not, it's certainly handled by import_openssl_pem() in OpenConnect's openssl.c.
Er, in OpenConnect's gnutls.c I mean: http://git.infradead.org/users/dwmw2/openconnect.git/blob/35542d52:/gnutls.c#l711
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/441.
Reopening. This bug was migrated to https://gitlab.gnome.org/GNOME/glib, but it should have been migrated to https://gitlab.gnome.org/GNOME/glib-networking.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib-networking/issues/29.