RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 630103 - https://www.flores-associates.com results in untrusted connection
Summary: https://www.flores-associates.com results in untrusted connection
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nss
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Elio Maldonado Batiz
QA Contact: Aleš Mareček
URL:
Whiteboard:
: 643557 (view as bug list)
Depends On: 603313 619241 630101 643132 643557
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-03 17:30 UTC by Elio Maldonado Batiz
Modified: 2011-05-19 14:03 UTC (History)
7 users (show)

Fixed In Version: nss-3.12.9-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 619241
Environment:
Last Closed: 2011-05-19 14:03:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0692 0 normal SHIPPED_LIVE nspr, nss, nss-softokn, and nss-util bug fix and enhancement update 2011-05-19 09:37:17 UTC

Description Elio Maldonado Batiz 2010-09-03 17:30:30 UTC
+++ This bug was initially created as a clone of Bug #619241 +++

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.

--- Additional comment from bmason on 2010-07-29 14:17:05 EDT ---

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

--- Additional comment from emaldona on 2010-07-29 15:23:58 EDT ---

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

--- Additional comment from bmason on 2010-07-29 18:00:13 EDT ---

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

--- Additional comment from emaldona on 2010-07-30 12:56:03 EDT ---

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.

--- Additional comment from kdudka on 2010-08-03 09:10:10 EDT ---

Bryan, could you please try it with curl?  Does it make any difference?

$ curl -svo/dev/null https://www.flores-associates.com

--- Additional comment from emaldona on 2010-08-03 12:09:26 EDT ---

(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.

--- Additional comment from kdudka on 2010-08-03 12:17:03 EDT ---

(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

--- Additional comment from emaldona on 2010-08-03 13:07:27 EDT ---

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.

--- Additional comment from updates on 2010-08-03 13:28:51 EDT ---

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

--- Additional comment from updates on 2010-08-03 14:57:53 EDT ---

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

--- Additional comment from updates on 2010-08-05 10:28:21 EDT ---

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

--- Additional comment from updates on 2010-08-05 19:32:53 EDT ---

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

--- Additional comment from updates on 2010-08-10 01:35:58 EDT ---

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

--- Additional comment from updates on 2010-08-10 22:56:00 EDT ---

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

--- Additional comment from updates on 2010-08-11 19:01:14 EDT ---

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

--- Additional comment from updates on 2010-08-11 19:01:31 EDT ---

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

--- Additional comment from updates on 2010-08-15 12:31:38 EDT ---

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

--- Additional comment from updates on 2010-08-15 12:36:44 EDT ---

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

--- Additional comment from updates on 2010-08-15 12:38:25 EDT ---

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

--- Additional comment from updates on 2010-08-19 21:31:21 EDT ---

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.

--- Additional comment from updates on 2010-09-02 11:42:18 EDT ---

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

--- Additional comment from updates on 2010-09-02 16:35:25 EDT ---

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.

Comment 2 Kamil Dudka 2010-10-15 23:47:34 UTC
*** Bug 643557 has been marked as a duplicate of this bug. ***

Comment 6 errata-xmlrpc 2011-05-19 14:03:28 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0692.html


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