With Google’s recent Chrome 58 version update, your Public Key Infrastructure (PKI) may suddenly be impacted. Your formerly-compliant HTTPS certificates may no longer be working. CSS is here to explain what has changed, why has it changed and how to identify which certificates may be impacted. We will look at a temporary Google Chrome work around and view best practice security settings to adopt when working with SANs (Subject Alternative Name) certificates.
Recently Google released a new patch for Google Chrome Version 58 browser. This new release has depreciated use of the “COMMONNAME” value in a certificate for HTTPS (TLS) forcing a SAN attribute as the only option. Certificates using the commonName field for RFC 2818 compliancy (since May of 2000 ) will no longer be compliant on Chrome, causing errors. If affected, you may see an error of “NET::ERR_CERT_COMMON_NAME_INVALID” when visiting sites on local intranet or “private PKI” and errors on other software that may have not been using SANs attributes.
How do I know if I am affected?
If you do not have a certificate management system in place, like CMS Enterprise (certificate and PKI management software), you will have to manually hunt down the certificates either in the CA snap-in or go to your web servers/authentication device servers and take a look at their certificates. Let’s take a look at some comparison certificates:
This is a comparison of 2 certificates – 1 using a CommonName for HTTPS instead of a SANs.
What do I do now?
Option 1: Short-term roll back for Chrome defaults:
With Google’s disruptive change, luckily there is an option to roll back support and make use of administrative templates to push this to organizations on a wider level. Utilizing the information provided, there is temporary support for Linux, MAC, Windows, Google OS, and Android.
Google also has Policy templates to ease the setup up for domain admins and GPO administrators.
Option 2: Long-term adoption of new SAN attributes and best practices:
The first step to supporting SAN attributes is identifying the certificates in the environment that may be impacting connectivity with Chrome. Next, start remediating the certificates that do not have SAN attributes in them. What if you haven’t used SAN attributes in the environment at all? If this is now necessary in the environment, what are the best practices surrounding SAN attributes? Microsoft has released some information on this. In addition, there are hidden dangers of using SANs, which is detailed in a blog by one of our principle PKI consultants at CSS.
Need more information or have additional questions?