samba - Jan 2016 - Stymied with samba vs openldap SSL ("Failed to issue the StartTLS instruction...")

On Wed, Jan 6, 2016 at 10:36 AM, Graham Allan <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.

Good luck and please keep us updated.

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!

G.

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).

On 06/01/16 20:56, Graham Allan 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!
>
> G.
>
>
Have a look at this earlier post, it may help: 
https://lists.samba.org/archive/samba/2011-November/164855.html

Rowland