4 ms·

Update your browser - happens to me in IE8, but not Chrome 22. Certification verification is done by the browser, and I believe they store acceptable CA signers

Update your browser - happens to me in IE8, but not Chrome 22. Certification verification is done by the browser, and I believe they store acceptable CA signers somehow, which is probably out dated. Edit: Don't quote me, been a while since studying site certificates.

y0ghur7_xxx 14y ago
I have the latest ff: 16.0.2. I even tried $ openssl s_client -connect hacks.mozilla.org:443 from a linode vm: CONNECTED(00000003) --- Certificate chain 0 s:/serialNumber=I1oZ-yurbFWiPu/xP8HIzW3f9mApQvMv/C=US/ST=California/L=Mountain View/O=Mozilla Corporation/OU=IT/CN=tbpl.mozilla.org i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA 1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate [...] subject=/serialNumber=I1oZ-yurbFWiPu/xP8HIzW3f9mApQvMv/C=US/ST=California/L=Mountain View/O=Mozilla Corporation/OU=IT/CN=tbpl.mozilla.org issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA Any idea?
- superawesome 14y ago
  s_client doesn't support SNI, so this is expected behavior. The client (s_client) doesn't know how to tell the server what hostname it's requesting during the handshake... so the server returns the default one. After the handshake completes, normal HTTP semantics kick in and the client/server have no problems... but by then it's too late, and the client has already negotiated based on the wrong cert.
positivelogic 14y ago
This advisory seems to clear up Internet Explorer's reluctance: http://support.microsoft.com/kb/2643584 http://support.microsoft.com/kb/2643584
superawesome 14y ago
Wild guess... are you on WinXP? WinXP + any version of IE does not support TLS SNI... even though it does support TLSv1.0, it doesn't support the SNI extension. Supported in Vista and 7, though. Chrome, Firefox, and Opera (on any platform) all support TLSv1.0, with or without SNI.

y0ghur7_xxx 14y ago

I have the latest ff: 16.0.2. I even tried $ openssl s_client -connect hacks.mozilla.org:443 from a linode vm: CONNECTED(00000003) --- Certificate chain 0 s:/serialNumber=I1oZ-yurbFWiPu/xP8HIzW3f9mApQvMv/C=US/ST=California/L=Mountain View/O=Mozilla Corporation/OU=IT/CN=tbpl.mozilla.org i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA 1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate [...] subject=/serialNumber=I1oZ-yurbFWiPu/xP8HIzW3f9mApQvMv/C=US/ST=California/L=Mountain View/O=Mozilla Corporation/OU=IT/CN=tbpl.mozilla.org issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA Any idea?

superawesome 14y ago
s_client doesn't support SNI, so this is expected behavior. The client (s_client) doesn't know how to tell the server what hostname it's requesting during the handshake... so the server returns the default one. After the handshake completes, normal HTTP semantics kick in and the client/server have no problems... but by then it's too late, and the client has already negotiated based on the wrong cert.

positivelogic 14y ago

This advisory seems to clear up Internet Explorer's reluctance: http://support.microsoft.com/kb/2643584 http://support.microsoft.com/kb/2643584

superawesome 14y ago

Wild guess... are you on WinXP? WinXP + any version of IE does not support TLS SNI... even though it does support TLSv1.0, it doesn't support the SNI extension. Supported in Vista and 7, though. Chrome, Firefox, and Opera (on any platform) all support TLSv1.0, with or without SNI.