On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote: > My snap reaction is to say that nothing should ever be *trying* to > compare a rooted F.Q.D.N. against a certificate; it is, as has been > noted, merely command line/entry field shorthand to tell the local > resolver where to quit; applications should all be stripping that > trailing dot. > > Do you have evidence that the extra AltName with the trailing dot > is operationally necessary?
'Necessary' is what's hard to ascertain here. If, under a UNIX-like operating system, you request a PTR with some command-line tool such as 'dig', you'll get a rooted domain name: $ dig -x 8.8.8.8 +short google-public-dns-a.google.com. And you can use this rooted domain name get an A record: $ dig a google-public-dns-a.google.com. +short 8.8.8.8 As a matter of example, if you had automation that was internally testing your network for trusted certificates, and generated a set of hostnames based on reverse DNS, then your SSL client will now be using rooted domain names. When I did my initial development with OpenSSL, I observed: - If I did not have the rooted domain name in the SAN, then any SSL client stack would fail the verification if a rooted domain name was used to connect to the SSL server. - I could generate a CSR with both formats of hostnames. - My OpenSSL-based CA (and our internal MS-based CA) would sign said certificate request, preserving all of the hostnames in the SAN. - and now using a roted domain name was successful. And I figured, if both OpenSSL and Microsoft's Certificate Services, (and their respective SSL clients) behaved the same way, I just coded my automated generation of the CSR to include the rooted domain names, just to cover my bases. I did not expect that misc commercial entities would punish people under these circumstances... Now, I expect in this specific customer's case, I'm reasonably certain that they won't have a tool chain / work flow / whatever, that would introduce a rooted domain name. But, I don't know if I can guarantee that for all of our current and future clients. I don't know if the practices suggested by RFC 1535 will come into effect, but I wanted to future-proof our product in this regard... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > -- Brian Reichert <reich...@numachi.com> BSD admin/developer at large
