On Thu, 19 Sep 2013, espeake@oreillyauto.com wrote:
We have a client server that is failing on the ssl handshake using TLS. The following is from the server log when the client is trying to connect.
Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from IP=172.17.1.10:55469 (IP=0.0.0.0:389) Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid= err=0 text= Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS negotiation failure)
On the client when I run the following:
openssl s_client -showcerts -connect tntest-ldap.oreillyauto.com:389
That doesn't do StartTLS (like your client is attempting), though.
Try something like https://groups.google.com/forum/#!topic/mailing.openssl.users/1OOwXp45iIw if you'd like. Or OpenLDAP Software such as ldapsearch(1).
Turning up the slapd(8) debug level may be of some use, too.
I get this on the client
CONNECTED(00000003) 139669033973408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 226 bytes
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE
If I do the same command on port 636 I can see the certificate. All of our applications that use ldap are all set for TLS. Even if I force them to port 636 they fail.
Any ideas to look at are appreciated.
Eric Speake Web Systems Administrator O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS ? 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.