It looks like uses an SSL certificate which is for the hostname As the SSL certificate hostname does not match the browser URL, why does this work? I should get a warning instead!

I tested with Firefox and Chromium (it looks like it didn't work before).

I checked the certificate with the command: echo | openssl s_client -connect which gives:

Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/
  • 1 doesn't even work for me. I am going to guess whatever the correct site is, its internally directed to the which is an extended validation certificate. Chrome handles google websites silently. In other words Chrome knows if the website is Google or not. I assume your using the current version on all browsers in question? – Ramhound Jul 28 '14 at 15:08
  • 5
    @Ramhound It sends a 301 Moved Permanently to If you've visited it before, your browser will cache the redirection and won't even make the request. It probably serves a different certificate. – Bob Jul 28 '14 at 15:12
  • @Bob - Yes; I sort of knew Google did that; – Ramhound Jul 28 '14 at 16:50
up vote 7 down vote accepted uses a good certificate, but the server you are connecting to is using Server Name Indication to run virtual hosts on a single address+port. For this to work, the client must tell the server what virtual host it's looking for before the SSL/TLS negotiation is done. Firefox and Chromium (and other clients of similar size) do this automatically.

To get the effective certificate with openssl s_client, you need to use the -servername option.

openssl s_client -servername -connect

Google results for lynx SNI don't look good.

  • +1 In addition, it's not the CN that really matters, but it's the Subject Alternative Names that matter here (as visible when looking at the full details of the cert, for example using echo | openssl s_client -connect -servername | openssl x509 -text -noout). – Bruno Jul 28 '14 at 23:20
  • @Bruno There are no SANs on the certificate served by, unless I missed something. While they may be on the certificate from, that's really the opposite of what the question was asking. Though, yes, SANs should be the first thing to check. – Bob Jul 29 '14 at 3:21
  • @Bob, you've missed something, try the OpenSSL command to show the details for mail.g..: X509v3 Subject Alternative Name: It's not quite the opposite of the question since the asker was effectively why wondering why it wasn't in the Subject DN, which isn't what should be checked first anyway. It could have been a single cert with SANs for both and (it isn't). In any case, SANs are the 1st thing to check, since CNs should be ignored when SANs are present, so mentioning only the CN in the question and in your answer is slightly irrelevant. – Bruno Jul 29 '14 at 9:49
  • @Bruno I wasn't aware of subjectAltName's presence meaning the CN should be ignored (RFC2818§3.1 if anyone else is interested) - I had always assumed it was in addition to. Sorry. As for my answer - "As the SSL certificate hostname does not match the browser URL, why does this work?" is what my answer addresses - it does match the URI the browser is loading, which is different from the one typed. (I didn't mention/check/answer the OpenSSL output, yea - overlooked that). – Bob Jul 29 '14 at 11:21
  • @Bob Indeed, that's in RFC 2818. There's also RFC 6125 now, but it's not implemented everywhere (it is in Chrome as far as I know), it's mostly compatible but clarifies a few points (mainly CN and wildcards). Some tools are stricter than others too (see this SO question for example). – Bruno Jul 29 '14 at 11:44 does not use a bad certificate. Here is its current certificate, as intercepted by Fiddler2:

== Server Certificate ==========
[Subject], O=Google Inc, L=Mountain View, S=California, C=US

  CN=Google Internet Authority G2, O=Google Inc, C=US

[Serial Number]

[Not Before]
  16/07/2014 10:04:37 PM

[Not After]
  14/10/2014 11:00:00 AM


Note the

The actual response type from the HTTP request is a 301 Moved Permanently to This has two effects:

  1. The browser will redirect to the destination, making a new request, with a new tunnel (because different domain) and different certificate. This is why you see a certificate - this is after the redirect. If you look at the address bar, the actual site you are on is, not It's a bit hard to catch the pre-redirect certificate in a browser, which is why I used Fiddler2.

  2. The browser will cache this redirect and perform it automatically in the future, never making another request to (that's the point of Moved Permanently). This isn't really significant to this question, but it does make it a bit harder to discover the redirect - you need to clear your caches or open a private browsing window first.

  • Why does openssl s_client -connect find a certificate for then? Why does lynx produces a SSL error, while lynx doesn't? – Totor Jul 28 '14 at 17:34
  • 2
    @Totor probably because of how they handle HTTP Redirects? – BlueCacti Jul 28 '14 at 18:13

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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