Hello all,
why does slapd require a peer/client certificate? I'm slapd 2.3.30 on debian (package 2.3.30-5 to be precise).
when connexting with ssl to slapd using
ldapsearch -H ldaps://artemis.t310.org -b dc=t310,dc=org -x
I get the following error from slapd (started with -d 8):
TLS: can't accept. TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455
When connecting to the same host but with the ldap protocol (vs ldaps) the search results correctly.
This error seems like somehow slapd wants to get a client certficate, but I did not set slapd up that way. The ldap.conf on the client machines only contains the CA certificate field:
TLS_CACERT /usr/share/ca-certificates/t310/t310_pem.crt
relevant parts from slapd.conf (included in total at the end of message):
TLSCertificateFile /etc/ldap/artemis-ldap-cert.pem TLSCertificateKeyFile /etc/ldap/artemis-ldap-key.pem TLSCACerticateFile /usr/share/ca-certificates/t310/t310_pem.crt #TLSVerifyClient never #TLSCRLCheck none
verification with openssl s_server and s_client:
openssl s_server -accept 12345 -cert /etc/ldap/artemis-ldap- cert.pem -key /etc/ldap/artemis-ldap-key.pem -CAfile /usr/share/ca- certificates/t310/t310_pem.crt Using default temp DH parameters Using default temp ECDH parameters ACCEPT
and the client:
openssl s_client -CAfile /etc/ssl/certs/t310_pem.pem - connect artemis.t310.org:12345
allows me to exchange data between them. However connecting the s_client to the real ldap server results in an error:
artemis:~# openssl s_client -CAfile /etc/ssl/certs/ t310_pem.pem -connect artemis.t310.org:636 CONNECTED(00000003) depth=1 /O=T310 technologies/OU=CA Division/ emailAddress=ca@t310.org/L=Amsterdam/ST=NH/C=NL/CN=T310 root CA verify return:1 depth=0 /C=NL/ST=NH/O=T310 technologies/OU=ldap/ CN=artemis.t310.org verify return:1 15612:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1057:SSL alert number 40 15612:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
Any help is appreciated
Frank Cornelissen
On Aug 15, 2007, at 9:00 AM, Frank Cornelissen wrote:
Hello all,
why does slapd require a peer/client certificate? I'm slapd 2.3.30 on debian (package 2.3.30-5 to be precise).
when connexting with ssl to slapd using
ldapsearch -H ldaps://artemis.t310.org -b dc=t310,dc=org -xI get the following error from slapd (started with -d 8):
TLS: can't accept. TLS: error:140890C7:SSLroutines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455
<snip>
After some debugging, this seems to be caused by the fact that on this machine libnss-ldap is enabled. This library will be loaded and will set some libldap options which seem to be global and thus interfering with the options from slapd. Anybody got an idea how to solve this, apart from setting up a seperate machine for openldap|?
Thanks in advance,
Frank Cornelissen
Frank Cornelissen frankc@t310.org writes:
After some debugging, this seems to be caused by the fact that on this machine libnss-ldap is enabled. This library will be loaded and will set some libldap options which seem to be global and thus interfering with the options from slapd. Anybody got an idea how to solve this, apart from setting up a seperate machine for openldap|?
Make sure that you run slapd as root, or at least as a user that isn't managed through nss-ldap. That helps some.
Help the OpenLDAP developers in whatever way possible towards getting a 2.4 release out so that Debian can get rid of the incredibly broken dual library setup that we have right now for licensing reasons which is causing tons of problems like this and upgrade everything to 2.4 across the board. :/
On 8/23/07, Frank Cornelissen frankc@t310.org wrote:
On Aug 15, 2007, at 9:00 AM, Frank Cornelissen wrote:
Hello all,
why does slapd require a peer/client certificate? I'm slapd 2.3.30 on debian (package 2.3.30-5 to be precise).
when connexting with ssl to slapd using
ldapsearch -H ldaps://artemis.t310.org -b dc=t310,dc=org -xI get the following error from slapd (started with -d 8):
TLS: can't accept. TLS: error:140890C7:SSLroutines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455
<snip>
After some debugging, this seems to be caused by the fact that on this machine libnss-ldap is enabled. This library will be loaded and will set some libldap options which seem to be global and thus interfering with the options from slapd. Anybody got an idea how to solve this, apart from setting up a seperate machine for openldap|?
I haven't looked at this specific issue, but other issues relating to using ldap-enabled software on a host using nss_ldap could be worked around by using nscd. However, the problems I've seen were fixed in the latest release of nss_ldap (257). Versions affected were at least 254-256, but it may depend on the ssl library (and version).
More details would help ... (if this hasn't been resolved yet).
"Buchan Milne" bgmilne@gmail.com writes:
On 8/23/07, Frank Cornelissen frankc@t310.org wrote:
After some debugging, this seems to be caused by the fact that on this machine libnss-ldap is enabled. This library will be loaded and will set some libldap options which seem to be global and thus interfering with the options from slapd. Anybody got an idea how to solve this, apart from setting up a seperate machine for openldap|?
I haven't looked at this specific issue, but other issues relating to using ldap-enabled software on a host using nss_ldap could be worked around by using nscd. However, the problems I've seen were fixed in the latest release of nss_ldap (257). Versions affected were at least 254-256, but it may depend on the ssl library (and version).
More details would help ... (if this hasn't been resolved yet).
Debian has additional issues due to library conflicts (themselves due to incredibly frustrating licensing nonsense) that aren't nss_ldap's fault but which using nss_ldap will trigger because that loads the conflicting library. These issues are Debian-specific since other distributions, so far as I can tell, just ignore the OpenSSL/GPL license conflict.
Frank Cornelissen wrote:
Hello all,
why does slapd require a peer/client certificate? I'm slapd 2.3.30 on debian (package 2.3.30-5 to be precise).
when connexting with ssl to slapd using
ldapsearch -H ldaps://artemis.t310.org -b dc=t310,dc=org -xI get the following error from slapd (started with -d 8):
TLS: can't accept. TLS: error:140890C7:SSLroutines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455
When connecting to the same host but with the ldap protocol (vs ldaps) the search results correctly.
This error seems like somehow slapd wants to get a client certficate, but I did not set slapd up that way. The ldap.conf on the client machines only contains the CA certificate field:
TLS_CACERT /usr/share/ca-certificates/t310/t310_pem.crtrelevant parts from slapd.conf (included in total at the end of message):
TLSCertificateFile /etc/ldap/artemis-ldap-cert.pem TLSCertificateKeyFile /etc/ldap/artemis-ldap-key.pem TLSCACerticateFile /usr/share/ca-certificates/t310/t310_pem.crt #TLSVerifyClient never #TLSCRLCheck none
Uncomment the "TLSVerifyClient never" directive here to work around this problem.
On Aug 25, 2007, at 2:49 PM, Howard Chu wrote:
Frank Cornelissen wrote:
Hello all, why does slapd require a peer/client certificate? I'm slapd 2.3.30 on debian (package 2.3.30-5 to be precise). when connexting with ssl to slapd using ldapsearch -H ldaps://artemis.t310.org -b dc=t310,dc=org -x I get the following error from slapd (started with -d 8): TLS: can't accept. TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr.c:2455 When connecting to the same host but with the ldap protocol (vs ldaps) the search results correctly. This error seems like somehow slapd wants to get a client certficate, but I did not set slapd up that way. The ldap.conf on the client machines only contains the CA certificate field: TLS_CACERT /usr/share/ca-certificates/t310/t310_pem.crt relevant parts from slapd.conf (included in total at the end of message): TLSCertificateFile /etc/ldap/artemis-ldap-cert.pem TLSCertificateKeyFile /etc/ldap/artemis-ldap-key.pem TLSCACerticateFile /usr/share/ca-certificates/t310/ t310_pem.crt #TLSVerifyClient never #TLSCRLCheck none
Uncomment the "TLSVerifyClient never" directive here to work around this problem.
No, that didn't work. The problem is a bad interaction with libnss_ldap and slapd, that share the same ldap connection context (same process). libnss-ldap does (rightfully) want to check the certificate of the server, and sets this option when it is activated. That happens after the slapd.conf is read. My solution for now is to run slapd in a chroot jail which does not reference nss-ldap, so this problem does not occur.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Frank Cornelissen
On Sunday 26 August 2007 20:16:14 Frank Cornelissen wrote:
No, that didn't work. The problem is a bad interaction with libnss_ldap and slapd, that share the same ldap connection context (same process). libnss-ldap does (rightfully) want to check the certificate of the server, and sets this option when it is activated. That happens after the slapd.conf is read. My solution for now is to run slapd in a chroot jail which does not reference nss-ldap, so this problem does not occur.
The other workaround for problems like this is to use nscd ...
openldap-software@openldap.org
-
Buchan Milne -
Buchan Milne -
Frank Cornelissen -
Howard Chu -
Russ Allbery