Hello,
I'm having a heck of a time getting certs to function correctly. This server is being setup with another server in mirrormode - and currently they cannot talk to each other (or themselves when using ldapsearch).
We have a root CA, with a subordinate CA used to sign the cert our ldap server is using.
I have both appended to the /etc/pki/tls/certs/ca-bundle.crt file (CentOS5) - root first, sub second.
I have both (also in the same order) in the cacert.pem used by slapd.conf. TLS directives: TLSCACertificateFile /etc/openldap/cacerts/cacert.pem TLSCertificateFile /etc/openldap/cacerts/ldapcrt.pem TLSCertificateKeyFile /etc/openldap/cacerts/ldapkey.pem
When I test the cacert.pem file or the ldapcrt.pem file using "openssl verify [cert]", everything comes back with OK (I tested removing those from the ca-bundle.crt file and they fail - those are below too). I have those certs available separately and tested them too.
------ Test with CA and Sub-CA in ca-bundle.crt ------ # openssl verify cacert.pem cacert.pem: OK # openssl verify ldapcrt.pem ldapcrt.pem: OK # openssl verify carootcrt.pem carootcrt.pem: OK # openssl verify casubcrt.pem casubcrt.pem: OK
------ Test without CA and Sub-CA in ca-bundle.crt ------ # openssl verify cacert.pem cacert.pem: /DC=edu/DC=apollogrp/CN=Apollo Group Enterprise CA error 18 at 0 depth lookup:self signed certificate OK # openssl verify ldapcrt.pem corp-ldapcrt.pem: [verify specific cert subject snipped] error 20 at 0 depth lookup:unable to get local issuer certificate # openssl verify carootcrt.pem carootcrt.pem: /DC=edu/DC=apollogrp/CN=Apollo Group Enterprise CA error 18 at 0 depth lookup:self signed certificate OK # openssl verify casubcrt.pem casubcrt.pem: /DC=edu/DC=apollogrp/CN=Apollo Group Subordinate CA error 20 at 0 depth lookup:unable to get local issuer certificate
I'm using OpenLDAP build: 2.4.21 built with the following options: ./configure --with-tls=openssl \ --enable-crypt \ --enable-dynamic \ --enable-ldap \ --enable-lmpasswd \ --enable-modules \ --enable-overlays \ --enable-spasswd \ --sysconfdir=/etc
After loading ldif data from our older 2.2 openldap servers, I verified the data was there using Apache Directory Studio (even got some work done on removing/re-adding/comparing ldifs).
Ldapsearch though is another beast all together though.
# ldapsearch -H ldaps://localhost/ ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate in certificate chain)
If you're interested in more details:
# ldapsearch -H ldaps://localhost/ -d5 ldap_url_parse_ext(ldaps://localhost/) ldap_create ldap_url_parse_ext(ldaps://localhost:636/??base) ldap_pvt_sasl_getmech ldap_search put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ldap_build_search_req ATTRS: supportedSASLMechanisms ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:636 ldap_pvt_connect: fd: 3 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: 2, err: 19, subject: /DC=edu/DC=apollogrp/CN=Apollo Group Enterprise CA, issuer: /DC=edu/DC=apollogrp/CN=Apollo Group Enterprise CA TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA 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 in certificate chain). ldap_err2string ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate in certificate chain)
Help? - chris
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.