Hi,
how do the openldap tools technically verfify certificates with ldapi:// ?
With ldapi, you don't have a hostname or IP address, so how do the openldap tools do it?
I tried to browse the code but got losat somewhere ion the way. Any hints to the code or a short step-by-step explanation will help.
Background of this question: I want to implement the feature in perl-ldap.
Thanks in advance for your help Peter
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
With ldapi, you don't have a hostname or IP address, so how do the openldap tools do it?
Are you talking about SASL/EXTERNAL? There are no certs involved at all with ldapi:// (see http://tools.ietf.org/html/draft-chu-ldap-ldapi-00).
Ciao, Michael.
Hi,
On Monday, 28. May 2012, Michael Ströder wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
With ldapi, you don't have a hostname or IP address, so how do the openldap tools do it?
Are you talking about SASL/EXTERNAL? There are no certs involved at all with ldapi:// (see http://tools.ietf.org/html/draft-chu-ldap-ldapi-00).
Michaels post showed that I did not make myself clear enough. I want to verify server certificates when switching to TLS
In the end I want to achieve the same as ldapsearch -LLL -x -H ldapi:/// -ZZ -s base -b "" I.e. 1) connect via ldapi 2) switch to TLS with reuiring the verification of the server certificate to succeed
How does ldapsearch check the server certificate in the absence of a hostname or IP address?
Best PEter
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
I assume the answer is "the one the server returns when you do StartTLS on the ldapi:// connection".
It's pretty unusual to do that, of course. The normal solution for authenticating the server in the ldapi case is to put the socket somewhere that only the trusted user can write to, so you know that the socket you connected to is trusted.
If that's not a sufficient option, and verifying certs is required, then it appears the code will treat the socket path as the hostname to verify for. For OpenSSL, for example, that means it'll compare it against any DNS: subjectAltNames as well as against the last CN component of the cert subject.
(A related question is what slapd will use as your authentication id for SASL EXTERNAL if you do TLS with a client cert on an ldapi socket: will it use the cert's subject or the "gidNumber=%d+uidNumber=%d,...etc" DN of the ldapi connection. The former seems like the obvious choice, being the "more recent" of the two in this case, and a quick look at the slapd code would seem to confirm that...but I would test it before designing a system to depend on it...)
Philip Guenther
Hi,
On Monday, 28. May 2012, Philip Guenther wrote:
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
I assume the answer is "the one the server returns when you do StartTLS on the ldapi:// connection".
Correct.
If that's not a sufficient option, and verifying certs is required, then it appears the code will treat the socket path as the hostname to verify for. For OpenSSL, for example, that means it'll compare it against any DNS: subjectAltNames as well as against the last CN component of the cert subject.
That's not what the openldap tools do. My cerver certificates do not contain the ldapi socket path as hostnames, yet ldapsearch -LLL -x -H ldapi:/// -ZZ -s base -b "" works and I want to find out how it does this.
Best PEter
Peter Marschall wrote:
On Monday, 28. May 2012, Philip Guenther wrote:
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
I assume the answer is "the one the server returns when you do StartTLS on the ldapi:// connection".
Correct.
So if the quite liberal RFC 6125 does not provide any inspiration this boils down to being undefined. StartTLS over LDAPI is an unusal scenario anyway.
Ciao, Michael.
Hi Michael,
On Monday, 28. May 2012, Michael Ströder wrote:
Peter Marschall wrote:
On Monday, 28. May 2012, Philip Guenther wrote:
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
I assume the answer is "the one the server returns when you do StartTLS on the ldapi:// connection".
Correct.
So if the quite liberal RFC 6125 does not provide any inspiration this boils down to being undefined. StartTLS over LDAPI is an unusal scenario anyway.
Thanks for your reply. It helps a bit ("looking at the issue from the standard angle"), but my question was how the openldap tools do it.
Best Peter
Peter Marschall wrote:
On Monday, 28. May 2012, Michael Ströder wrote:
Peter Marschall wrote:
On Monday, 28. May 2012, Philip Guenther wrote:
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
I assume the answer is "the one the server returns when you do StartTLS on the ldapi:// connection".
Correct.
So if the quite liberal RFC 6125 does not provide any inspiration this boils down to being undefined. StartTLS over LDAPI is an unusal scenario anyway.
Thanks for your reply. It helps a bit ("looking at the issue from the standard angle"), but my question was how the openldap tools do it.
I think the standards are what is relevant here. The arbitrarily check for "localhost" does not make sense because "localhost" does not sufficiently specify the name of the server.
The server is an end entity for the CA and the CA guarantees having checked the server's identity (or checked whether someone was authorized to request a cert for the server's name). So I wouldn't trust any CA which issues certs for "localhost".
=> StartTLS over LDAP is undefined and probably every API should simple refuse it at all or accept any server cert. In both cases the underlying LDAPI channel is fully trusted anyway.
If the client really would like to implement an additional *security* check that a rogue attacker did not trick the client to connect to another Unix domain socket (MITM service) checking the server's identity by matching "localhost" also does not make sense to me.
Ciao, Michael.
Michael Ströder wrote:
=> StartTLS over LDAP is undefined and probably every API should simple refuse it at all or accept any server cert. In both cases the underlying LDAPI channel is fully trusted anyway.
If the client really would like to implement an additional *security* check that a rogue attacker did not trick the client to connect to another Unix domain socket (MITM service) checking the server's identity by matching "localhost" also does not make sense to me.
A rough idea: GeneralName can be an URI. So the LDAPI URI should be in subjectAltName extension and checked by the client (if some name has to be checked at all). Anything else is nonsense.
Ciao, Michael.
Hi,
On Monday, 28. May 2012, Michael Ströder wrote:
I think the standards are what is relevant here. The arbitrarily check for "localhost" does not make sense because "localhost" does not sufficiently specify the name of the server.
I fully concur, that it is not correct to use "localhost" in certificates.
The server is an end entity for the CA and the CA guarantees having checked the server's identity (or checked whether someone was authorized to request a cert for the server's name). So I wouldn't trust any CA which issues certs for "localhost".
My certificates do neither contain "localhost" nor the path to the ldapi:// socket, yet both of the following commands work. ldapsearch -LLL -x -H ldap://localhost/ -ZZ -s base -b "" ldapsearch -LLL -x -H ldapi:/// -ZZ -s base -b ""
In my opinion, this can only have one of the folowing reasons: * ldapsearch simply ignores the server certificate verification completely * ldapsearch soes some "clever trick" to be able to do certificate verification.
Any ideas (ideally with references to the code) which of these options ldapsearch (and the other openldap tools) choose?
Best EPter
On Mon, 28 May 2012, Peter Marschall wrote:
On Monday, 28. May 2012, Philip Guenther wrote:
...
If that's not a sufficient option, and verifying certs is required, then it appears the code will treat the socket path as the hostname to verify for. For OpenSSL, for example, that means it'll compare it against any DNS: subjectAltNames as well as against the last CN component of the cert subject.
That's not what the openldap tools do.
I'm glad I said "it appears", as appearances can be (and were) deceiving. :-)
Checking with a debugger, I see that my description was correct for the case where a path was specified in the URI, ala ldapi://%2fvar%2frun%2fldapi
If no path is specified (e.g., "ldapi://") then the checking code is passed a hostname of "localhost".
Philip Guenther
On Mon, 28 May 2012, Philip Guenther wrote:
If no path is specified (e.g., "ldapi://") then the checking code is passed a hostname of "localhost".
...which then remaps that to the local hostname (if available) for the actual check.
Huh. So for any URI that doesn't specify a host component, be it "ldapi://" or "ldap://" or "ldaps://", the OpenLDAP tools will connect to the default 'host' for the schema, be it "/var/run/ldpai" or "localhost", but for StartTLS they'll match the server cert against the *hostname*.
I did not expect that, though I can see how it can be justified.
Philip Guenther
Hi,
On Monday, 28. May 2012, Philip Guenther wrote:
...which then remaps that to the local hostname (if available) for the actual check.
Huh. So for any URI that doesn't specify a host component, be it "ldapi://" or "ldap://" or "ldaps://", the OpenLDAP tools will connect to the default 'host' for the schema, be it "/var/run/ldpai" or "localhost", but for StartTLS they'll match the server cert against the *hostname*.
I did not expect that, though I can see how it can be justified.
Sounds like a/the "clever trick" I was looking for.
Now that I knew for what I was looking ,I was able to find it in ibraries/libldap/tls_{o,g,m}.c
Thanks a lot Peter
openldap-technical@openldap.org
-
Michael Ströder -
Peter Marschall -
Philip Guenther