Hacker News Reader

Comment by JimmaDaRustla | Hacker News Reader

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.

View on HN

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?

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.

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.

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

Reply on news.ycombinator.com