I've been running an openLDAP server for several months now and we use it to authenticate for a number of applications. A previous staff member set up the server and it doesn't seem to be a standard installation but it's pretty straightforward.
Recently one of our CA certificates expired and the decision was made to replace it with Let's Encrypt. My manager replaced the certificate on the server.
It works for the web application (LDAP Manager, self-service password changing), however no clients can authenticate against it. For example, if I try to test a Redmine LDAP configuration, I get a message saying "Unable to connect (SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A)"
Testing Nexus authentication against it it just doesn't connect.
Frustratingly there is nothing in the logs either on the LDAP server or those with the applications to indicate why this is failing. My investigations lead me to believe that it is something to do how the certificate/key are configured but I have tried everything I can think of and everything I can find online and nothing works.
Environment details are:
Debian 8 openLDAP openldap-2.4.40
My config is as below:
# LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/letsencrypt/live/myserver.com/fullchain.pem
dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: c6dd9e40-9dc2-1035-8c03-add74f928a5e creatorsName: cn=config createTimestamp: 20160423171552Z entryCSN: 20160423171552.629347Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20160423171552Z
If I test the connection:
admin@ldap:~$ sudo openssl s_client -connect localhost:636 -showcerts -state -CAfile /etc/letsencrypt/live/myserver.com/fullchain.pem CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A 140394818631312:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 289 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE
Does anyone had any idea what I am missing?
As per suggestion from @84104 I have edited the tls.ldif file to read as follows:
dn: cn=config changetype: modify replace: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/letsencrypt/live/myserver/fullchain.pem - replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/letsencrypt/live/myserver/cert.pem - replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/letsencrypt/live/myserver/privkey.pem
Then run the command:
ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif
However the output I now get is:
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Other (e.g., implementation specific) error (80)
I found suggestion this may be due to permissions on the certificate or key files but I changed these to match exactly with the ones on the previously used files and still got this message.
Again I apologise for my lack of general knowledge on the topic but can anyone suggest anything else?
As per the suggestion I altered tls.ldif and changed all the commands from replace to delete, then ran the ldapmodify command again. There is another error.
admin@ldap:/etc/ansible_ldif_work$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.remove.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Inappropriate matching (18) additional info: modify/delete: olcTLSCACertificateFile: no equality matching rule