Chrome to Fix Common Name Mismatch Error
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Chrome to Fix Common Name Mismatch Error

An automatic redirect will take care of a misconfiguration

The developer edition of Chrome, known as Chrome Canary, is testing out new functionality that will eliminate a common SSL error, Name Mismatch.

By automatically redirecting users, Chrome Canary will take care of the common problem of a site being SSL accessible over their root domain OR the “www.” subdomain, but not both.

This behavior is not in the Stable release of Chrome yet, and it has not been stated when that will happen. But Canary is usually a few months ahead so this feature should be available to everyone around the beginning of 2017.

To understand exactly what Chrome is doing, and why it matters, let go through a quick example and explanation.

A key piece of the SSL/TLS protocol is authenticating the server by matching the hostname you have visited with the hostname listed in the SSL certificate. The browser will look for an exact match between the two. For example, our certificate is valid for multiple hostnames including “www.thesslstore.com,” “thesslstore.com,” and “thesslstore.in.”

If you visit any of those sites in your browser, you will successfully start an HTTPS connection because the names match. If the names do not match, you will get a mismatch error, also frequently known as a common name invalid error.

It is important to enforce this behavior because it stops someone from forming an HTTPS connection with a site they don’t own. For example, we don’t want you using “badwebsite.com”’s SSL certificate to encrypt your data if you are visiting our site.

So, this is really important behavior that a proper client (i.e. your browser) should have. However, one of the downsides is that this often causes a rather frivolous error due to small mismatches in the names.

The most common is when a site only properly supports SSL over their root domain (“example.com”) or the www. subdomain (“www.example.com”), but not both.

Typically, when you encounter this problem, the browser responds with a major error. In Chrome’s case, it presents a full page warning saying “Your connection is not private.” Even if you were to move past this warning, your connection would now have a broken HTTPS connection displayed in your address bar.

This has been one of the more tedious SSL errors, because it’s entirely non-obvious to humans (at least, the non-technical ones). We treat “www.google.com” and “google.com” as the same website, and that is almost always a safe assumption. But traditionally, software has not done the same, because despite it being a common practice, those are different hostnames that can resolve to different places and be controlled by different entities.

However, Google Chrome has seen it fit to start solving this problem. If the user visits either “https://www.example.com” or “https://example.com,” they will be redirected to the other address if the SSL certificate is not valid for both.

In the example below, showing Chrome’s console, the user is being redirected from the raw subdomain to the “www.” subdomain because Chrome detected the certificate was only valid in that case. Chrome does this on its own without the server having any redirects set up.

Twitter User Anand Bhat drew attention to this feature earlier this week.

Name Mismatch

This all stems from a two common problems. Servers will be mis-configured to provide their certificate when users access “https://www.example.com” and “https://example.com,” without realizing that their certificate is not valid for both names; and that’s because some Certificate Authorities do not automatically issue certificates for both versions of the domain name.

This behavior only works with the “www.” subdomain. Chrome will not attempt this redirect if you visited, say, “login.example.com.” This is because there is a much larger chance other subdomains are entirely different services or operated by different people, which presents a security risk.

Currently, this behavior is only in Chrome Canary. But it should hit the Stable release of Chrome in the next few months. When it does, there will be one less frivolous SSL error to worry about.