1177987 - Client Certificate Authentication Failure with TLS 1.2

Status: RESOLVED INACTIVE

(NSS :: Libraries, defect)

Description

[hceuterpe]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150514102509

Steps to reproduce:

Windows 7 SP1 64-bit, Firefox ESR 38.  
(Note: a very similar defect was also found on RHEL 7.1 as they are also using ESR 38, here https://bugzilla.redhat.com/show_bug.cgi?id=1234693 .  This was fixed however with a newer version of NSS, view later comments for differences on updated packages.)

With TLS 1.2 vs. TLS 1.1  and 1.0 (SSL 3.0 disabled on given server):

TLS 1.2:
1. Remove all Firefox Security Devices except "Builtin Roots Module" and "NSS Internal PKCS #11 Module"
2. Import known working certificate into "Your Certificates".  This certificate is RSA 2048-bit, SHA-2 256-bit.
3. Confirmed this is the only certificate in "Your Certificates"
4. Import all unique CAs (particularly those that may have issued or was in the chain for the certificate imported in step 2).
5. Confirm Firefox is negotiating at TLS 1.2 by resetting "security.tls.version.max" (3).
6. Access known website requiring client certificate authentication, with TLS 1.2 enabled (minimum TLS 1.0 allowed).

7. Certificate selection Window pops-up, select certificate imported in step 2.
<Refer to "What happened? (actual results)">
 
With TLS 1.1:
Assuming steps 1-5 from TLS 1.2 are already done--
8.  Modify security.tls.version.max to '2' 
7. Attempt steps 6 and 7 again
Refer to <What should have happened? (expected results)">



Actual results:

TLS 1.2 result:
**Following error appears.**

Secure Connection Failed

The connection to the server was reset while the page was loading.

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.




Finally, confirm, initial encrypted handshake is established:
   Lock icon appears next to https in address bar with the following:
      Website Identity
         Website: FQDN.
         Owner (none at class 1 StartCom certs)
         Verified by:   StartCom Ltd.

      Technical details
         Connection Encrypted (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.2)


Expected results:

TLS 1.1 result:

**Successful access to the website, albeit at TLS 1.1 (or below).**


Finally, confirm, initial encrypted handshake is established:
      Technical details
         Connection Encrypted (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.1)

Would expect same with TLS 1.2.

Notes: Website function properly @ TLS 1.2 with Internet Explorer 11 and Chrome 42.  Firefox 38 ESR functions properly on RHEL 7.1 after Redhat RHSA-2015-1185 is applied.

Comment 1

[hceuterpe]

I'd like to report that on a hunch I have installed the latest Firefox 39 beta.  I can confirm this is effectively fixed with that.  Curiously, it appears the root fix is something that has been corrected in NSS 3.19.  As the RHEL 7.1 based fix for their Firefox 38 ESR involved also updating their NSS packages that are separate from Firefox itself to 3.19.  Firefox 39 also will bump to NSS 3.19.  Since Firefox 39 release date is so soon, I think I can say this bug is more of an informational bug than one that will persist...