3:30 a.m.
Hi there!
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)"
Is there any way to work around this problem? As far as I understand it, RFC4514 section
3.1.3 allows wildcards thus the connection should work, shouldn't it?
What is confusing me is that
"openssl s_client -connect A.xyz123.com:636 -CAfile /etc/ssl/certs/rootca.cer"
results in:
Verify return code: 0 (ok)
If I am not mistaken, openssl accepts the server based on the certificate but openldap
does not.
Any help is much appreciated. I am really stuck with this. Thanks.
Regards,
Sascha
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
4:21 a.m.
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.
What is confusing me is that
"openssl s_client -connect A.xyz123.com:636 -CAfile /etc/ssl/certs/rootca.cer"
results in:
Verify return code: 0 (ok)
If I am not mistaken, openssl accepts the server based on the certificate but openldap
does not.
It's up to a particular SSL/TLS client implementation on what it accepts.
Ciao, Michael.
12:45 p.m.
--On Saturday, March 14, 2009 12:21 PM +0100 Michael Ströder
<michael(a)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
12:53 p.m.
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(a)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
1:38 p.m.
Sascha wrote:
It is an old-ish version of OpenLDAP (2.0.x I think) that we are using.
You really should update this setup for various reasons. Most notably
because auf possible data loss in this version. Note that this might
require sanitizing the current data since recent OpenLDAP versions are
more strict regarding schema checking than 2.0. And in 2.4 you can't
turn off schema checking anymore.
Ciao, Michael.
5192
days inactive
5193
days old
openldap-technical@openldap.org
4 comments
3 participants
participants (3)
-
Michael Ströder -
Quanah Gibson-Mount -
Sascha