Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

It looks like https://gmail.com uses an SSL certificate which is for the hostname mail.google.com. 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 gmail.com:443 which gives:

Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
share|improve this question
1  
gmail.com doesn't even work for me. I am going to guess whatever the correct site is, its internally directed to the mail.google.com 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 at 15:08
5  
@Ramhound It sends a 301 Moved Permanently to mail.google.com. If you've visited it before, your browser will cache the redirection and won't even make the gmail.com request. It probably serves a different certificate. –  Bob Jul 28 at 15:12
    
@Bob - Yes; I sort of knew Google did that; –  Ramhound Jul 28 at 16:50

2 Answers 2

up vote 7 down vote accepted

gmail.com 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 gmail.com -connect gmail.com:443

Google results for lynx SNI don't look good.

share|improve this answer
    
+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 gmail.com:443 -servername gmail.com | openssl x509 -text -noout). –  Bruno Jul 28 at 23:20
    
@Bruno There are no SANs on the certificate served by https://mail.google.com/, unless I missed something. While they may be on the certificate from https://gmail.com, that's really the opposite of what the question was asking. Though, yes, SANs should be the first thing to check. –  Bob Jul 29 at 3:21
    
@Bob, you've missed something, try the OpenSSL command to show the details for mail.g..: X509v3 Subject Alternative Name: DNS:mail.google.com. 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 mail.google.com and gmail.com (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 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 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 at 11:44

https://gmail.com/ does not use a bad certificate. Here is its current certificate, as intercepted by Fiddler2:

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

[Issuer]
  CN=Google Internet Authority G2, O=Google Inc, C=US

[Serial Number]
  4F4A246099981C2C

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

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

[Thumbprint]
  8F1065D237732F71CAD350A3FD0089AEEAAB675E

Note the CN=gmail.com.

The actual response type from the HTTP request is a 301 Moved Permanently to https://mail.google.com/. 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 mail.google.com certificate - this is after the redirect. If you look at the address bar, the actual site you are on is http://mail.google.com/, not http://gmail.com/. 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 https://gmail.com/ (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.

share|improve this answer
    
Why does openssl s_client -connect gmail.com:443 find a certificate for mail.google.com then? Why does lynx https://gmail.com produces a SSL error, while lynx https://mail.google.com doesn't? –  Totor Jul 28 at 17:34
2  
@Totor probably because of how they handle HTTP Redirects? –  GroundZero Jul 28 at 18:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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