On Wed, Mar 09, 2011 at 11:57:10PM +0100, Peter Eckel wrote:
Hi Baszi,
Well, yes, even though that'd be reliance on DNS, which may (in most cases) may not be trusted.
well, this is easy to misunderstand what I wrote. I wanted to write, it may not be trusted in most cases.
sure. Although I am currently rolling out DNSSEC step-by-step, which means that there is some progress to expect in the near future. But for most current installation you are of course right, it doesn't make much sense to link a certificate to a name that is not guaranteed to be correct at all.
If DNS may not be trusted, then why do web browsers compare the DNS name with the name in the server certificate, and complain or block the connection if there is a mismatch? This argument here is not right. Sure It's less trusted without DNSSEC but certainly more trusted than just accepting any client certificate your CA issued even if it's for a totally different system (because, for example, it was stolen by an attacker and not yet added to a CRL, etc.)
Generally all SSL enabled servers do it like syslog-ng, at least in my experience.
That seems to be the case, yes. Which makes it seem very probable that actually it doesn't make much sense to try to resolve names and match them to the CN/subjectAltName, because if there was a sensible way to do it, someone else would have done it already.
Last resort would be the IP address, which works fine in subjectAltName for authenticating the server to the client. Can you think of any reason why that could not be feasible as well?
I think it makes more sense to check the DNS because all the machine's IP can reverse-resolve to the machine's primary DNS name, and it avoids hard-coding IPs into client certificates which is presumably undesirable in a large environment of the sort where client certificates would add much value. Regards, Matthew.