In message <20130222215502.gd99...@numachi.com>, Brian Reichert writes: > 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.
You used a tool that returns a entry from the DNS. That tool doesn't do the reverse mapping into a hostname because it is a tool for querying the DNS. If you want a tool that deals with hostnames use something that wraps getnameinfo(). > 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 Again you are confusing domain names with host names. > 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. Well you have a broken SSL client app. If it is accepting non legal hostnames it should be normalising them before passing them to the ssl layer. > - 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 jra@baylink. > com > > Designer The Things I Think RFC 2 > 100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > > St Petersburg FL USA #natog +1 727 647 1 > 274 > > > > -- > Brian Reichert <reich...@numachi.com> > BSD admin/developer at large > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org