In short, "yes, Jay, I do". Got it. :-) You saw Joe's second reply?
Brian Reichert <reich...@numachi.com> wrote: >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.