Bug #8020
closed
Can't STARTTLS to LDAP server since 2.4.0
0%
Description
This setup was running fine until my upgrade to 2.4.0 (and 2.4.1). I'm running an OpenLDAP server (on EL6). This LDAP server is using a Let's Encrypt certificate. The intermediate certificate is correctly sent by the server. On PfSense, I'm also using a Let's Encrypt certificate (obtains with the ACME addon), which has automatically created the "Acmecert: O=Let's Encrypt, CN=Let's Encrypt Authority X3, C=US" CA in the certificate manager. This CA is set as the trusted CA of the LDAP server on PfSense (User manager -> Authentication servers)
The LDAP server is configured to use TCP - STARTTLS
Since I've upgraded to 2.4.0, all I get in the system logs is:
/system_authservers.php: ERROR! ldap_get_user_ous() could not STARTTLS to server .
If I switch to SSL, it's still can't connect, but the error message is different:
/system_authservers.php: ERROR! ldap_get_user_ous() could not bind anonymously to server .
From the command line, I can use ldapsearch with STARTTLS without problem
ldapsearch -x -ZZ -H ldap://ldap.domain.com -b dc=domain,dc=com
[...]
So it looks like something changed in the way the certificate chain is verified. I've also tried to import the intermediate certificate and set this one as trusted CA for this LDAP server, but still the same issue
Updated by Daniel Berteaud over 6 years ago
Forgot to add, when PfSense attempts to connect on my LDAP server, I see this on the server side:
TLS: error: accept - force handshake failure: errno 0 - moznss error -12195
TLS: can't accept: TLS error -12195:Peer does not recognize and trust the CA that issued your certificate..
59f451f9 conn=1467 fd=26 closed (TLS negotiation failure)
Which indicates a certificate validation issue on the client. On a side note, I think the drop-down to choose the trusted CA should even be optional, with the default behavior to use system wide CA bundle
Updated by Jim Pingle over 6 years ago
- Status changed from New to Duplicate
I ended up making a new issue for this, see #8044 for the fix.