Our company has some development web servers in our domain. Our domain name is rather long and to avoid typing it, our staff has gotten in the habit of browsing to our webservers by hostname only instead of fully qualified domain name. For example we have webserver1, and staff access it by going to https:// webserver1/ and not https:// webserver1.longsubdomainname.companydomain.local/
This hasn't been a problem in the past. Browsers on computers in our domain would trust webserver1's certificate because it was issued by our domain's certificate authority. Recently Chrome has started displaying a certificate error page with the error NET::ERR_CERT_COMMON_NAME_INVALID and as far as I can tell
it is because we aren't using the FQDN and chrome now requires that a CN be for the FQDN (see edit below). Firefox and the microsoft browsers still consider our configuration & certificate valid.
How can I get this to work with minimal changes? I am imagining these options
- Issue new certs for the FQDNs and configure the web servers to redirect to their FQDN. I know I will get some backlash over the different (longer) urls.
- somehow configure a permanent exception in Chrome (I haven't found a way to set a permanent exception for this error)
- modify our organization's DNS so webserver1.local point's to the server's IP address and issue a cert for webserver1.local.
Since I can't figure out how to do option 2, I'm leaning toward option 3. Option 1 feels more "by the book" but I'd like to keep the staff happy with shorter urls. Is there a compelling reason why I should not use option 3?
EDIT: Thanks to Steffen Ullrich's comment I realize I misunderstood the problem. I put the server's short name in the subject alternative names section and the certificate error went away.
Chrome 58 starts showing certificate errors when the certificate relies on the common name and doesn't have a SAN set. I didn't know, but apparently this has been depricated since May 2000.