Description of problem: Accessing https://www.flores-associates.com/ results in the message "This Connection is Untrusted." The "Technical Details" section says: www.flores-associates.com uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) However, the certificate chain appears to be valid. Version-Release number of selected component (if applicable): nss-3.12.6-7.fc12 How reproducible: 100% Steps to Reproduce: Point Firefox to https://www.flores-associates.com Actual results: SSL problem Expected results: No problem. Web page should load. Additional info: Downloading the certificate chain with "openssl s_client -connect www.flores-associates.com:443" results in the following chain: depth=3 C = US, ST = UT, L = Salt Lake City, O = The USERTRUST Network, OU = http://www.usertrust.com, CN = UTN - DATACorp SGC depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO High-Assurance Secure Server CA depth=0 C = US, postalCode = 28231, ST = NC, L = Charlotte, street = PO Box 31397, O = Flores & Associates, OU = EliteSSL, CN = www.flores-associates.com Certificate chain 0 s:/C=US/postalCode=28231/ST=NC/L=Charlotte/street=PO Box 31397/ O=Flores & Associates/OU=EliteSSL/CN=www.flores-associates.com i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/ CN=COMODO High-Assurance Secure Server CA 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/ CN=COMODO High-Assurance Secure Server CA i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/ CN=AddTrust External CA Root 2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/ CN=AddTrust External CA Root i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/ OU=http://www.usertrust.com/CN=UTN - DATACorp SGC The issuer of certificate #2 in the chain ("AddTrust External CA Root") is already in Firefox's CA database, so the certificate chain should be valid, but it seems to be rejected for some reason.
For what it's worth, I can access the Web site in RHEL 5.5 with firefox-3.0.16-1.el5_4 and nss-3.12.3.99.3-1.el5_3.2
I can access it with firefox-3.5.11-1.fc12.x86_64, nspr-4.8.4-2.fc12.x86_64, and nss-3.12.6-7.fc12.x86_64
Interesting. I'm still denied access with: # rpm -q firefox nspr nss firefox-3.5.11-1.fc12.x86_64 nspr-4.8.4-2.fc12.x86_64 nss-3.12.6-7.fc12.x86_64
This is trange we have the same versions of firefox, nspr and nss. I bet your system is far from pristine. I tried also on a RHEL-6 Beta 2 system and Fedora 13 without any problems. I used relatively clean virtual sytem. I had export NSS_DEFAULT_DB_TYPE="sql" on and tried with it commented out on my ~/.bashrc file so legacydb versus shared db doesn't matter, not that we expect it to matter at all.
Bryan, could you please try it with curl? Does it make any difference? $ curl -svo/dev/null https://www.flores-associates.com
(In reply to comment #5) > Bryan, could you please try it with curl? Does it make any difference? > $ curl -svo/dev/null https://www.flores-associates.com I performed the suggested test and it fails whereas it was working using the broser. Here are my annotated results I connect via curl [emaldona@localhost ~]$ curl -svo/dev/null https://www.flores-associates.com * About to connect() to www.flores-associates.com port 443 (#0) * Trying 63.243.17.132... connected * Connected to www.flores-associates.com (63.243.17.132) port 443 (#0) * Initializing NSS with certpath: /etc/pki/nssdb * WARNING: failed to load NSS PEM library libnsspem.so. Using OpenSSL PEM certificates will not work. * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * Peer's certificate issuer is not recognized: 'CN=COMODO High-Assurance Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB' * NSS error -8179 * Closing connection #0 * Peer certificate cannot be authenticated with known CA certificates Notice the "WARNING: failed to load NSS PEM library libnsspem.so." Something is preventing the PEM module from getting loaded. I have a suspect. I then check to see if nssysinit module is enabled [emaldona@localhost ~]$ sudo cat /etc/pki/nssdb/pkcs11.txt | grep library library=libnsssysinit.so It is enabled, Let's then turn it off. [emaldona@localhost ~]$ sudo /usr/bin/setup-nsssysinit.sh off And verfiy it is off. [emaldona@localhost ~]$ cat /etc/pki/nssdb/pkcs11.txt | grep library library= This tells me that it is disabled. Repeat the test [emaldona@localhost ~]$ curl -svo/dev/null https://www.flores-associates.com * About to connect() to www.flores-associates.com port 443 (#0) * Trying 63.243.17.132... connected * Connected to www.flores-associates.com (63.243.17.132) port 443 (#0) * Initializing NSS with certpath: /etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSL connection using SSL_RSA_WITH_RC4_128_MD5 * Server certificate: * subject: CN=www.flores-associates.com,OU=EliteSSL,O=Flores & Associates,OID.2.5.4.9=PO Box 31397,L=Charlotte,ST=NC,postalCode=28231,C=US * start date: Jul 15 00:00:00 2010 GMT * expire date: Jul 14 23:59:59 2013 GMT * common name: www.flores-associates.com * issuer: CN=COMODO High-Assurance Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB > GET / HTTP/1.1 > User-Agent: curl/7.20.1 (x86_64-redhat-linux-gnu) libcurl/7.20.1 NSS/3.12.6.2 zlib/1.2.3 libidn/1.16 libssh2/1.2.4 > Host: www.flores-associates.com > Accept: */* > < HTTP/1.1 200 OK < Server: Microsoft-IIS/4.0 < Content-Location: https://www.flores-associates.com/index.html < Date: Tue, 03 Aug 2010 14:52:38 GMT < Content-Type: text/html < Accept-Ranges: bytes < Last-Modified: Thu, 17 Apr 2008 13:57:38 GMT < ETag: "035c4fe92a0c81:a0d0" < Content-Length: 11881 < { [data not shown] * Connection #0 to host www.flores-associates.com left intact * Closing connection #0 ------------------------ This time it works. The nss-sys-init module being active seesm to be preventing the pem module from getting loaded. I have also observed the failure to load the PEM module on and off while testing a patch I'm working on to make the PEM module automatically loadable by nssysinit.
(In reply to comment #6) > I performed the suggested test and it fails whereas it was working using the > broser. Here are my annotated results Sure, FF does not use libnsspem.so to load root CA certificates, curl does. That's it. If it stopped working after an update of nss, you should look for the problem in nss. I am not aware of any changes in libcurl itself, except the one for NTLM support, which required the NSS initialization scheme to be slightly changed: http://github.com/bagder/curl/commit/f3b77e5
It is a bug in nss-sysinit and we seem to have a fix thanks to the patch contributed by David Woodhouse for [Bug 603313] that I have been testing. I was able to connect okay with nss-sysinit turned on once I tried the nss build with his patch.
nss-3.12.6-9.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc14
nss-3.12.6-9.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc13
nss-3.12.6-9.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc14
nss-3.12.6-9.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-9.fc13
nss-3.12.6-11.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc14
nss-3.12.6-11.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc14
nss-3.12.6-11.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc12
nss-3.12.6-11.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/nss-3.12.6-11.fc13
nss-3.12.6-12.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc14
nss-3.12.6-12.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc13
nss-3.12.6-12.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/nss-3.12.6-12.fc12
nss-3.12.6-12.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.12.7-3.fc14,nss-softokn-3.12.7-3.fc14,nss-util-3.12.7-2.fc14,nspr-4.8.6-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nss-3.12.7-3.fc14,nss-softokn-3.12.7-3.fc14,nss-util-3.12.7-2.fc14,nspr-4.8.6-1.fc14
nss-3.12.6-12.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
nss-3.12.7-4.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nss-3.12.7-4.fc14
I'm still getting an Untrusted Connection message when I try to open https://www.flores-associates.com/ in Firefox. When I get the certificate and view the certificate hierarchy, it looks like: UTN - DataCorp SGC AddTrust External CA Root UTN - DataCorp SGC AddTrust External CA Root UTN - DataCorp SGC AddTrust External CA Root UTN - DataCorp SGC AddTrust External CA Root UTN - DataCorp SGC AddTrust External CA Root UTN - DataCorp SGC AddTrust External CA Root UTN - DataCorp SGC AddTrust External CA Root UTN - DataCorp SGC AddTrust External CA Root UTN - DataCorp SGC AddTrust External CA Root COMODO High-Assurance Secure Server CA www.flores-associates.com The error on the Certificate Viewer window says "Could not verify this certificate for unknown reasons. curl seems able to work properly, though: [bjmason@bjmason ~]$ curl -svo /dev/null https://www.flores-associates.com * About to connect() to www.flores-associates.com port 443 (#0) * Trying 63.243.17.132... connected * Connected to www.flores-associates.com (63.243.17.132) port 443 (#0) * Initializing NSS with certpath: /etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSL connection using SSL_RSA_WITH_RC4_128_MD5 * Server certificate: * subject: CN=www.flores-associates.com,OU=EliteSSL,O=Flores & Associates,OID.2.5.4.9=PO Box 31397,L=Charlotte,ST=NC,postalCode=28231,C=US * start date: Jul 15 00:00:00 2010 GMT * expire date: Jul 14 23:59:59 2013 GMT * common name: www.flores-associates.com * issuer: CN=COMODO High-Assurance Secure Server CA,O=COMODO CA Limited, L=Salford,ST=Greater Manchester,C=GB > GET / HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.6.2 zlib/1.2.3 libidn/1.9 libssh2/1.2.4 > Host: www.flores-associates.com > Accept: */* > < HTTP/1.1 200 OK < Server: Microsoft-IIS/4.0 < Content-Location: https://www.flores-associates.com/index.html < Date: Wed, 08 Sep 2010 17:38:35 GMT < Content-Type: text/html < Accept-Ranges: bytes < Last-Modified: Thu, 17 Apr 2008 13:57:38 GMT < ETag: "035c4fe92a0c81:a0d0" < Content-Length: 11881 < { [data not shown] * Connection #0 to host www.flores-associates.com left intact * Closing connection #0 But I don't seem to be loading the nssysinit either: [bjmason@bjmason ~]$ grep library /etc/pki/nssdb/pkcs11.txt library= If I turn it on: [bjmason@bjmason ~]$ su - -c '/usr/bin/setup-nsssysinit.sh on' Password: [bjmason@bjmason ~]$ grep library /etc/pki/nssdb/pkcs11.txt library=libnsssysinit.so curl still works: [bjmason@bjmason ~]$ curl -svo /dev/null https://www.flores-associates.com * About to connect() to www.flores-associates.com port 443 (#0) * Trying 63.243.17.132... connected * Connected to www.flores-associates.com (63.243.17.132) port 443 (#0) * Initializing NSS with certpath: /etc/pki/nssdb * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSL connection using SSL_RSA_WITH_RC4_128_MD5 * Server certificate: * subject: CN=www.flores-associates.com,OU=EliteSSL,O=Flores & Associates,OID.2.5.4.9=PO Box 31397,L=Charlotte,ST=NC,postalCode=28231,C=US * start date: Jul 15 00:00:00 2010 GMT * expire date: Jul 14 23:59:59 2013 GMT * common name: www.flores-associates.com * issuer: CN=COMODO High-Assurance Secure Server CA,O=COMODO CA Limited, L=Salford,ST=Greater Manchester,C=GB > GET / HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.6.2 zlib/1.2.3 libidn/1.9 libssh2/1.2.4 > Host: www.flores-associates.com > Accept: */* > < HTTP/1.1 200 OK < Server: Microsoft-IIS/4.0 < Content-Location: https://www.flores-associates.com/index.html < Date: Wed, 08 Sep 2010 17:48:50 GMT < Content-Type: text/html < Accept-Ranges: bytes < Last-Modified: Thu, 17 Apr 2008 13:57:38 GMT < ETag: "035c4fe92a0c81:a0d0" < Content-Length: 11881 < { [data not shown] * Connection #0 to host www.flores-associates.com left intact * Closing connection #0 And Firefox still fails. So is this some sort of configuration problem with my Firefox?
Well that's interesting. If I create a new Firefox profile and run Firefox with that profile, I can access the site with no problems.
nss-3.12.7-4.fc14, nspr-4.8.6-1.fc14, nss-util-3.12.7-2.fc14, nss-softokn-3.12.7-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.