Since I upgraded Firefox to the version 38 I encounter problem while sending a certain form on the website https://usercenter.checkpoint.com/ Most of the website works normally but sending a form during opening a support ticket (URL in the log below) causes the Firefox to fail the TLS negotiation. The error page of Firefox explains almost nothing:
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.
Report this error
Reporting the address and certificate information for
usercenter.checkpoint.com will help us identify and block malicious
sites. Thanks for helping create a safer web!Automatically report errors in the future
Learn more…
In the web developer console I see only this:
19:58:44.470 This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.1 AjaxCall
19:58:44.589 POST https://usercenter.checkpoint.com/usercenter/portal/js_pane/supportId,CreateServiceRequestId [178ms]
The first line is just a warning that in the future SHA-1 will not be supported. Do I have to switch something on to see the cause of the TLS failure? The TLS and certificate information from the console is below:
I do not see anything wrong there. Out of despair I tried to play with the TLS parameters in about:config without success:
security.tls.insecure_fallback_hosts
security.tls.unrestricted_rc4_fallback
security.tls.version.fallback-limit
security.tls.version.max
security.tls.version.min
The Qualy SSL test does not show anything completely wrong: https://www.ssllabs.com/ssltest/analyze.html?d=usercenter.checkpoint.com
There is a promising article in the Red Hat knowledge base: Firefox 38 and SSL/TLS servers that are TLS version intolerant but the solution is available only to paying customers.
I have also checked Site Compatibility for Firefox 38.
Questions
- How can I troubleshoot what is the reason for the TLS failure?
- In Firefox are there any other user-configurable white lists where I can try to add the address of the failing website?
- What could be the reasons for the failure to appear only after sending a certain form while the console shows that the POST request goes to the same host
usercenter.checkpoint.comas the previous successful communication?
Best Answer
Use
openssl s_client. Its a swiss army knife for things like this. And useopenssl x509to dump certificates.You are usually interested in the
{Issuer, Subject}pairs in the chain like this:Notice how the issuer at the server becomes the subject for the next higher certificate. Gutmann provides the following diagram to describe it in his book Engineering Security:
At the top, the CA root is self signed, and the issue and the subject are the same. If there was a level 3, it would be:
But you usually don't see it in a chain because you must trust it. And part of the requirements for the trust anchor is you already have it to ensure its not tampered with.
Using Subject and Issuer names is utilizing what is called Distinguished Names. The other way to form a chain is with
KEYIDs. You will sometimes see it via Subject Key Identifier (SKI) and Authority Key Identifier (AKI). The key identifiers are just thumbprints of a digested public key.You can find reading on Distinguished Names in standards like RFC 4514; and using KEYIDs in standards like RFC 4518, which concerns itself with path building.
It appears the problem is with the browser (but see below). It looks like it is missing the
Class 3 Public Primary Certification Authoritywith thumbprinta1 db 63 93 91 6f 17 e4 18 55 09 40 04 15 c7 02 40 b0 ae 6b.When I visit Symantec Root Certifcates and download Class 3 Public Primary Certification Authority, I can build a path for validation (notice the
Verify return code: 0 (ok)below).You should download and install
Class 3 Public Primary Certification Authorityin your browser's trusted root store. Or determine why its not being used by the browser to build the path (see next).Mozilla and Firefox talk about
Class 3 Public Primary Certification Authorityin a blog post: Phasing out Certificates with 1024-bit RSA Keys. According to the post, they have deprecated that CA certificate since Firefox 32. I don't really fault them since these keys are used long term for CA signing operations, and they need "stronger" parameters because they have to live 10 to 30 years (literally).Checkpoint needs to get a new server certificate issued under a certificate (chain) with contemporary parameters, like a CA with a 4096-bit RSA moduli and SHA-256. Or a Subordinate CA with a 2048-bit RSA moduli and SHA-256...
(Also see what did not work for me below).
Here's an example of validating the server certificate with Class 3 Public Primary Certification Authority using OpenSSL's
s_client:Earlier I said "At the top, the CA root is self signed, and the issue and the subject are the same". Here's a dump of that self signed CA root, where the Subject and Issuer are the same. It also shows the 1024-bit moduli and sha1WithRSAEncryption.
Earlier I said "Checkpoint needs to get a new server certificate issued under a certificate (chain) with contemporary parameters, like a CA with a 4096-bit RSA moduli and SHA-256. Or a Subordinate CA with a 2048-bit RSA moduli and SHA-256...".
Here's what did not work for me: rooting or anchoring trust in the stronger Subordinate CA
VeriSign Class 3 Public Primary Certification Authority - G5, and not the weaker 1024-bit Root CA.EDIT: this is due to a bug in OpenSSL 1.0.2a and below. It was fixed in OpenSSL 1.0.2b. See Expected behavior for verification when a subordinate in a chain is promoted to a self signed root?
The practical problem is Symantec re-issuing a certificate with the same name and same public key, so the Distinguished Name, Subject Key Identifier and Authority Key Identifier did not change; but only changing the Serial Number.
I was able to spot it below due to the different serial numbers between the certificate sent in the chain versus the one downloaded from the Symantec site. Then it became apparent the re-issued certificate was changed from a Subordinate CA to a Root CA.
You can use
-showcertswith OpenSSL'ss_clientto see the certs in the chain:What I normally do next is copy a PEM encoded certificate in the chain to a clipboard, and then use
pbpasteto paste in into a terminal and pipe it to OpenSSL'sx509. For example, here is Level 2'sVeriSign Class 3 Public Primary Certification Authority - G5sent as part of the chain: