...

Just to make sure, can you pull the entire HEAD?  Thanks for checking, in any case.  p.

I finally had the time to reproduce the issue using the cvs source code from HEAD. The following command was used to build OpenLDAP:

---

CPPFLAGS="-I/home/openldap/software/include -D_AVL_H" \ LDFLAGS="-L/home/openldap/software/lib -Wl,-rpath=/home/openldap/software/lib" \ ./configure --prefix=/home/openldap/software --enable-rewrite --enable-dnssrv \ --enable-ldap --enable-meta --enable-auditlog --enable-rwm --enable-sssvlv \ --with-cyrus-sasl --with-tls=openssl --enable-bdb make depend; make; make install

---

The necessary SSL certificates are selfsigned:

openssl genrsa -out server1.key 2048 openssl req -new -key server1.key -x509 -days 365 -out server1.crt openssl genrsa -out server2.key 2048 openssl req -new -key server2.key -x509 -days 365 -out server2.crt

---

"server2" was started with the command: slapd -f /home/openldap/config/slapd.conf.server2 -h "ldaps://server2:6361" At this point I could already authenticate via SASL EXTERNAL using the ldapsearch command: LDAPTLS_CACERT=server2.crt LDAPTLS_CERT=server1.crt LDAPTLS_KEY=server1.key \ ldapsearch -H "ldaps://server2:6361" -b "" -s base -Y EXTERNAL 'objectclass=*'

Now I started "server1": slapd -f /home/openldap/config/slapd.conf.server1 -h "ldap://server1:3891"

Searching with ldapsearch -H ldap://server1:3891 -b "dc=server2,dc=example,dc=com" -x gives me no result, but the following output on server1's debug log (level

1):

ldap_connect_to_host: Trying 127.0.0.1:6361 ldap_pvt_connect: fd: 9 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server2, issuer: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server2 TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA

I think the real error is that you're using self-signed certificates; this has nothing to do with the way OpenLDAP is using them. Using certificates signed by a CA known to the servers I obtain the expected behavior.

p.

TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate). conn=1000 op=1 meta_search_dobind_init[0]: retrying URI="ldaps://server2:6361" DN="".

---

And again: Starting "server1" with the environment variables and everything works fine: LDAPTLS_CACERT=server2.crt LDAPTLS_CERT=server1.crt LDAPTLS_KEY=server1.key \ slapd -f /home/openldap/config/slapd.conf.server1 -h "ldap://server1:3891"

I hope you can reproduce this issue using the information I provided. The configurations of both servers are attached below.

Best Regards, Manuel

slapd.conf.server1

include /home/openldap/software/etc/openldap/schema/core.schema include /home/openldap/software/etc/openldap/schema/cosine.schema include /home/openldap/software/etc/openldap/schema/inetorgperson.schema database meta suffix "dc=example,dc=com" uri "ldaps://server2:6361/dc=server2,dc=example,dc=com" idassert-authzFrom "*" idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_cert=/home/openldap/config/server1.crt tls_key=/home/openldap/config/server1.key tls_cacert=/home/openldap/config/server2.crt mode=none

---

slapd.conf.server2

include /home/openldap/software/etc/openldap/schema/core.schema include /home/openldap/software/etc/openldap/schema/cosine.schema include /home/openldap/software/etc/openldap/schema/inetorgperson.schema TLSCertificateFile /home/openldap/config/server2.crt TLSCertificateKeyFile /home/openldap/config/server2.key TLSCACertificateFile /home/openldap/config/server1.crt TLSVerifyClient demand database bdb suffix "dc=server2,dc=example,dc=com" rootdn "cn=manager,dc=server2,dc=example,dc=com" directory /home/openldap/db.server2

---