[Date Prev][Date Next]
Out of ideas when troubleshooting TLS negotiation failure
- To: firstname.lastname@example.org
- Subject: Out of ideas when troubleshooting TLS negotiation failure
- From: Graham Allan <email@example.com>
- Date: Wed, 6 Jan 2016 15:13:15 -0600
- Organization: Physics, University of Minnesota
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
This feels like a lame question, but I'm out of ideas, so...
I'm moving samba service between a couple of FreeBSD systems (9.3 to
10.2), and I'm stuck on getting samba on the new machine to connect to
our openldap server over ssl - frustrating since I've been running
samba+ldap for 15 years or so; feel sure I'm missing something basic!
The smbd-to-ldap connection works fine with no encryption, but I get
errors when using either TLS to port 389 ("Failed to issue the StartTLS
instruction: Connect error") or SSL to 636.
However I'm pretty certain it's not a certificate or CA validation
issue. All my other ldap clients on that server are working as expected,
including a simple "ldapsearch -ZZ". Both openssl s_client and
gnutls-cli show the ldap server certificate validating.
Maximum debugging on the ldap server gave me:
connection_read(3): TLS accept failure error=-1 id=1042, closing
conn=1042 fd=3 closed (TLS negotiation failure)
Running smbd under gbd shows ldap_start_tls_s (ldap_struct, NULL, NULL)
in smb_ldap_start_tls is returning -11 (LDAP_CONNECT_ERROR). That
doesn't give me any ideas, sadly!
Capturing the packet exchange between smbd and slapd, I'm seeing the
(smbd) client sends a "decrypt error" (TLS alert code 51) to the ldap
server after receiving the certificate, while the working "ldapsearch
-ZZ" moves on to client key exchange etc.
Besides all my other ldap clients working successfully, I think I'd
expect to see a TLS alert more like 42-48 if it were a cert validation
I'm not sure where to try looking next for the cause, would welcome any