Bug 497788 - [RFE] way to load default root certificates
Summary: [RFE] way to load default root certificates
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nss_compat_ossl
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-27 09:10 UTC by Kamil Dudka
Modified: 2009-05-09 04:04 UTC (History)
4 users (show)

Fixed In Version: 0.9.5-2.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-02 16:35:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
proposed patch (lacking SECMOD_UnloadUserModule/SECMOD_DestroyModule for now) (1.08 KB, patch)
2009-04-27 09:10 UTC, Kamil Dudka
no flags Details | Diff
strace output (4.92 KB, application/octet-stream)
2009-04-27 14:26 UTC, Kamil Dudka
no flags Details
Implement SSL_CTX_set_default_verify_paths() (2.14 KB, patch)
2009-04-29 02:59 UTC, Rob Crittenden
no flags Details | Diff

Description Kamil Dudka 2009-04-27 09:10:48 UTC
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

Comment 1 Rob Crittenden 2009-04-27 13:32:26 UTC
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?

Comment 2 Kamil Dudka 2009-04-27 14:26:33 UTC
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?

Comment 3 Rob Crittenden 2009-04-27 15:00:28 UTC
Is elinks calling SSL_CTX_load_verify_locations() with the bundle?

If not, I wonder how this works with OpenSSL.

Comment 4 Kamil Dudka 2009-04-27 15:22:19 UTC
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!

Comment 5 Kamil Dudka 2009-04-28 09:34:02 UTC
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.

Comment 6 Rob Crittenden 2009-04-28 14:19:55 UTC
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.

Comment 7 Bob Relyea 2009-04-28 22:50:37 UTC
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

Comment 8 Bob Relyea 2009-04-28 22:54:40 UTC
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.

Comment 9 Rob Crittenden 2009-04-29 00:40:47 UTC
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().

Comment 10 Rob Crittenden 2009-04-29 02:59:23 UTC
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.

Comment 11 Kamil Dudka 2009-04-29 11:47:40 UTC
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.

Comment 12 Rob Crittenden 2009-04-29 13:52:37 UTC
Committed upstream:

Sending        ChangeLog
Sending        src/ssl.c
Transmitting file data ..
Committed revision 73.

Comment 13 Fedora Update System 2009-04-29 14:43:48 UTC
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

Comment 14 Fedora Update System 2009-04-29 14:43:58 UTC
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

Comment 15 Fedora Update System 2009-04-29 14:44:08 UTC
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

Comment 16 Bob Relyea 2009-04-29 18:23:45 UTC
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

Comment 17 Fedora Update System 2009-05-02 16:35:22 UTC
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.

Comment 18 Fedora Update System 2009-05-02 16:36:31 UTC
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.

Comment 19 Fedora Update System 2009-05-09 04:03:57 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.