0

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

  1. 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.
  2. somehow configure a permanent exception in Chrome (I haven't found a way to set a permanent exception for this error)
  3. 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.

Owen
  • 131
  • 7
  • 8
    *"... it is because we aren't using the FQDN and chrome now requires that a CN be for the FQDN..."* - No. This is because Chrome is no longer accepting the hostname inside the CN but expect it do be a inside the subject alternative name section. This means you have to fix the certificates. – Steffen Ullrich Apr 28 '17 at 18:53
  • 2
    The CN can be anything you want - `CN=Our Dev Cert` would work just fine. Add DNS entries to the Subject Alternate Names for each dev server. You can have one entry for the hostname and another for the FQDN. That way, your users can enter the short or long version. – garethTheRed Apr 28 '17 at 18:57
  • I'd like to point out that option 1 wouldn't work anyway coz the first thing that happens is the handshake fails, so the redirect wouldn't be made. Anyways, I don't really understand the whole situation. Why do you guys use hostname instead of FQDN, browsers autocomplete URLs anyway, so you really don't have to type the whole thing, only the first few characters. – bviktor Apr 28 '17 at 21:33
  • At least Chromium seems to have [`--ignore-certificate-errors`](https://cs.chromium.org/chromium/src/ios/chrome/browser/chrome_switches.cc?q=kIOSIgnoreCertificateErrors&sq=package:chromium&type=cs&l=112) but I'm not sure if it works on Chrome too and I wouldn't advice using it as it affects globally. (Mostly I see answers that should have been comments. Now, Steffen's comment is actually an answer.) – Esa Jokinen Apr 29 '17 at 10:59

0 Answers0