In message <20130222215502.GD99258@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 <reichert@numachi.com> BSD admin/developer at large
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org