On 04/12/2011 02:18 PM, Judith Flo Gaya wrote:
On 4/12/11 9:49 PM, Rich Megginson wrote:
If you are using /usr/bin/ldapsearch on Fedora 14 and later, it is linked with Mozilla NSS instead of openssl. But openldap with moznss works the same as it does with openssl.
so certificates generated by openssl should work with this settings?
Yes.
Do you have your CA cert on the client machine?
I copied the ca-cert.pem from the server machine to the client,
Ok.
along with the certificate that I generate for the client itself.
Not sure what you mean by this.
I thought that it was this last certificate the one that I should place in the TLS_CACERT (ldap.conf) not the general one.
Not sure what you mean by this. TLS_CACERT must be the certificate of the CA that issued the server cert.
If so, did you specify it in /etc/openldap/ldap.conf or ~/.ldaprc? If not, you can also specify it on the command line like this:
LDAPTLS_CACERT=/path/to/ca_cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/
I made the test and still it does not work ;( # LDAPTLS_CACERT=/etc/openldap/cacerts/ca-cert.pem ldapsearch -x -H ldaps://curri0.imppc.local:636/ -d 1 ldap_url_parse_ext(ldaps://curri0.imppc.local:636/) ldap_create ldap_url_parse_ext(ldaps://curri0.imppc.local:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP curri0.imppc.local:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 172.19.5.13:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS certificate verification: subject: -unknown-, issuer: -unknown-, cipher: -unknown-, security level: off, secret key bits: 0, total key bits: 0, cache hits: 0, cache misses: 0, cache not reusable: 0 TLS certificate verification: bad TLS certificate verification: Error, -8182: Unknown code ___f 10 TLS: error: connect - force handshake failure -1 - error -8182:Unknown code ___f 10 TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
It seems that it doesn't like the certificate.
-8182 is SEC_ERROR_BAD_SIGNATURE. During the TLS/SSL handshake, the client tries to see if the server's cert is correctly signed by the CA cert (the local ca-cert.pem).
On the server side it is finally working :) the problem is that all clients are f14
See http://www.openldap.org/faq/data/cache/1514.html for information about how to use Mozilla NSS.
I'll have a look, otherwise, I may compile openldap for the clients and the change all binaries so that they use "my versions of openldap" with openssl instead of the mozz ones... It looks a little mess though ;(
and this is what the server says: slap_listener_activate(8):
slap_listener(ldaps://curri0.imppc.local:636)
connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL_accept:before/accept initialization TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write server done A TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL_accept:error in SSLv3 read client certificate A TLS trace: SSL_accept:error in SSLv3 read client certificate A connection_get(12): got connid=1008 connection_read(12): checking for input on id=1008 TLS trace: SSL3 alert read:fatal:bad certificate TLS trace: SSL_accept:failed in SSLv3 read client certificate A TLS: can't accept: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate. connection_read(12): TLS accept failure error=-1 id=1008, closing connection_close: conn=1008 sd=12
any clue? the error on the client side seems to indicate that the client is trying to use the nss from the mozilla but I never meant to this, openssl is installed. Thanks a lot for your help. j
instead.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration