7

Is it possible to solve the scenario where a web server is served behind HTTPS, and must be accessible both with www.domain.com and www.domain.com.? And notice the trailing dot.

An example for all: GitHub

The certificate of course is for github.com not for github.com.. Is this problem somehow solvable? Am I completely misunderstanding the DNS architecture?

Pier Paolo Ramon
  • 173
  • 1
  • 5
  • 2
    You don't need to use the trailing dot. What are you really doing? – Michael Hampton Jan 20 '13 at 00:33
  • GoDaddy and Comodo certs appear to work with the trailing dot just fine. Does yours not? Why do you care? – ceejayoz Jan 20 '13 at 01:11
  • You would need to find a CA that would issue a certificate that had a name with trailing dot listed as a subject alternate name. I don't know of any that do that. – David Schwartz Jan 20 '13 at 01:26
  • 1
    @MichaelHampton: You would if you needed to ensure the correct domain is accessed. For example "example.com" may be resolved to what "example.com.badguy.com" resolves to if someone has "badguy.com" in their DNS search order. (For example, a friend of mine once had the domain "router.com". A lot of people who had "com" in their search order would type `telnet router` and wind up connecting to him. They should be typing `telnet router.`. – David Schwartz Jan 20 '13 at 01:28
  • Actually I'm not working on nothing in particular. I'm starting to extend my knowledge about networking and I came to the fact the a fqdn can be used also on http requests. My curiosity was: should I in future certificate request ask for both domain.tld and domain.tld.? – Pier Paolo Ramon Jan 20 '13 at 02:13
  • @ceejayoz: This is a browser/client-specific issue, not CA. What GoDaddy- or Comodo-issued certs did you test with? What browser/client did you test with? – charleswj81 Jan 21 '13 at 23:41

1 Answers1

4

Unless you have a cert with a Common Name or Subject Alternative Name (sometimes called a UCC certificate) that matches the hostname exactly as it is typed, the browser will report a name mismatch.

Most (all?) browsers appear to do this. See Bug 134402 - URLs with trailing dots in host names (FQDN) produce cert name mismatches for a discussion of Mozilla's position on this issue. From thier perspective, there's just not enough upside to making such a change, since there are so few, if any, reasons a trailing dot should be included in a URL.

Basically browser vendors, as well as anyone else producing a product that verifies certificates, have to be conservative in any case where they are matching hostnames to certs. Making assumptions as to what the user intended is generally considered "bad". If you are not careful, you can end up in a situation where a hostname in a non-specific url (ex. https://www) is matched to a cert for https://www.<a_domain_in_your_suffix_search_list>, where that resultant domain is not controlled by the same entity as the originally typed name. This is one exception to my rule for always using a trailing dot in FQDNs. The trailing dot is generally a good idea as it is unambiguous and requires fewer queries to resolve, but not all applications deal with it gracefully.

Good catch though, you are WAY ahead of most people in terms of your understanding of "how DNS/SSL/browsers work".

charleswj81
  • 2,453
  • 15
  • 18
  • Thank you so much. Very good insight. I was also wondering about virtual hosting, usually you just check against the Host Header, which could contain "wrong" values such as only `"www"` if you put `google.com` on your search list. – Pier Paolo Ramon Jan 24 '13 at 11:03
  • I recently came across a good reason to use a FQDN with a trailing dot: to reduce DNS queries in a Kubernetes cluster. Ref: https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html By appending a dot, we can tell the `resolver` that the given name is a FQDN and it should not attempt the suffixes in the search list, thus avoiding unnecessary DNS queries. – Satoru.Logic Apr 25 '23 at 07:13