9

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:

TLS and certificate info

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.com as the previous successful communication?
8
  • The only problem I see is “The connection to the server was reset while the page was loading.” Totally unrelated to SSL, of course.
    – Daniel B
    May 22 '15 at 19:36
  • Also see Phasing out Certificates with 1024-bit RSA Keys on the Firefox/Mozilla blog. The CA root used in the chain is 1024-bits.
    – jww
    May 22 '15 at 22:50
  • @pabouk Somewhat related to this
    – RogUE
    May 24 '15 at 1:57
  • Have your internet disconnected, then try to load any web page; what do you see?
    – RogUE
    May 24 '15 at 1:58
  • If Mozilla has the new VeriSign Class 3 Public Primary Certification Authority - G5 in the Trust Store, then this is a Mozilla bug. The certificate was re-issued, and it was promoted from a Subordinate CA to a self signed Root CA with a different serial number. {Distinguished Name, Serial Number} makes the certificate unique, so it can be selected unambiguously; see RFC 4158. But see the caveats below on selecting it because its not an easy thing to do. Also, Checkpoint should not send the old G5 certificate as part of the chain.
    – jww
    May 24 '15 at 22:13
4

How to troubleshoot “Secure Connection Failed” in Firefox appearing since the version 38?

Use openssl s_client. Its a swiss army knife for things like this. And use openssl x509 to dump certificates.

You are usually interested in the {Issuer, Subject} pairs in the chain like this:

Certificate chain
 0 s:/C=US/ST=California/L=San Carlos/O=Check Point Software Technologies Inc./OU=MIS-US/CN=usercenter.checkpoint.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

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:

enter image description here

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:

 3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

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 Authority with thumbprint a1 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 Authority in 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 Authority in 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:

$ openssl s_client -connect usercenter.checkpoint.com:443 -tls1 \
    -servername usercenter.checkpoint.com -CAfile Class-3-Public-Primary-Certification-Authority.pem 
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)10, CN = VeriSign Class 3 Secure Server CA - G3
verify return:1
depth=0 C = US, ST = California, L = San Carlos, O = Check Point Software Technologies Inc., OU = MIS-US, CN = usercenter.checkpoint.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=San Carlos/O=Check Point Software Technologies Inc./OU=MIS-US/CN=usercenter.checkpoint.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFaTCCBFGgAwIBAgIQbDQ79PGfSr9ppjYf2kOh4zANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwHhcNMTQwMjEx
MDAwMDAwWhcNMTYwMjI1MjM1OTU5WjCBnTELMAkGA1UEBhMCVVMxEzARBgNVBAgT
CkNhbGlmb3JuaWExEzARBgNVBAcUClNhbiBDYXJsb3MxLzAtBgNVBAoUJkNoZWNr
IFBvaW50IFNvZnR3YXJlIFRlY2hub2xvZ2llcyBJbmMuMQ8wDQYDVQQLFAZNSVMt
VVMxIjAgBgNVBAMUGXVzZXJjZW50ZXIuY2hlY2twb2ludC5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDeG4n8NH4KaU/DE4xg2TQNXmKkcslgsqcg
qZbo0QiuHpQTFXF9BbrG3Nv10bNBhe8FWyo1AwJK33PTs0WVeGyMBaVYBIR48C4D
gk+4JPncFWO6eq2eWxzg2yei/xPQwvGNGn0QNcGCUfPZE8Z+KhGUucxGcmlW/lLj
vG0XjCaYkgxUEgOx9rCWYnA5HSmPYYHTT7+lXdlqE4e5QHnRRm4p4iVPRBSAgs94
jtn7wgBf+xg81SqnZ3+gC6ggdd+HDk+PFC/8DsDEFxEJRe/uYhfmMLGZ0Lz9oitc
GIK8rPtylkgVTlNldo2TPsr/zdR43s9gQPpqM0niRQHLcHX83BG3AgMBAAGjggGJ
MIIBhTAkBgNVHREEHTAbghl1c2VyY2VudGVyLmNoZWNrcG9pbnQuY29tMAkGA1Ud
EwQCMAAwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjBDBgNVHSAEPDA6MDgGCmCGSAGG+EUBBzYwKjAoBggrBgEFBQcCARYcaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAfBgNVHSMEGDAWgBQNRFwWU0TBgn4d
IKsl9AFj2L55pTBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vU1ZSU2VjdXJlLUcz
LWNybC52ZXJpc2lnbi5jb20vU1ZSU2VjdXJlRzMuY3JsMHYGCCsGAQUFBwEBBGow
aDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMEAGCCsGAQUF
BzAChjRodHRwOi8vU1ZSU2VjdXJlLUczLWFpYS52ZXJpc2lnbi5jb20vU1ZSU2Vj
dXJlRzMuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQBcO/j4DpV+SAh0xwrrulHW9sg0
ifgntImsZF10gY9P93mRf0rq8OdCeOejx45LZCDc1xgBGov0ehyiShy2pA7rQ93t
hvaMopAnKPi1KPApcwiDNAQ4dI5daUVI1MwvkFZsoxoHvx0IBQOYPgAjSUIE9Q9W
oa6/NqRh2hpZgg550cZhwzh5vbbRieGn6hS8qVCpYYs5N1+39vw+hFNqaTfjyIHF
Aq6UboCNvj28+ZU3U16rxGqu9JQBL/GvaqYXHXhLmXIe63Flv5VSPDA8EcjX7uzo
yt210nEvNhvDBmWA06tX3fYPiZvgf1tzzITVRUZxxZlpUdEuMrcCUB+UFAuO
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=San Carlos/O=Check Point Software Technologies Inc./OU=MIS-US/CN=usercenter.checkpoint.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 4310 bytes and written 600 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 141BB5DD85FA61CC85E5C8368DED9EB9C7C6427D7F655F8DD778EEB003F9EBE7
    Session-ID-ctx: 
    Master-Key: 84261799D242992FE44D48F39F1A10CFCE5BE60E1A900CC3E6BFFD368DAB68A439287C81DC9510871963EF8E3366FFE3
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1432323605
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

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.

$ openssl x509 -in Class-3-Public-Primary-Certification-Authority.pem -inform PEM -text -noout
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
        Validity
            Not Before: Jan 29 00:00:00 1996 GMT
            Not After : Aug  2 23:59:59 2028 GMT
        Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:c9:5c:59:9e:f2:1b:8a:01:14:b4:10:df:04:40:
                    db:e3:57:af:6a:45:40:8f:84:0c:0b:d1:33:d9:d9:
                    11:cf:ee:02:58:1f:25:f7:2a:a8:44:05:aa:ec:03:
                    1f:78:7f:9e:93:b9:9a:00:aa:23:7d:d6:ac:85:a2:
                    63:45:c7:72:27:cc:f4:4c:c6:75:71:d2:39:ef:4f:
                    42:f0:75:df:0a:90:c6:8e:20:6f:98:0f:f8:ac:23:
                    5f:70:29:36:a4:c9:86:e7:b1:9a:20:cb:53:a5:85:
                    e7:3d:be:7d:9a:fe:24:45:33:dc:76:15:ed:0f:a2:
                    71:64:4c:65:2e:81:68:45:a7
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption
         10:72:52:a9:05:14:19:32:08:41:f0:c5:6b:0a:cc:7e:0f:21:
         19:cd:e4:67:dc:5f:a9:1b:e6:ca:e8:73:9d:22:d8:98:6e:73:
         03:61:91:c5:7c:b0:45:40:6e:44:9d:8d:b0:b1:96:74:61:2d:
         0d:a9:45:d2:a4:92:2a:d6:9a:75:97:6e:3f:53:fd:45:99:60:
         1d:a8:2b:4c:f9:5e:a7:09:d8:75:30:d7:d2:65:60:3d:67:d6:
         48:55:75:69:3f:91:f5:48:0b:47:69:22:69:82:96:be:c9:c8:
         38:86:4a:7a:2c:73:19:48:69:4e:6b:7c:65:bf:0f:fc:70:ce:
         88:90

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?

$ openssl s_client -connect usercenter.checkpoint.com:443 -tls1 \
    -servername usercenter.checkpoint.com -CAfile VeriSign-Class-3-Public-Primary-Certification-Authority-G5.pem 
CONNECTED(00000003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:/C=US/ST=California/L=San Carlos/O=Check Point Software Technologies Inc./OU=MIS-US/CN=usercenter.checkpoint.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFaTCCBFGgAwIBAgIQbDQ79PGfSr9ppjYf2kOh4zANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwHhcNMTQwMjEx
MDAwMDAwWhcNMTYwMjI1MjM1OTU5WjCBnTELMAkGA1UEBhMCVVMxEzARBgNVBAgT
CkNhbGlmb3JuaWExEzARBgNVBAcUClNhbiBDYXJsb3MxLzAtBgNVBAoUJkNoZWNr
IFBvaW50IFNvZnR3YXJlIFRlY2hub2xvZ2llcyBJbmMuMQ8wDQYDVQQLFAZNSVMt
VVMxIjAgBgNVBAMUGXVzZXJjZW50ZXIuY2hlY2twb2ludC5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDeG4n8NH4KaU/DE4xg2TQNXmKkcslgsqcg
qZbo0QiuHpQTFXF9BbrG3Nv10bNBhe8FWyo1AwJK33PTs0WVeGyMBaVYBIR48C4D
gk+4JPncFWO6eq2eWxzg2yei/xPQwvGNGn0QNcGCUfPZE8Z+KhGUucxGcmlW/lLj
vG0XjCaYkgxUEgOx9rCWYnA5HSmPYYHTT7+lXdlqE4e5QHnRRm4p4iVPRBSAgs94
jtn7wgBf+xg81SqnZ3+gC6ggdd+HDk+PFC/8DsDEFxEJRe/uYhfmMLGZ0Lz9oitc
GIK8rPtylkgVTlNldo2TPsr/zdR43s9gQPpqM0niRQHLcHX83BG3AgMBAAGjggGJ
MIIBhTAkBgNVHREEHTAbghl1c2VyY2VudGVyLmNoZWNrcG9pbnQuY29tMAkGA1Ud
EwQCMAAwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjBDBgNVHSAEPDA6MDgGCmCGSAGG+EUBBzYwKjAoBggrBgEFBQcCARYcaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAfBgNVHSMEGDAWgBQNRFwWU0TBgn4d
IKsl9AFj2L55pTBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vU1ZSU2VjdXJlLUcz
LWNybC52ZXJpc2lnbi5jb20vU1ZSU2VjdXJlRzMuY3JsMHYGCCsGAQUFBwEBBGow
aDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMEAGCCsGAQUF
BzAChjRodHRwOi8vU1ZSU2VjdXJlLUczLWFpYS52ZXJpc2lnbi5jb20vU1ZSU2Vj
dXJlRzMuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQBcO/j4DpV+SAh0xwrrulHW9sg0
ifgntImsZF10gY9P93mRf0rq8OdCeOejx45LZCDc1xgBGov0ehyiShy2pA7rQ93t
hvaMopAnKPi1KPApcwiDNAQ4dI5daUVI1MwvkFZsoxoHvx0IBQOYPgAjSUIE9Q9W
oa6/NqRh2hpZgg550cZhwzh5vbbRieGn6hS8qVCpYYs5N1+39vw+hFNqaTfjyIHF
Aq6UboCNvj28+ZU3U16rxGqu9JQBL/GvaqYXHXhLmXIe63Flv5VSPDA8EcjX7uzo
yt210nEvNhvDBmWA06tX3fYPiZvgf1tzzITVRUZxxZlpUdEuMrcCUB+UFAuO
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=San Carlos/O=Check Point Software Technologies Inc./OU=MIS-US/CN=usercenter.checkpoint.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 4310 bytes and written 600 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 736B3105DB22F2AB0F5D42C8161A8A132BF1E7C37464BB2F0D00058B867332EB
    Session-ID-ctx: 
    Master-Key: BDD5D4951E3FD01C3C456D475EAE6D0D5CE53FBF75B4F6F3D4D186A27B566D75056057D5395F35AE3BA8D20A669212C2
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1432324811
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---

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 -showcerts with OpenSSL's s_client to see the certs in the chain:

$ openssl s_client -connect usercenter.checkpoint.com:443 -tls1 \
    -servername usercenter.checkpoint.com -showcerts
CONNECTED(00000003)
...
---
Certificate chain
 0 s:/C=US/ST=California/L=San Carlos/O=Check Point Software Technologies Inc./OU=MIS-US/CN=usercenter.checkpoint.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
-----BEGIN CERTIFICATE-----
MIIFaTCCBFGgAwIBAgIQbDQ79PGfSr9ppjYf2kOh4zANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwHhcNMTQwMjEx
MDAwMDAwWhcNMTYwMjI1MjM1OTU5WjCBnTELMAkGA1UEBhMCVVMxEzARBgNVBAgT
CkNhbGlmb3JuaWExEzARBgNVBAcUClNhbiBDYXJsb3MxLzAtBgNVBAoUJkNoZWNr
IFBvaW50IFNvZnR3YXJlIFRlY2hub2xvZ2llcyBJbmMuMQ8wDQYDVQQLFAZNSVMt
VVMxIjAgBgNVBAMUGXVzZXJjZW50ZXIuY2hlY2twb2ludC5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDeG4n8NH4KaU/DE4xg2TQNXmKkcslgsqcg
qZbo0QiuHpQTFXF9BbrG3Nv10bNBhe8FWyo1AwJK33PTs0WVeGyMBaVYBIR48C4D
gk+4JPncFWO6eq2eWxzg2yei/xPQwvGNGn0QNcGCUfPZE8Z+KhGUucxGcmlW/lLj
vG0XjCaYkgxUEgOx9rCWYnA5HSmPYYHTT7+lXdlqE4e5QHnRRm4p4iVPRBSAgs94
jtn7wgBf+xg81SqnZ3+gC6ggdd+HDk+PFC/8DsDEFxEJRe/uYhfmMLGZ0Lz9oitc
GIK8rPtylkgVTlNldo2TPsr/zdR43s9gQPpqM0niRQHLcHX83BG3AgMBAAGjggGJ
MIIBhTAkBgNVHREEHTAbghl1c2VyY2VudGVyLmNoZWNrcG9pbnQuY29tMAkGA1Ud
EwQCMAAwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjBDBgNVHSAEPDA6MDgGCmCGSAGG+EUBBzYwKjAoBggrBgEFBQcCARYcaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAfBgNVHSMEGDAWgBQNRFwWU0TBgn4d
IKsl9AFj2L55pTBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vU1ZSU2VjdXJlLUcz
LWNybC52ZXJpc2lnbi5jb20vU1ZSU2VjdXJlRzMuY3JsMHYGCCsGAQUFBwEBBGow
aDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMEAGCCsGAQUF
BzAChjRodHRwOi8vU1ZSU2VjdXJlLUczLWFpYS52ZXJpc2lnbi5jb20vU1ZSU2Vj
dXJlRzMuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQBcO/j4DpV+SAh0xwrrulHW9sg0
ifgntImsZF10gY9P93mRf0rq8OdCeOejx45LZCDc1xgBGov0ehyiShy2pA7rQ93t
hvaMopAnKPi1KPApcwiDNAQ4dI5daUVI1MwvkFZsoxoHvx0IBQOYPgAjSUIE9Q9W
oa6/NqRh2hpZgg550cZhwzh5vbbRieGn6hS8qVCpYYs5N1+39vw+hFNqaTfjyIHF
Aq6UboCNvj28+ZU3U16rxGqu9JQBL/GvaqYXHXhLmXIe63Flv5VSPDA8EcjX7uzo
yt210nEvNhvDBmWA06tX3fYPiZvgf1tzzITVRUZxxZlpUdEuMrcCUB+UFAuO
-----END CERTIFICATE-----
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
-----BEGIN CERTIFICATE-----
MIIF7DCCBNSgAwIBAgIQbsx6pacDIAm4zrz06VLUkTANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTAwMjA4MDAwMDAwWhcNMjAwMjA3MjM1OTU5WjCBtTEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMmVmVy
aVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCxh4QfwgxF9byrJZenraI+nLr2wTm4i8rCrFbG
5btljkRPTc5v7QlK1K9OEJxoiy6Ve4mbE8riNDTB81vzSXtig0iBdNGIeGwCU/m8
f0MmV1gzgzszChew0E6RJK2GfWQS3HRKNKEdCuqWHQsV/KNLO85jiND4LQyUhhDK
tpo9yus3nABINYYpUHjoRWPNGUFP9ZXse5jUxHGzUL4os4+guVOc9cosI6n9FAbo
GLSa6Dxugf3kzTU2s1HTaewSulZub5tXxYsU5w7HnO1KVGrJTcW/EbGuHGeBy0RV
M5l/JJs/U0V/hhrzPPptf4H1uErT9YU3HLWm0AnkGHs4TvoPAgMBAAGjggHfMIIB
2zA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlz
aWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4
RQEHFwMwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2Nw
czAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQG
A1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMtZzUu
Y3JsMA4GA1UdDwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkwVzBVFglp
bWFnZS9naWYwITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZLjAlFiNo
dHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjAoBgNVHREEITAfpB0w
GzEZMBcGA1UEAxMQVmVyaVNpZ25NUEtJLTItNjAdBgNVHQ4EFgQUDURcFlNEwYJ+
HSCrJfQBY9i+eaUwHwYDVR0jBBgwFoAUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwDQYJ
KoZIhvcNAQEFBQADggEBAAyDJO/dwwzZWJz+NrbrioBL0aP3nfPMU++CnqOh5pfB
WJ11bOAdG0z60cEtBcDqbrIicFXZIDNAMwfCZYP6j0M3m+oOmmxw7vacgDvZN/R6
bezQGH1JSsqZxxkoor7YdyT3hSaGbYcFQEFn0Sc67dxIHSLNCwuLvPSxe/20majp
dirhGi2HbnTTiN0eIsbfFrYrghQKlFzyUOyvzv9iNw2tZdMGQVPtAhTItVgooazg
W+yzf5VK+wPIrSbb5mZ4EkrZn0L74ZjmQoObj49nJOhhGbXdzbULJgWOw27EyHW4
Rs/iGAZeqa6ogZpHFt4MKGwlJ7net4RYxh84HqTEy2Y=
-----END CERTIFICATE-----
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
-----BEGIN CERTIFICATE-----
MIIE0DCCBDmgAwIBAgIQJQzo4DBhLp8rifcFTXz4/TANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDYxMTA4MDAwMDAwWhcNMjExMTA3MjM1OTU5WjCByjELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1nmAMqudLO07cfLw8
RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbext0uz/o9+B1fs70Pb
ZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIzSdhDY2pSS9KP6HBR
TdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQGBO+QueQA5N06tRn/
Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+rCpSx4/VBEnkjWNH
iDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/NIeWiu5T6CUVAgMB
AAGjggGbMIIBlzAPBgNVHRMBAf8EBTADAQH/MDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMA4GA1UdDwEB/wQEAwIBBjA9
BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL2NwczAdBgNVHQ4EFgQUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwbQYI
KwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQU
j+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVyaXNpZ24uY29t
L3ZzbG9nby5naWYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC52ZXJpc2lnbi5jb20wPgYDVR0lBDcwNQYIKwYBBQUHAwEGCCsGAQUFBwMC
BggrBgEFBQcDAwYJYIZIAYb4QgQBBgpghkgBhvhFAQgBMA0GCSqGSIb3DQEBBQUA
A4GBABMC3fjohgDyWvj4IAxZiGIHzs73Tvm7WaGY5eE43U68ZhjTresY8g3JbT5K
lCDDPLq9ZVTGr0SzEK0saz6r1we2uIFjxfleLuUqZ87NMwwq14lWAyMfs77oOghZ
tOxFNfeKW/9mz1Cvxm1XjRl4t7mi0VfqH5pLr7rJjhJ+xr3/
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=San Carlos/O=Check Point Software Technologies Inc./OU=MIS-US/CN=usercenter.checkpoint.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---
...

What I normally do next is copy a PEM encoded certificate in the chain to a clipboard, and then use pbpaste to paste in into a terminal and pipe it to OpenSSL's x509. For example, here is Level 2's VeriSign Class 3 Public Primary Certification Authority - G5 sent as part of the chain:

$ pbpaste | openssl x509 -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            25:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
    ...
1

This is fixed by typing about:config in the address bar, then selecting "I'll be careful, I promise!" button. At that point double click the security.tls.insecure_fallback_hosts option and then add in the address you are trying to access.

I had to remove the "https:\" (put both backslashes, superuser removed my second one)from my address to get it to work, but your results may vary so maybe try both.

This is accurate as of Firefox version 43.0.1.

1
  • As I already wrote in the question security.tls.insecure_fallback_hosts was not the case. Later in a comment a wrote that the problem was on the server side. The server was closing the connections.
    – pabouk
    Feb 17 '16 at 12:48
0

(from other answer) In this case, Symantec needs to fix their broken Root Certifcates page or provide the correct certificate for download when selecting VeriSign Class 3 Public Primary Certification Authority - G5.

If you look at VeriSign Class 3 Public Primary Certification Authority - G5 provided in the chain with openssl s_client ... -showcerts and the VeriSign Class 3 Public Primary Certification Authority - G5 made available for download, you will see they are different certificates. So Verisign re-issued a certificate with the same distinguished name and subject public key.

The chain version of VeriSign Class 3 Public Primary Certification Authority - G5 has the following serial number, and it is not self-signed (notice the Subject and Issuer are different):

$ pbpaste | openssl x509 -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            25:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
        Validity
            Not Before: Nov  8 00:00:00 2006 GMT
            Not After : Nov  7 23:59:59 2021 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
...

The downloaded version from Symantec Root Certificates of VeriSign Class 3 Public Primary Certification Authority - G5 has the following serial number, and it is self-signed (notice the Subject and Issuer are the same):

$ openssl x509 -in VeriSign-Class-3-Public-Primary-Certification-Authority-G5.pem -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            18:da:d1:9e:26:7d:e8:bb:4a:21:58:cd:cc:6b:3b:4a
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Validity
            Not Before: Nov  8 00:00:00 2006 GMT
            Not After : Jul 16 23:59:59 2036 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
...

There is really only one fix here.

Checkpoint should stop sending the old version VeriSign Class 3 Public Primary Certification Authority - G5 subordinate in the chain.

That's because in practice, those verifying paths and selecting certificates will get confused because the old G5 certificate and the new G5 certificate are too similar. They are too similar because they use the same Distinguished Name and same Subject Key Identifier/Authority Key Identifier.


In theory, you could extract the old G5 certificate from the chain sent by the server and put it in the Mozilla Trust Store. But I strongly suspect it will confuse user agents trying to build a path because the only thing that changed is the serial number.

To understand the confusion, look at RFC 4158 and how to select a certificate. One way is the {Distinguished Name, Serial Number} tuple. But a certificate being verified does not include the issuer's serial number. It only includes the Distinguished Name and Authority Key Identifier.

Section 3.5.12 Matching Key Identifiers (KIDs), does specify:

If the current certificate expresses the issuer name and serial number in the AKID, certificates that match both these identifiers have highest priority.

But its not required, and its missing from the warez Symantec provided. To see it first hand, dump the Level 1 intermediate sent in the chain. Its called VeriSign Class 3 Secure Server CA - G3. Notice it has an Authority Key Identifier, but no Serial Number:

$ pbpaste | openssl x509 -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:cc:7a:a5:a7:03:20:09:b8:ce:bc:f4:e9:52:d4:91
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006 VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public Primary Certification Authority - G5
        Validity
            Not Before: Feb  8 00:00:00 2010 GMT
            Not After : Feb  7 23:59:59 2020 GMT
        Subject: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Secure Server CA - G3
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b1:87:84:1f:c2:0c:45:f5:bc:ab:25:97:a7:ad:
                    a2:3e:9c:ba:f6:c1:39:b8:8b:ca:c2:ac:56:c6:e5:
                    bb:65:8e:44:4f:4d:ce:6f:ed:09:4a:d4:af:4e:10:
                    9c:68:8b:2e:95:7b:89:9b:13:ca:e2:34:34:c1:f3:
                    5b:f3:49:7b:62:83:48:81:74:d1:88:78:6c:02:53:
                    f9:bc:7f:43:26:57:58:33:83:3b:33:0a:17:b0:d0:
                    4e:91:24:ad:86:7d:64:12:dc:74:4a:34:a1:1d:0a:
                    ea:96:1d:0b:15:fc:a3:4b:3b:ce:63:88:d0:f8:2d:
                    0c:94:86:10:ca:b6:9a:3d:ca:eb:37:9c:00:48:35:
                    86:29:50:78:e8:45:63:cd:19:41:4f:f5:95:ec:7b:
                    98:d4:c4:71:b3:50:be:28:b3:8f:a0:b9:53:9c:f5:
                    ca:2c:23:a9:fd:14:06:e8:18:b4:9a:e8:3c:6e:81:
                    fd:e4:cd:35:36:b3:51:d3:69:ec:12:ba:56:6e:6f:
                    9b:57:c5:8b:14:e7:0e:c7:9c:ed:4a:54:6a:c9:4d:
                    c5:bf:11:b1:ae:1c:67:81:cb:44:55:33:99:7f:24:
                    9b:3f:53:45:7f:86:1a:f3:3c:fa:6d:7f:81:f5:b8:
                    4a:d3:f5:85:37:1c:b5:a6:d0:09:e4:18:7b:38:4e:
                    fa:0f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Authority Information Access: 
                OCSP - URI:http://ocsp.verisign.com

            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.113733.1.7.23.3
                  CPS: https://www.verisign.com/cps
                  User Notice:
                    Explicit Text: https://www.verisign.com/rpa

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.verisign.com/pca3-g5.crl

            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            1.3.6.1.5.5.7.1.12: 
                0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
            X509v3 Subject Alternative Name: 
                DirName:/CN=VeriSignMPKI-2-6
            X509v3 Subject Key Identifier: 
                0D:44:5C:16:53:44:C1:82:7E:1D:20:AB:25:F4:01:63:D8:BE:79:A5
            X509v3 Authority Key Identifier: 
                keyid:7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33

    Signature Algorithm: sha1WithRSAEncryption
         0c:83:24:ef:dd:c3:0c:d9:58:9c:fe:36:b6:eb:8a:80:4b:d1:
         a3:f7:9d:f3:cc:53:ef:82:9e:a3:a1:e6:97:c1:58:9d:75:6c:
         e0:1d:1b:4c:fa:d1:c1:2d:05:c0:ea:6e:b2:22:70:55:d9:20:
         33:40:33:07:c2:65:83:fa:8f:43:37:9b:ea:0e:9a:6c:70:ee:
         f6:9c:80:3b:d9:37:f4:7a:6d:ec:d0:18:7d:49:4a:ca:99:c7:
         19:28:a2:be:d8:77:24:f7:85:26:86:6d:87:05:40:41:67:d1:
         27:3a:ed:dc:48:1d:22:cd:0b:0b:8b:bc:f4:b1:7b:fd:b4:99:
         a8:e9:76:2a:e1:1a:2d:87:6e:74:d3:88:dd:1e:22:c6:df:16:
         b6:2b:82:14:0a:94:5c:f2:50:ec:af:ce:ff:62:37:0d:ad:65:
         d3:06:41:53:ed:02:14:c8:b5:58:28:a1:ac:e0:5b:ec:b3:7f:
         95:4a:fb:03:c8:ad:26:db:e6:66:78:12:4a:d9:9f:42:fb:e1:
         98:e6:42:83:9b:8f:8f:67:24:e8:61:19:b5:dd:cd:b5:0b:26:
         05:8e:c3:6e:c4:c8:75:b8:46:cf:e2:18:06:5e:a9:ae:a8:81:
         9a:47:16:de:0c:28:6c:25:27:b9:de:b7:84:58:c6:1f:38:1e:
         a4:c4:cb:66

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.