Starting with Fedora 28, something seems to break the SSSD TLS/SSL connection to our LDAP server. It also fails with Fedora 29. It fails at:
Could not start TLS encryption. Start TLS request accepted. Server willing to negotiate SSL.
I also see some additional errors in the debug log (iv'e removed things that are not relevant): [sbus_issue_request_done] sssd.dataprovider.getDomains: Error: DP target is not configured [sss_ldap_init_sys_connect_done] : ldap_install_tls failed: [connect error] [unknown error] [sdap_sys_connect_done]: sdap_async_connect_call request failed: input/output error
It was previously working with Fedora 27 fine. But i've noticed that is an older version of SSSD.
If I curl the ldaps:// address of our ldap server. I get curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to our server name.
I've tried running: openssl ciphers -v ALL
It only seems to show TLSv1.3 I tried running: update-crypto-policies --set LEGACY ; update-crypto-policies and then run "openssl ciphers -v ALL" again but error seems to still occur with TLS connections to servers. I can see that LEGACY has enabled old TLS versions on the system.
Did you use nss db certificates with openldap ? The support fort nss was removed in f29 and I saw some issues with runtime conversion in f28.
https://src.fedoraproject.org/rpms/openldap/c/5411c8463a0e092d60913bc22fd6dbe7e987becd?branch=f29
That is a good question. How would I check to see if we are using that or not? If it is on the client side, it is basically just a default Fedora 29 install with no customization yet.
We do have services = nss, pam, autofs in the /etc/sssd/sssd.conf file.
Certificates for openldap libs can be configured in /etc/openldap/ldap.conf (TLS_CACERT, TLS_CACERTDIR ) or in domain section of /etc/sssd/sssd.conf (ldap_tls_cacert, ldap_tls_cacertdir).
/etc/openldap/ldap.conf
/etc/sssd/sssd.conf
man ldap.conf also says:
When using OpenSSL, if neither TLS_CACERT nor TLS_CACERTDIR is set, the system-wide default set of CA certificates is used.
Ok. Yes. I have added our CA and it is defined using ldap_tls_cacert in /etc/sssd/sssd.conf. I have also installed our CA in /etc/pki/ca-trust and updated the "update-ca-trust" command.
The main errors I see now are when doing a curl to the ldaps address: curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to our server name.
I also see some additional errors in the sssd domain debug log (iv'e removed things that are not relevant): [sbus_issue_request_done] sssd.dataprovider.getDomains: Error: DP target is not configured [sss_ldap_init_sys_connect_done] : ldap_install_tls failed: [connect error] [unknown error] [sdap_sys_connect_done]: sdap_async_connect_call request failed: input/output error
I was able to resolve the issue by specifically setting a cipher I know the ldap server supports:
So in /etc/openldap/ldap.conf I set the "TLS_CIPHER_SUITE" to a suite that I got from simply doing a curl to the ldaps:// address on a server that works.
Although I still get curl error: curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to our server name.
It might be better to test with ldapsearch instead of curl.
ldapsearch
curl
Fedora openldap maintainer @mhonek might help you with some tips for debugging. (I used to test with ldapsearch -d 7 and ldaps port)
ldapsearch -d 7
I was able to resolve the issue by specifically setting a cipher I know the ldap server supports: So in /etc/openldap/ldap.conf I set the "TLS_CIPHER_SUITE" to a suite that I got from simply doing a curl to the ldaps:// address on a server that works. Although I still get curl error: curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to our server name.
IMHO, it would be better to do some hardening on server instead of using weaker cypers :-)
Please close issue if it work for you.
Thanks!
Metadata Update from @warthur: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4970
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.