Thanks, Michael and Quanah.
It is an old-ish version of OpenLDAP (2.0.x I think) that we are using. I guess that explains why it's failing.
Any advise how I can work around it except for updating to a new version of OpenLDAP? I experimented with tls_reqcert and tls_checkpeer (or similar) but without success.
Thanks, Sascha
Am 14.03.2009 um 20:45 schrieb Quanah Gibson-Mount:
--On Saturday, March 14, 2009 12:21 PM +0100 Michael Ströder <michael@stroeder.com
wrote:
Sascha wrote:
I have a problem with an LDAP server that I need to connect to. I have the required certificate stored on the client but I am getting the following error message:
"TLS: hostname (A.xyz123.com) does not match common name in certificate (*.xyz123.com)"
Personally I'm scared of accepting wildcard certs for security reasons.
As far as I understand it, RFC4514 section 3.1.3 allows wildcards thus the connection should work, shouldn't it?
It's RFC 4513, section 3.1.3. And there it says:
The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed.
So wildcard DNS names in CN is explicitly not allowed. You can try with wildcard patterns in the subjectAltName cert extension.
Except that most cert vendors put the wildcard in CN and not subjectAltName. I note everything I ever tested with a wildcart cert accepted this *except* OpenLDAP. So I submitted an ITS somewhere back in OpenLDAP 2.2 land to allow this, and it has been in place ever since, and works to this day AFAIK.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration