Understanding Certificate Name Mismatches

Recently, I received a query from the Windows Mobile team-- they had observed that visiting https://gmail.com triggers a certificate name mismatch error on IEMobile, but doesn’t seem to trigger any error on Windows 7 when using the desktop versions of Internet Explorer or Firefox.

Now, long-time readers know that I love a good mystery, so I was excited to take a look at what was going on here. I first verified the original problem: IE on Windows Mobile 6.5 does indeed show the name mismatch warning, and desktop IE doesn’t show any warning at all. My next step was to watch the Desktop’s traffic with Fiddler, which, when configured to perform HTTPS decryption, will warn about any certificate errors by default. I was intrigued to find that Fiddler does, in fact, warn about the certificate when visiting https://gmail.com. As you can see, the certificate presented is for “mail.google.com” instead of “gmail.com”:

This name mismatch triggers a warning in Fiddler and should be triggering a similar warning within the browser. My next step was to try opening the site using IE6 inside XP Virtual Mode. There, I found that IE6 reported the same certificate error.

 

So, what’s going on here? A security bug introduced in the newer desktop versions of Firefox and IE, that prevents proper name matching? Unlikely.

No, actually, something more interesting is going on, and by now I had a hunch about what it was. I tried IE8 running on a Windows XP machine and saw the expected certificate error page. I then switched back to my Windows 7 machine and unticked the “Use TLS 1.0” option inside of IE8’s Advanced Internet Options and revisited the site. This time, I also got a certificate error:

So, the site always yields a certificate error on Windows XP, and on Windows 7 if TLS is disabled. But why?

By now, some of you have probably jumped ahead to solve the case, but I wanted to be very sure. My next tool of choice was Netmon, a packet-monitor that allows me to easily examine the HTTPS handshakes in both the Certificate-Error and No-Certificate-Error cases. I was able to quickly determine that in the No-Certificate-Error case, the GMail site was returning the “CN=gmail.com” certificate while in the Certificate-Error case, it was returning the “CN=mail.google.com” certificate.

More importantly, however, I was able to see the reason why: In the No-Certificate-Error case, the browser was sending the Server Name Indication TLS extension. I first blogged about the SNI extension back in the fall of 2005 when it was introduced in IE7 on Windows Vista. As I explained back then:

When a web browser initiates a HTTPS handshake with a web server, the server immediately sends down a digital certificate. The hostname of the server is listed inside the digital certificate, and the browser compares it to the hostname it was attempting to reach. If these hostnames do not match, the browser raises an error. 

The matching-hostnames requirement causes a problem if a single-IP is configured to host multiple sites (sometimes known as “virtual-hosting”). Ordinarily, a virtual-hosting server examines the HTTP Host request header to determine what HTTP content to return. However, in the HTTPS case, the server must provide a digital certificate before it receives the HTTP headers from the browser. SNI resolves this problem by listing the target server’s hostname in the SNI extension field of the initial client handshake with the secure server. A virtual-hosting server may examine the SNI extension to determine which digital certificate to send back to the client.

The GMail server is configured to select a certificate to return based on the SNI sent by the client; the only problem is that pre-Vista versions of IE don’t send the SNI at all, nor will any browser where either SSLv2 is enabled or TLS is disabled. (Even if TLS is enabled, having SSLv2 enabled prevents sending of the TLS extensions because the SSLv2 handshake format cannot carry TLS extensions.)

Unfortunately, SNI support isn’t available on Windows XP, even in IE8. IE relies on SChannel for the implementation of all of its HTTPS protocols. SChannel is an operating system component, and it was only updated with support for TLS extension on Windows Vista and later. The Google folks could avoid the name mismatch problem for downlevel clients by returning a certificate containing multiple hostnames (e.g. “SubjectCN=mail.google.com; SubjectAltNames=DNS Name=gmail.com”) but apparently doing so is problematic because they have so many hostnames in use on their load-balanced servers.

Case closed.

-Eric

PS: I’m especially glad I investigated this case because it uncovered a bug in Fiddler. Fiddler shouldn’t have encountered this problem (when running on Windows 7) because it should have been using a SSLv3 format handshake and the TLS extensions should have been sent. The bug I found is that Fiddler was incorrectly allowing SSLv2 connections to upstream servers, which forced use of the v2 format handshake, which had the effect of disabling TLS extensions. That bug is now fixed in Fiddler v2.2.7.9.

Of course, when running Fiddler on pre-Vista versions of Windows, it makes no difference: the .NET Framework’s SslStream class also relies on SChannel, and hence TLS extensions aren’t available to .NET applications running on Windows XP either.

Comments

• Anonymous
  December 07, 2009
  So, what's the solution? Switching to FireFox?

• Anonymous
  December 07, 2009
  Kerry-- The solution depends on who you are and what your scenario is. If you're Google, you could use multi-hostname certs. If you're an end-user, you could upgrade to Vista+, or you could choose to use the URLs that are supported by your service (e.g. https://mail.google.com).

• Anonymous
  January 05, 2010
  Am I understanding correctly that from IE with SSL 2.0 enabled, you would not be able to connect to a server that only accepted TLS?

• Anonymous
  January 06, 2010
  @moidib: Not exactly. If TLS is also enabled, then virtually all TLS servers will accept a SSLv2 handshake and negotiate a TLS connection. However, if the server requires TLS extensions to succeed (e.g. requires a cipher that communicates parameters via TLS extensions like some of the TLS1.1/TLS1.2 ciphers do) then a client that sends an SSLv2 handshake will not work with that server. In the case here, the connection succeeds, but the server, which relies upon a TLS extension to determine which certificate to send, will send the wrong certificate and trigger the warning in the client.

• Anonymous
  June 16, 2012
  See blogs.msdn.com/.../https-request-hangs-.net-application-connection-on-tls-server-name-indicator-warning.aspx for details of an issue with servers that return TLS WARNING statuses for SNI mismatches.

• Anonymous
  November 08, 2012
  IIS8 now supports SNI on the server-side. weblogs.asp.net/.../what-s-new-in-iis-8.aspx

• Anonymous
  January 03, 2013
  Sooo what would you do with WIndows Mobile??  I have some devices showing this error and some that do not.. identical devices.. all running 6.5 Classic... stumped. EricLaw: Since 6.5 doesn't support SNI, the most likely explanation is that certain devices are getting load-balanced to a server that isn't using SNI for certificate selection. Hard to say without a network trace.

• Anonymous
  January 17, 2013
  The comment has been removed

• Anonymous
  January 23, 2013
  I will double check the clocks... they are with the client.  Let me do that before publicly postingthe URL  thanks!

• Anonymous
  March 01, 2013
  Sadly it is microsoft that will lose this, with the demise of ipv4, many small hosting companies have no choice but to use SNI since they can not get any more ipv4 addresses, so the answer is to change to Firefox or Chrome, not go out and pay hundred plus dollars for a new OS when  a 30 second free download resolves the problem. But, its not just MS, Apple's safari on XP wont work either, or at least didnt the last time i tried. EricLaw: XP will not ever be updated to offer SNI, and that OS will be fully unsupported in 2014.