2

On a company intranet, it is often more comfortable to access an internal webserver just by its hostname (e. g. webserver) instead of providing the FQDN (e. g. webserver.company.com). As long as the hostname itself does not already equal a valid name on the internet, the automatic concatenation of the hostname and a DNS suffix (company.com), provided by the network settings, will be resolved to the intranet server successfully.

To not get certificate warnings, the certificate then needs to cover both names, the hostname and the FQDN of the server.

On ServerFault, there is a question that covers the technical feasibility of having both, the hostname and the FQDN in an SSL certificate (which technically is absolutely no problem, as long as you have your own PKI). It partially drifted into a discussion, if it is OK to have both names in a certificate, that I'd like to commence here.

The main concern, that was mentioned, was trust. It would be necessary to work with the FQDN of a machine to trust it. Assuming correctly configured DNS suffixes, how can the trust be compromised, when using just the hostnames? Is it only a problem with multiple DNS suffixes (ambiguity)?

stackprotector
  • 1,653
  • 3
  • 9
  • 19
  • What about a default DNS suffix set on the clients? That would automatically "upgrade" the host name to a FQDN. – Robert Mar 18 '22 at 13:21
  • @Robert This does already happen "under the hood" as described in my first paragraph. But this will only affect the DNS query, not what will be visible in the address bar of the browser. – stackprotector Mar 18 '22 at 14:06
  • 1
    Note that the solution described in the linked question on ServerFault is only possible if you run your own CA and your CA cert is installed on your users' systems. It is unlikely that a widely trusted CA (such as Verisign, GeoTrust, etc.) will sign a certificate with just a hostname (and not a FQDN) in the CN or SAN. See https://security.stackexchange.com/questions/121163/how-do-i-run-proper-https-on-an-internal-network for more info. – mti2935 Mar 18 '22 at 14:15
  • Is the intranet only accesible from internal network? What actual TLD are you using for the FQDN? – Rodrigo Murillo Mar 18 '22 at 17:03
  • @RodrigoMurillo Yes, .com. – stackprotector Mar 18 '22 at 19:45

1 Answers1

-1

A typical browser would probably not allow a secure connection to a host without a FQDN without displaying a warning message. The browser wants to make sure it's accessing the server the certificate was issued for. If the certicate was issued for frt-kors43 it would not know for sure if it was accessing frt-kors43.google.com or frt-kors.busche-cnc.com because of the /etc/hosts file or automatic concatenation of a DNS suffix by the network settings.

The whole domain name business and CA process is geared to verify that the browser is accessing the FQDN securely, so how could GoDaddy or CPanel issue a certificate to secure just a hostname? If we really wanted to bypass this warning to access https://frt-kors43 without getting a warning message, we would have to start Chrome with the flag to bypass the security warning message for all URLs.

schroeder
  • 129,372
  • 55
  • 299
  • 340
brent groves
  • 1
  • 1
  • 2
    This is quite wrong. Except Safari, which I can't test, the major browsers now are Chrome/Edge and Firefox, and both accept a single-label name in cert as valid for that name in URL. FWIW so do curl* wget nodejs.https python.urllib python.requests and Java.HttpsURLConnection (* curl with OpenSSL NSS GnuTLS Schannel -- I can't test Apple here either). But no public CA (like GoDaddy Sectigo Digicert LetsEncrypt -- CPanel is not a CA) will issue you such a cert, so you must use an organizational or personal CA, which it sounds to me like this OP can. – dave_thompson_085 Aug 05 '23 at 08:18
  • @dave_thompson_085 Agreed 100%. – stackprotector Aug 15 '23 at 07:27