Re: looking for terminology recommendations concerning non-rooted FQDNs

[Jay Ashworth <jra () baylink com>]

In short, "yes, Jay, I do".  Got it.  :-)

You saw Joe's second reply?

Brian Reichert <reichert () 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                      
> jra () 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                         <reichert () numachi com>
> BSD admin/developer at large   

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.