What is the rationale for web browsers to consider "example.com." different from "example.com" when validating SSL certificates?
At first blush this seems silly, but I may not have thought through the security consequences thoroughly.
At first blush this seems silly, but I may not have thought through the security consequences thoroughly.
Any non-rooted domain actually has the potential to have what is called a "search domain" applied to it: if your own host's FQDN is bob.example.com, going to "foo.com" can actually take you to "foo.com.example.com.", just like going to "foo" can take you to "foo.example.com."
It's just that, conventionally, although it was always an option to use weird TLD-lookin' subdomain hierarchies within domains like that, nobody does it, because it's so confusing. I don't think much at all would break if we enforced a "if your non-rooted domain ends in a known TLD, canonicalize it to a rooted domain before comparison" rule in browsers, the OpenSSL and OpenSSH libraries, etc., and then require that going forward, all X.509 certs, CORS policies, and so forth which are meant to refer to an FQDN are issued only for the rooted version.
[If you're curious, DNS zone records themselves are always already canonicalized into rooted form whenever you edit them through any sensible interface.]
I don't think this is correct. Check out RFC 2606--it implies that .localhost (the TLD) is localhost, which means "localhost" and "localhost." are the same (one will definitely not have a search domain added to it though).
I suspect the same applies to .local—I just checked and the multicast DNS draft RFC [1] refers to ".local." everywhere.
[1] https://tools.ietf.org/html/draft-cheshire-dnsext-multicastd...
Any other TLD--besides the special-cased "private virtual" ones (localhost., local.)--will still have this problem, though.
The problem is that in practice many implementations that use DNS names display "example.com" to the user when they really mean "example.com." and many certificates are signed for "example.com" when they really mean to be signing for "example.com." A proper implementation would use "example.com." everywhere, but might choose to display "exmample.com" in the GUI if they consistently translate between the two.
I particularly wonder if one can set "www.example.com" to point to a different address from "www.example.com." (globally, not via changing /etc/hosts or your local dns server...)? If they are practically equivalent, then I can't think of much security benefit from treating them differently.
Even if changing the behaviour won't cause any security risk, I can't imagine this being a simple change to make. The SSL certificate contains a digital signature that is performed on a hash of many details, including the CN which is typically the FQDN (without the trailing dot). The `CN==requested-server-name?' matching can be performed at different layers and is probably deeply embedded within the specification and in different implementations. Add this to the practicality of needing to use both www.example.com and www.example.com. - it seems that the balance is in favour of keeping things simple and as the post suggested, use a redirect (or buying an extra certificate).