TLS enabled LDAP, clients fail to connect
Mubeesh ali
mubeeshalivm at gmail.com
Mon Nov 22 12:49:00 UTC 2010
hi,
Is the server cert trusted on the client ?
--
Best Regards,
Mubeesh Ali.V.M
On Mon, Nov 22, 2010 at 3:50 AM, bluethundr <bluethundr at gmail.com> wrote:
> I am attempting to setup SSL/TLS support on my openLDAP 2.4 server on FreeBSD.
>
> LBSD2# pkg_info | grep openldap
> openldap-sasl-client-2.4.23 Open source LDAP client implementation
> with SASL2 support
> openldap-sasl-server-2.4.23 Open source LDAP server implementation
>
> I put my cert file, key file and CA certfile in a directory called
> /usr/local/etc/openldap/cacerts
>
> Here's how it looks:
>
> [root at LBSD2:/usr/local/etc/openldap/cacerts]#ls -l
> total 48
> dr--r----- 2 root ldap 512 Nov 21 17:12 bak
> -r--r----- 1 root ldap 1960 Nov 21 07:05 bsd2.summitnjhome.com.crt
> -r--r----- 1 root ldap 4604 Nov 21 17:16 gd_bundle.crt
> -r--r----- 1 root ldap 4689 Nov 21 18:59 sf_bundle.crt
> -r--r----- 1 root ldap 1537 Nov 21 17:16 sf_issuing.crt
> -r--r----- 1 root ldap 1090 Nov 21 12:29 slapd.csr
> -r--r----- 1 root ldap 1743 Nov 21 12:26 slapd.key
> -r--r----- 1 root ldap 1675 Nov 21 17:25 slapd.pem
>
>
> My cert flie is a GoDaddy turbo-ssl certfile named
> bsd2.summitnjhome.com.crt. slapd.key is the key file and slapd.pem is
> the same thing only with the password removed.
>
> I'm a little unsure of which CA file to use but I think that
> sf_issuing.crt _should_ work as this is the CA file that I used to
> setup a similar SSL enabled LDAP server for a client recently.
> Although I have tried all three CA files in this directory:
> (gd_bundle.crt, sf_bundle.crt, and sf_issuing.crt).
>
> I put the various cert/key files into my slapd.conf file like this:
>
> LBSD2# cat slapd.conf | grep -i tls
> ## TLS options for slapd
> TLSCipherSuite HIGH:MEDIUM:+SSLv2
> TLSCertificateFile /usr/local/etc/openldap/cacerts/bsd2.summitnjhome.com.crt
> TLSCertificateKeyFile /usr/local/etc/openldap/cacerts/slapd.pem
> TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt
>
>
> Slapd restarts cleanly!
>
> LBSD2# /usr/local/etc/rc.d/slapd restart
> Stopping slapd.
> Waiting for PIDS: 81924.
> Starting slapd.
>
>
> Then I attempt to setup a virtual instance of CentOS 5.5 on the client
> side and that's where things fall apart...I attempt to ssh to
> localhost as an LDAP account:
>
> [root at VIRTCENT08:/etc/openldap/cacerts]#ssh bluethundr at localhost
>
> [...tectonic plates drift, careers begin and end, babies learn to
> walk, talk and grow to adulthood..]
>
> Connection closed by 127.0.0.1
>
> [root at VIRTCENT08:/etc/openldap/cacerts]#getent passwd | grep ldapAccount
> [same interminable wait as above]
>
>
> This is what my /etc/ldap.conf file looks like on the client:
>
> [root at VIRTCENT08:/etc/openldap/cacerts]#cat /etc/ldap.conf
> # Your LDAP server. Must be resolvable without using LDAP.
> # Multiple hosts may be specified, each separated by a
> # space. How long nss_ldap takes to failover depends on
> # whether your LDAP client library supports configurable
> # network or connect timeouts (see bind_timelimit).
> #host 127.0.0.1
> # The distinguished name of the search base.
> base dc=summitnjhome,dc=com
> # stored in /etc/ldap.secret (mode 600)
> #rootbinddn cn=manager,dc=example,dc=com
> # The port.
> # Optional: default is 389.
> #port 389
> # Search timelimit
> #timelimit 30
> timelimit 120
> # Bind/connect timelimit
> #bind_timelimit 30
> bind_timelimit 120
> # Idle timelimit; client will close connections
> # (nss_ldap only) if the server has not been contacted
> # for the number of seconds specified below.
> #idle_timelimit 3600
> idle_timelimit 3600
> # Netscape SDK LDAPS
> #ssl on
> # Netscape SDK SSL options
> #sslpath /etc/ssl/certs
> # OpenLDAP SSL mechanism
> # start_tls mechanism uses the normal LDAP port, LDAPS typically 636
> #ssl start_tls
> #ssl on
> # OpenLDAP SSL options
> # Require and verify server certificate (yes/no)
> # Default is to use libldap's default behavior, which can be configured in
> # /etc/openldap/ldap.conf using the TLS_REQCERT setting. The default for
> # OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes".
> #tls_checkpeer yes
> # CA certificates for server certificate verification
> # At least one of these are required if tls_checkpeer is "yes"
> #tls_cacertfile /etc/ssl/ca.cert
> #tls_cacertdir /etc/ssl/certs
> # SSL cipher suite
> # See man ciphers for syntax
> #tls_ciphers TLSv1
> # Client certificate and key
> # Use these, if your server requires client authentication.
> #tls_cert
> #tls_key
> # SASL mechanism for PAM authentication - use is experimental
> # at present and does not support password policy control
> uri ldap://ldap.summitnjhome.com/
> ssl start_tls
> tls_cacertdir /etc/openldap/cacerts
> pam_password crypt
>
> This is how my nsswitch on the client side is setup:
>
> passwd: files ldap
> shadow: files ldap
> group: files ldap
>
> And here is the cert dir on my CentOS client:
>
> [root at VIRTCENT08:/etc/openldap/cacerts]#ls -l
> total 72
> lrwxrwxrwx 1 root root 13 Nov 21 09:44 97552d04.0 -> gd_bundle.crt
> lrwxrwxrwx 1 root root 14 Nov 21 09:44 b737b221.0 -> sf_issuing.crt
> dr--r--r-- 2 root root 4096 Nov 21 2010 bak
> -r--r--r-- 1 root root 1960 Nov 21 07:05 bsd2.summitnjhome.com.crt
> lrwxrwxrwx 1 root root 25 Nov 21 09:44 c75be861.0 -> bsd2.summitnjhome.com.crt
> -r--r--r-- 1 root root 4604 Nov 21 2010 gd_bundle.crt
> -r--r--r-- 1 root root 1537 Nov 21 2010 sf_issuing.crt
> -r--r--r-- 1 root root 1090 Nov 21 12:29 slapd.csr
> -r--r--r-- 1 root root 1743 Nov 21 12:26 slapd.key
> -r--r--r-- 1 root root 1675 Nov 21 2010 slapd.pem
>
>
> Back on the server side there is a lot of activity in the ldap logs
> (here is an excerpt)
>
> Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: read activity on 11
> Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: select: listen=6
> active_threads=0 tvp=NULL
> Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: select: listen=7
> active_threads=0 tvp=NULL
> Nov 21 20:21:38 LBSD2 slapd[81972]: connection_read(11): input
> error=-2 id=1017, closing.
> Nov 21 20:21:38 LBSD2 slapd[81972]: connection_closing: readying
> conn=1017 sd=11 for close
> Nov 21 20:21:38 LBSD2 slapd[81972]: daemon: activity on 1 descriptor
>
> I've encloses a more complete log file as an attachment.
>
> I then try to show the CA files with an openssl command.
>
> First with sf_issuing.crt -
>
> slapd.conf:
>
> TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_issuing.crt
>
> On the client:
>
> [root at VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect
> ldap.summitnjhome.com:389 -showcerts -CAfile sf_issuing.crt
> CONNECTED(00000003)
> 3143:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188
>
>
> Next with sf_bundle.crt -
>
> slapd.conf:
>
> TLSCACertificateFile /usr/local/etc/openldap/cacerts/sf_bundle.crt
>
>
> [root at VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect
> ldap.summitnjhome.com:389 -showcerts -CAfile sf_bundle.crt
> 3149:error:02001002:system library:fopen:No such file or
> directory:bss_file.c:122:fopen('sf_bundle.crt','r')
> 3149:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:125:
> 3149:error:0B084002:x509 certificate
> routines:X509_load_cert_crl_file:system lib:by_file.c:279:
> CONNECTED(00000003)
> 3149:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:188:
>
> Next with gd_bundle.crt -
>
> TLSCACertificateFile /usr/local/etc/openldap/cacerts/gd_bundle.crt
>
> [root at VIRTCENT08:/etc/openldap/cacerts]#openssl s_client -connect
> ldap.summitnjhome.com:389 -showcerts -CAfile gd_bundle.crt
> CONNECTED(00000003)
> 3156:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:188:
>
>
> Disabling TLS on the client side authentication works again!
>
> [root at VIRTCENT08:/etc/openldap/cacerts]#ssh bluethundr at localhost
> bluethundr at localhost's password:
> Last login: Sun Nov 21 09:41:34 2010 from 192.168.1.50
> #########################################################
> # SUMMITNJHOME.COM #
> # TITLE: VIRTCENT08 BOX #
> # LOCATION: SUMMIT BASEMENT #
> # #
> #########################################################
>
>
> Any thought on how to resolve the current situation would be most
> appreciated! ;)
>
>
>
>
> --
> Here's my RSA Public key:
> gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9
>
> Share and enjoy!!
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>
More information about the freebsd-questions
mailing list