Page 1 of 1

Fun with Web Certificates 101

Posted: Fri Apr 21, 2017 2:33 pm
by SteveBeauchemin
The other morning, for no reason that I could see, I could no longer get into my Nagios XI Console.
WebCertChrom-Version-58.png
Other people sitting near me had no problem. I thought it was just a local problem related to just my PC. Clearing web cache, and other stuff did not help. Uninstalling and reinstalling Chrome, no help. It worked in IE just fine.

Later that morning I was sent this in an email by one of our web admins:
In an effort to make our lives more difficult Google has decided to end the use of Common Names in Chrome version 58. What this means to us is any certificate created by our internal servers (all Dev/QA and a few production internal only sites) will report as the certificate is not valid because of the common name.

Going forward all Certificates need to have a subject alternate name (san) entered when created. You can do this in the Attributes box of the certificate server by adding:
san:dns=<websitename>.company.com

if you want to do both FQDN and websitename you would enter:
san:dns=<websitename>.company.com&dns=<websitename>

replacing <websitename> with the name of the website (like webservicesqa or wwwqa3)
When I saw this email I checked my Chrome version and sure enough, my workstation had been upgraded to Chrome 58 overnight through our Corporate PC management tools.

My Nagios server is not exposed to the Internet, but we do need SSL on it for various reasons. So, in case anyone else encounters this in chrome... Go get a new cert.

To be clear, this is for Internally generated Certs only. The Cert providers that make you pay for certs have already dealt with this.

Just when everything works perfectly, something has to intrude. Nice huh.

Steve B

Re: Fun with Web Certificates 101

Posted: Sat Apr 22, 2017 4:54 am
by WillemDH
Steve,

Your internal certificate doesn't supply a Subject Alternate Name, Chrome no longer relies on CommonName without SubjectAlternateName having a matching entry.
The policy EnableCommonNameFallbackForLocalAnchors will restore the old behavior, without needing to re-generate the certificates. You can temporarily work around this by adding a registry key in Windows..

https://www.chromium.org/administrators ... calAnchors

This workaround will only work for a while (not sure how long, but I heard someone say several weeks). In the meantime you will have to regenerate your certificates and supply a SAN.

We have 100+ websites for which w'll need to regenerate certificates..

Grr

Re: Fun with Web Certificates 101

Posted: Sun Apr 23, 2017 5:30 pm
by dwhitfield
Thanks to both of you for the helpful info!

Re: Fun with Web Certificates 101

Posted: Wed Apr 26, 2017 11:18 am
by SteveBeauchemin
Willem,

Thanks for adding to the information. I do have new certificates in place. I feel bad for the Web team here as they have to find and make new certs for many systems.

I was the one of the first to get the Chrome update here. My workstation is in a test group for updates so I get broken before the general population. I saw the problem and got new certs right away. I try not to let my stuff sit in a bad state for long.

I will pass on the information you shared to my Web folks.

I mainly posted this in case other folks have a mystery problem that makes no sense. I hate those.

Thanks again. This can be closed if someone feels the need...

Steve B