looking for terminology recommendations concerning non-rooted FQDNs

Fri Feb 22 21:55:02 UTC 2013

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	