Browser manufacturers are always releasing updates intended to improve usability and security. Most changes are benign but some can produce havoc, even if well-intentioned (like blocking java applets when accessing critical internal sites).
The latest version of Google Chrome (58), released on April 20, includes a new checking mechanism for secured websites (which are accessed using https). This check analyzes the SSL certificate used by the site to encrypt traffic, and will produce a warning if the certificate does not include the common name of the website (e.g. website.company.com) as a subjective alternative name (SAN), which is a fancy word for alias. This check can be suppressed on Windows systems (for a temporary basis at least), and I’ll explain how to do so below.
The warning appears as follows:
Users must then click “Advanced” to be able to continue to access the website:
Clicking the Proceed to… link will permit access to the site.
Certificates issued by a Trusted Certificate Authority such as Entrust or Verisign (and which are generally applied to public-facing websites) should be fine, but expect to start seeing this error if you use Chrome with internal websites that utilize self-signed certificates or certificates issued from an internal certificate authority.
What is a subject alternative name?
As I said, a subjective alternative name (SAN) is like an alias which can permit the use of multiple server or host names by a single certificate. Let’s say you have a website with a common name of website.company.com. The website can direct traffic to one of two sites you run; a primary site in Boston (boston.company.com) and a secondary site in Los Angeles (la.company.com).
You’d like each site to be able to handle traffic if the other one is unavailable, so you issue an SSL certificate for company.com with two SANs: boston.company.com and la.company.com.
In this scenario, however, Chrome will issue the above error if your SSL certificate doesn’t include a SAN of website.company.com as that is the common name to which you are connecting.
Why did Google make this change?
At first glance this may seem illogical. If Google is trying to protect users against spoofed websites, couldn’t malicious website operators just add the common name as a SAN and circumvent the issue?
Well, they could, but in this case it’s not going to work. In the first place, they can’t add someone else’s common name to their certificate because no public certificate authority will allow that. Chrome 58 doesn’t even check the common name of the site when accessing it, but focuses exclusively on the certificate by looking at the ASCII code involved and not the actual characters.
You see, different character sets in different languages can appear similar but are actually viewed as separate entities by a computer. This can allow fake domains to be registered using another name or set of characters to fool visitors. Chrome 58 mitigates this issue by requiring a SAN matching the common name, which won’t match those look alike characters.
How can this be resolved?
For a single user this is probably a manageable, but annoying, issue. Once I proceeded to a site I did not get the prompt again, although I saw a red security warning associated with the certificate when I returned to the site.
For an entire company, however, a fix should be put in place or else the IT department is going to get a LOT of calls (which is probably better than users blithely ignoring security warnings, if you think about it logically).
If you’re a system administrator, you could always downgrade Chrome installations, but I don’t recommend it. You will miss out on other security upgrades down the line. If you’re getting this error when accessing internal sites, the best bet is to roll up your sleeves and update the SSL certificates for those sites to include the common name of the website as a SAN.
You can buy yourself some time with Windows systems, at least. It’s possible to implement or deploy a registry key to suppress this prompt (make sure you know what you’re doing when editing a system registry!)
Run regedit and access this registry key:
HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome
Create a REG_DWORD subkey called EnableCommonNameFallbackForLocalAnchors and give it a value of 1:
You can also create a custom registry (.reg) file and populate it with the data below:
Double-clicking this file and answering yes will automatically add this information into the system registry. It’s a bad idea to send such a file to users to ask them to run it (Outlook will likely block it anyhow) so push this out via Active Directory Group Policy, enact the setting via SCCM (if applicable) or arrange a script to install this. Please note it’s necessary to restart Chrome for this change to take effect.
However, this fix will only remain valid through version 65 of Chrome, so you should still plan to update any SSL certificates you have administrative authority over.
Security controls of this nature can generate confusion and frustration, but it’s important to keep in mind that for the most part they are well-thought-out and necessary. Google’s intention here is to protect users, but probably some sort of advanced warning (such as a message prompt in Chrome 57 that Chrome 58 would include this feature) would make sense next time.
Also see:
- Win32 is malware? Webroot mistakenly labels Windows as cybersecurity threat
- Easy ways to make your Android device more secure
- Why businesses have the wrong cybersecurity mindset, and how they can fix it
- How to manage cross-device syncing in Chrome
