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.
Am 14.03.2009 um 20:45 schrieb Quanah Gibson-Mount:
--On Saturday, March 14, 2009 12:21 PM +0100 Michael Ströder
> 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
>> 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
> identity to the Common Name (CN) [RFC4519] value in the leaf
> 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 184.108.40.206, below, with the
> that no wildcard matching is allowed.
> So wildcard DNS names in CN is explicitly not allowed. You can try
> 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.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration