Authproxy showing "unable to establish ssl" error... who has the issue

[Ken Stieers]

I'm seeing the following error in my authproxy.log;

2024-12-03T13:14:29.960557-0600 [duoauthproxy.modules.ad_client._ADServiceClientFactory#info] Starting factory <duoauthproxy.modules.ad_client._ADServiceClientFactory object at 0x000001A6499EA810>
2024-12-03T13:14:29.960557-0600 [duoauthproxy.lib.log#error] Unable to establish SSL connection. Client may be attempting incompatible protocol version or cipher.
2024-12-03T13:14:29.960557-0600 [duoauthproxy.modules.ad_client._ADServiceClientFactory#info] Stopping factory <duoauthproxy.modules.ad_client._ADServiceClientFactory object at 0x000001A6499EA810>

I've enabled Debug in the autproxy.cfg, but I'm not getting any better information. 

How can I get the logs to tell me which Authproxy client is failing? 

[DuoKristina]

>Client may be attempting incompatible protocol version or cipher.

I'm guessing you have an ldap_server_auto section in your authproxy.cfg?

Here, the Duo Authentication Proxy is reporting an issue negotiating SSL with whatever the downstream LDAP application is as it's trying to make its outgoing LDAP bind.

Use Wireshark or your preferred tool to capture that incoming LDAP auth from the downstream application, and look at the client and server hello packets to see if you can find a mismatch in protocol or lack over overlapping ciphers.

If you really see no LDAP binds attempted even with debug logging on (remember you have to cycle the proxy service for edits to authproxy.cfg to become effective) it could be that something is connecting to your Duo proxy on the LDAPS port (636 default) and then closing the connection instead of negotiating SSL, and the proxy is just logging a misleading message.

[Ken Stieers]

Yep, I’m using LDAP_Server Auto…
Authproxy ADClient is connecting to a Windows Domain Controller.

And looking a the Wireshark, the AuthProxy is sending a reset after the domain controller sends a Change Cipher Spec message, but that’s after they’ve already agreed on a cipher.

2456 35.829062 DUO1 59304 DC1 636 TLSv1.2 286 Client Hello (SNI=)
2457 35.829936 DC1 636 DUO1 59304 TCP 1514 636 → 59304 [ACK] Seq=1 Ack=233 Win=2097664 Len=1460 [TCP PDU reassembled in 2458]
2458 35.829936 DC1 636 DUO1 59304 TLSv1.2 1036 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
2459 35.829985 DUO1 59304 DC1 636 TCP 54 59304 → 636 [ACK] Seq=233 Ack=2443 Win=2102272 Len=0
2460 35.833467 DUO1 59304 DC1 636 TLSv1.2 224 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
2461 35.834467 DC1 636 DUO1 59304 TLSv1.2 105 Change Cipher Spec, Encrypted Handshake Message
2462 35.835026 DUO1 59304 DC1 636 TCP 54 59304 → 636 [RST, ACK] Seq=403 Ack=2494 Win=0 Len=0

[DuoKristina]

What do you see in the packet capture regarding communications between the Duo proxy and the downstream LDAP application? That is the point where the authproxy should take an incoming bind from the LDAP application and proxy the bind request to the DC.