Created attachment 341408 [details] proposed patch (lacking SECMOD_UnloadUserModule/SECMOD_DestroyModule for now) Description of problem: This problem was encountered while porting elinks to nss_compat_ossl. We want to enable "connection.ssl.cert_verify" elinks option by default. But nobody can use it if there are no default root certificates available. It works fine when SSL_DIR is set to Firefox NSS database, but it needs to be manually configured by user and moreover it depends on Firefox which is unacceptable. I've written a simple patch for nss_compat_ossl which makes elinks working. Maybe it is not good idea to load the certificates by default, but it should be definitely possible to do it through nss_compat_ossl API (not good idea at all to mix nss_compat_ossl API calls with direct nss API calls). When I was looking for proper place for SECMOD_UnloadUserModule/SECMOD_DestroyModule I spot there isn't any call of NSS_Shutdown(). It is ok? Note the patch was inspired by this part of xulrunner: http://xulrunner.sourcearchive.com/documentation/1.9.0.1-1/nsNSSComponent_8cpp-source.html Version-Release number of selected component (if applicable): nss_compat_ossl-0.9.5-2 Steps to Reproduce: 1. enable "connection.ssl.cert_verify" elinks option 2. elinks https://bugzilla.redhat.com Actual results: we can see the "SSL error" dialog Expected results: displayed web page with trusted certificate
The pem module should be providing this capability by loading the OpenSSL CA bundle. Can you tell if the pem module not being loaded or is the bundle not being added?
Created attachment 341434 [details] strace output The pem module seems to be loaded, but /etc/pki/tls/certs/ca-bundle.crt is not accessed - the strace output is attached. Should I change something within elinks code to load it?
Is elinks calling SSL_CTX_load_verify_locations() with the bundle? If not, I wonder how this works with OpenSSL.
AFAIK not, though it works and loads the certificates from /etc/pki/tls/cert.pem. I'll look at it deeper tomorrow and report here. Thanks!
It calls SSL_CTX_set_default_verify_paths() instead, which is not implemented by nss_compat_ossl. No problem for me to fix it within elinks by some #ifdef directives, but it might be reason to implement if elinks is not the only affected application.
It isn't yet defined but it seems to me that the loading of libnssckbi.so you wrote fits the implementation perfectly. Bob, will we create problems if the root cert list is already loaded and we try to reload it? It seems to me that the load will fail and we won't have a handle to it. The downside is that we won't be able to differentiate between failures because the module is already loaded vs another reason for failure (not found, bad permissions, sun spots, etc). Can we use something like SECMOD_GetDBModuleList() to see if the root certs are already loaded? I'm not very familiar with that part of the API.
There's an NSS call that tells you if a Builtin Root certs module is already loaded.... PRBool SECMOD_HasRootCert(). BTW on Fedora 12, I'm working to arrange that a number of databases, including the built-in root certs, are automatically loaded when you open /etc/pki/nssdb. bob
BTW, you can also force root cert loading today from /etc/pki/nssdb by creating a symbolic link ln -s /usr/lib/libnssckbi.so /etc/pki/nssdb. This is a bit of a hack which we added serveral years ago to keep some servers happy. You can also use modutil to add libnsscki to /etc/pki/nssdb/secmod.db. Both of these options are user admin options, not really an option for applications.
Ok, the HasRootCert() seems the way to go. We can't be sure that the database will be /etc/pki/nssdb, though we can make that the default at some point I guess. Whatever solution we come up with needs to work equally well when we do an NSS_Init("/path/to/database") and NSS_NoDBInit().
Created attachment 341689 [details] Implement SSL_CTX_set_default_verify_paths() This roughly takes Kamil's patch and stuffs it into SSL_CTX_set_default_verify_paths(). I changed the way the configstring is passed because NSS may modify the string (it parses internally). Since we'll have 2 modules I also renamed mod to pemMod for clarity. It tests out ok with elinks for me.
I've changed elinks to be able to load CA certificates from file in PEM format (to be consistent with the GnuTLS variant of elinks) by calling SSL_CTX_load_verify_locations(). And if the configuration option connection.ssl.trusted_ca_file is an empty string, it calls SSL_CTX_set_default_verify_paths() to load NSS default root certificates. It works now in both cases with your patch for nss_compat_ossl, built as elinks-0.12-0.15.pre3.fc12.
Committed upstream: Sending ChangeLog Sending src/ssl.c Transmitting file data .. Committed revision 73.
nss_compat_ossl-0.9.5-3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/nss_compat_ossl-0.9.5-3.fc10
nss_compat_ossl-0.9.5-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/nss_compat_ossl-0.9.5-2.fc11
nss_compat_ossl-0.9.5-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/nss_compat_ossl-0.9.5-2.fc9
re comment 9. OK. if you open with No_DB_init, your only option is to hand load the module. For Fedora 12, we should change it to always open /etc/pki/nssdb (even if you continue to support loading other root certs through pem). That will allow us to use the work I'm doing in Fedora 12 to manage all the applications from a single point. bob
nss_compat_ossl-0.9.5-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
nss_compat_ossl-0.9.5-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
nss_compat_ossl-0.9.5-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.