looking for terminology recommendations concerning non-rooted FQDNs

Jay Ashworth jra at baylink.com
Fri Feb 22 22:21:02 UTC 2013


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

You saw Joe's second reply?

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

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


More information about the NANOG mailing list