LDAP clients fail to connect with SSL enabled

bluethundr

bluethundr

LDAP clients fail to connect with SSL enabled


I am attempting to setup SSL/TLS support on my openLDAP 2.4 server on FreeBSD.

Code: 
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:

Code: 
[root@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:

Code: 
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!

Code: 
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:

Code: 
[root@VIRTCENT08:/etc/openldap/cacerts]#ssh bluethundr@localhost

[...tectonic plates drift, careers begin and end, babies learn to walk, talk and grow to adulthood.. x( ]

Connection closed by 127.0.0.1

[root@VIRTCENT08:/etc/openldap/cacerts]#getent passwd | grep ldapAccount
[same interminable wait as above]

[bluethundr@VIRTCENT08:~]#ldapsearch -h ldap.summitnjhome.com -ZZ "dc=summitnjhome,dc=com"
ldap_start_tls: Connect error (-11)
	additional info: TLS: hostname does not match CN in peer certificate

Although it is claiming that the hostname does not match the CN in the peer cert, I copy/pated the output of hostname into the common name field of the certificate generation process:

Code: 
LBSD2# hostname
LBSD2.summitnjhome.com

This is what my /etc/ldap.conf file looks like on the client:

Code: 
[root@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:

Code: 
passwd:     files ldap
shadow:     files ldap
group:      files ldap

And here is the cert dir on my CentOS client:

Code: 
[root@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)

Code: 
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 -

Code: 
slapd.conf:

TLSCACertificateFile  /usr/local/etc/openldap/cacerts/sf_issuing.crt

On the client:

[root@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 -

Code: 
slapd.conf:

TLSCACertificateFile  /usr/local/etc/openldap/cacerts/sf_bundle.crt


[root@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 -

Code: 
TLSCACertificateFile  /usr/local/etc/openldap/cacerts/gd_bundle.crt

[root@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!

Code: 
[root@VIRTCENT08:/etc/openldap/cacerts]#ssh bluethundr@localhost
bluethundr@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! ;)
 

Attachments

  • openldap.txt
    17.3 KB · Views: 277
Self signed certs, same situation

Ok, at this point I realize that the problem with the godady cert is that in the creation of the cert I entered the name according to the dns name bsd2.summitnjhome rather than the output of the hostname command which was LBSD2.summitnjhome.com!! spelleing is everything in unix eh? ;)

So tho I could just change the hostname to LBSD2.summitnjhome.com I need the server to have a valid cert so I will have to get the cert re-issued. This, according to GD ssl support will take a couple of days. That's ok.

But in the meantime I tried issuing a self signed cert and got this result:

This is how I entered it into slapd.conf:
Code: 
LBSD2# cat slapd.conf | grep -i TLS
## TLS options for slapd
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile  /usr/local/etc/openldap/cacerts/slapd.crt 
TLSCertificateKeyFile /usr/local/etc/openldap/cacerts/slapd.key
# TLSCACertificateFile  /usr/local/etc/openldap/cacerts/sf_issuing.crt

These are the modes and ownership on the cacerts dir:

Code: 
LBSD2# ls -l
total 16
dr--r-----  2 root  ldap   512 Nov 22 00:28 bak
-r--r-----  1 root  ldap  2069 Nov 22 01:55 slapd.crt
-r--r-----  1 root  ldap  1785 Nov 22 01:54 slapd.csr
-r--r-----  1 root  ldap  3243 Nov 22 01:56 slapd.key
-r--r-----  1 root  ldap  3311 Nov 22 01:52 slapd.key.secure

And this is the result when I try to set it up on the CentOS 5.5 client:

Code: 
[root@VIRTCENT08:~]#setup
unable to load certificate
2199:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: TRUSTED CERTIFICATE
unable to load certificate
2208:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: TRUSTED CERTIFICATE
unable to load certificate
2209:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: TRUSTED CERTIFICATE
unable to load certificate
2210:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:647:Expecting: TRUSTED CERTIFICATE

And this is what an SSL test shows:

Code: 
[root@VIRTCENT08:~]#openssl s_client -connect ldap.summitnjhome.com:389 -showcerts
CONNECTED(00000003)
2225:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

It's almost identical to the output of a server I build a few days ago that also has a self-signed cert:

Code: 
[root@VIRTCENT08:~]#openssl s_client -connect ldap.example.net:389 -showcerts
CONNECTED(00000003)
2220:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

I would certainly appreciate any input you may have.. ;)

But in
 
Did you ever find a solution for this? I am having the same trouble, and all I see people saying online is read the man pages for ldap.conf. However, after attempting to verify the connection to the ldap server with openssl, it is obviously not an issue with the ldap.conf file, it appears to be server configuration.
 
You must log in or register to reply here.
Back
Top