Forgot to mention, website is enabled as client certificate required.

Kai, can you elaborate here please? Thanks!

I need more details.

What's the error message that firefox displays (technical details)?

Did it ever work with Firefox?
What's the last version of Firefox that previously worked for you?

If you were successful with an earlier version of Firefox, did that earlier version of Firefox work with TLS 1.2 enabled?

Ideally I'd need a trace of a failing connection to the server.

On the machine where you run firefox, you could run a local transparent proxy that can be used to produce a trace:

ssltap -s -l -p 1924 server-hostname:443 2>&1 | tee /tmp/ssltap.log

(replace server-hostname with the hostname that you see in the URL/location bar at the time firefox shows a failure message, excluding the http:// and /path parts. E.g., if the url bar shows https://somehost.somedomain.com/some/path then use somehost.somedomain.com )

While the ssltap utility is running, to produce the trace, enter the following address in firefox:
  https://127.0.0.1:1924

Firefox complains that the hostname will mismatch. Add a temporary override in Firefox to proceed anyway. Now you should see that trace information is printed on the console that runs the ssltap utility. The same information is also saved to file /tmp/ssltap.log

Please attach file ssltap.log to this bug, and please also answer my questions above. Thanks

Ok more details:


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.

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.

8. 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)

9. modify security.tls.version.max to '2' and completely exit Firefox.
10. Relaunch firefox and Attempt steps 6 through 8 again
Successful access to the website, albeit at TLS 1.1 (or below).
      Technical details
         Connection Encrypted (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.1)
Assumptions:
Website's certificate's CN matches the FQDN, and site attempted is https://FQDN
Server Certificate is issued to known and trusted third party (in my case Startcom Class 1 intermediary), as SHA-2 256-bit 2048-bit.

Also, the same website works on Windows 7 using latest version of IE11 and Chrome 42 (I think?)  as of 06-20-2015.  In fact with the same exact client certificate on a physical smart card even and both negotiate at TLS 1.2.  Not USB based, card based (but I have those as well).  Can't remember what the standard is (IEC 7816), but it looks like a credit card and using a Identiv SCR3311 USB card reader.

Chrome uses TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA  IE11 gets TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Also the card's PKCS#11 middleware on RHEL 7.1 recreates the exact same scenario assuming the imported certificate in step 2 is deleted, and the PKCS#11 is added back from being removed from step 1.  I did this as a sanity check to take the PKCS#11 middleware out of the potential cause.

Kai, is a packet trace still required?  If PFS is enabled, is a wireshark trace no good?  I can send you one perhaps by email, but I'd rather not post it on the bugzilla page directly for privacy reasons.

So good news!
Whatever is in this update appears to have to fixed it:
https://rhn.redhat.com/errata/RHSA-2015-1185.html

---> Package nss.x86_64 0:3.18.0-2.2.el7_1 will be updated
---> Package nss.x86_64 0:3.19.1-3.el7_1 will be an update
---> Package nss-sysinit.x86_64 0:3.18.0-2.2.el7_1 will be updated
---> Package nss-sysinit.x86_64 0:3.19.1-3.el7_1 will be an update
---> Package nss-tools.x86_64 0:3.18.0-2.2.el7_1 will be updated
---> Package nss-tools.x86_64 0:3.19.1-3.el7_1 will be an update
---> Package nss-util.x86_64 0:3.18.0-1.el7_1 will be updated
---> Package nss-util.x86_64 0:3.19.1-1.el7_1 will be an update

Another note, a certificate stored on a PKCS#11 device, and the same certificate loaded on that device, along with the PKCS #11 .so security device loaded: Prior to the nss updates this also failed.

However with the updates, that too is now working.

Finally, Firefox ESR 38 on Windows is also behaving similar as was with RHEL 7.1 Firefox ESR 38 without RHSA-2015-1185.
Cross posting for reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=1177987

Great, seems to be fixed now.