[Samba] Stymied with samba vs openldap SSL ("Failed to issue the StartTLS instruction...")

[Lee Brown]

On Wed, Jan 6, 2016 at 12:56 PM, Graham Allan <allan at physics.umn.edu> wrote:

> On 01/06/2016 01:34 PM, Lee Brown wrote:
>
>> On Wed, Jan 6, 2016 at 10:36 AM, Graham Allan <allan at physics.umn.edu
>> <mailto:allan at physics.umn.edu>> wrote:
>>
>>     On 01/06/2016 09:53 AM, Graham Allan wrote:
>>
>>
>>         The packet dump is a good idea. I get the same failure using
>>         straight
>>         SSL to port 636, but wireshark might be able to decode any
>> StartTLS
>>         negotiation attempt on the default port. Failing that I guess I'll
>>         resort to running smbd in gdb...
>>
>>
>>     tshark tells me 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.
>>
>>     Puzzling, it doesn't seem like a certificate validation error, I'd
>>     expect that to result in something like codes 42-48.
>>
>>
>> I'd be very interested to see how you troubleshoot this.  I'm running
>> FreeBSD 10.1, samba 4.2.3, but I don't use openldap as the backend,
>> samba is my LDAP now as it does Active Directory.  I've found SSL to be
>> incredibly hard to troubleshoot, especially when client certs get
>> involved as it gets hard to determine if the problem is on the server
>> side not liking the client cert, or the client side not liking the
>> server cert.  In some cases I've had to bundle the entire chain in a
>> single file, while others I've had to point to a directory of certs.
>>
>
> gdb didn't give me much new, though for the record, it needed a couple of
> things to be usable: (1) install newer gdb from ports, and (2) build samba
> with --disable-pie
>
> What I got from that was ldap_start_tls_s (ldap_struct, NULL, NULL) in
> smb_ldap_start_tls is returning -11 (LDAP_CONNECT_ERROR), which doesn't
> really help.
>
> 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)
>
> I'm out of ideas for now, other than maybe trying one of the openldap
> lists!
>
That's about the stage I can never dig deeper into.  OK, so we know
application X is having an SSL failure, so how can we crank up the SSL
verbosity?  Typically I can use openssl s_client to get a clue, although
you can't always do that either (Postgresql for example).