I don't think it's possible to buy a certificate with a dot at the end, so I don't see how this is Google's problem.

It seems to be either a problem with Firefox or with the domain name system in general.

It looks like the problem should be fixed in 2016 because then all non-FQDN certificates will have expired. Then browsers can go ahead and assume that google.com. in a url is the same as google.com in a certificate.

I think Firefox is actually wrong. They do have long standing open bug on this with a lot of, in my opinion, nonsensical arguments. [1]

RFC 6125 [2] says that DNS-IDs should be fully qualified domain names and points you at RFC 1034 [3] for a definition (which doesn't have a definition sadly).

RFC 1034 does specify the difference between complete (or absolute) domain name and a incomplete (or relative) domain name, with complete domain names including the trailing dot. As best as I can tell the first use of Fully Qualified Domain Names (FQDN) came from RFC 1535 [4]. It doesn't really define the term either but proceeds to use it and mentions "absolute 'rooted' FQDN" in such a way that it implies that absolute is adjective. Finally, we get to RFC 1594 section 5.2 [5] which tries to clear up the matter and describes a FQDN in a way that would seem to agree with your usage (requiring the trailing dot), while giving examples that omit the trailing dot. The Wikipedia article on FQDN [6] says otherwise that the trailing dot is necessary. So at best the definition of FQDN is ambiguous in my opinion which means the RFCs don't help us much here with determining the proper way of handling the trailing dot with respect to PKIX certificate validation.

However, I think that there are some conclusions we can draw using some common sense and thinking about the implications of the behavior.

1) Hostnames are commonly used without the trailing dot. As long as they only are missing the trailing dot they are still fully qualified. They may not be absolute and are still relative to the root.

2) Nobody issues certificates with the trailing dot in the common name. It doesn't make much sense for the RFC to be defined in a way that is entirely incompatible with the existing certificates. Especially since it went to such an effort to define how to deal with the old Common Name sytle and not only the newer SubjectAltName style.

Maybe they should have been using absolute hostnames in order to allow everyone to distinguish between certificates that were issued for relative domains but they don't. In general I don't think CAs should be issuing certificates for relative domains.

Mozilla's own CA Certificate Inclusion Policy [7] disallows certificates being issued that are not absolute domains. It does so by saying "the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate." I can't fathom how issuing a certificate based on a relative domain say "www" could ever be compliant with that.

3) What's the worst that could happen if you allow a match on "www.example.com." to the certificate with "www.example.com" in the CN or SNA? Well not much because the trailing dot forces you to the absolute hostname which happens to be what the CA issued the certificate for.

You can't (assuming a search domain of "example.org") ever end up at "www.example.com.example.org" and therefor be matching the wrong domain because of the trailing dot tells the resolver not to do that. If a browser does do that then they have a separate bug.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=134402 [2] http://tools.ietf.org/html/rfc6125 [3] http://tools.ietf.org/html/rfc1034 [4] http://tools.ietf.org/html/rfc1535 [5] https://tools.ietf.org/html/rfc1594#section-5 [6] http://en.wikipedia.org/wiki/Fully_qualified_domain_name [7] http://www.mozilla.org/en-US/about/governance/policies/secur...

That works just fine for me.