GNOME Bugzilla – Bug 507801
Certificates and private keys can be passed to libsoup only as file names
Last modified: 2010-11-09 16:13:14 UTC
Certificates and private keys have to be passed to libsoup as file names (using SOUP_SERVER_SSL_CERT_FILE, SOUP_SERVER_SSL_KEY_FILE and SOUP_SESSION_SSL_CA_FILE) but this somewhat inconvenient if you happen to have them already in memory. An improvement would be to accept a GInputStream or a GString containing the certificate.
Gnome 2.24 has been released, any update on the status of this bug?
the "ssl" branch in the libsoup git repo has a little bit of work on this. I was trying to fix all of the ssl issues at once, rather than adding new API specifically for this which would then later become deprecated. One way to handle this would be to figure out at least the broad outline of how the new SSL API will work, and then implement just a tiny bit of it for now, which (based on what's currently in the ssl branch) would probably mean something like: ssl = soup_ssl_client_new_from_data (data); session = soup_session_async_new_with_options (SOUP_SESSION_SSL_CLIENT, ssl, NULL); g_object_unref (ssl);
It may be worth knowing that gnome-keyring now supports certificate management (see comments on bug 585214) though it does a good job of hiding that from the user and the Seahorse tool doesn't yet know about it. Being able to tell libsoup to obtain the certificate from the gnome keyring, or pass an appropriate structure obtained from gnome-keyring, would be a big benefit.
NSS is working on a shared keystore with multi-application access to help with this: https://wiki.mozilla.org/NSS:Roadmap#SQLite-Based_Multiaccess_Certificate_and_Key_Databases See also Fedora's crypto consolidation efforts: http://fedoraproject.org/wiki/FedoraCryptoConsolidation
This will be fixed in 2.32/3.0 when we port to the new GIO TLS APIs (bug 588189), which allow constructing GTlsCertificates from files, PEM strings, or DER bytearrays. *** This bug has been marked as a duplicate of bug 634425 ***