Can you check if 'ldapsearch -ZZ ....' works from the command line with the same TLS_REQCERT value in /etc/openldap/ldap.conf you use in sssd.conf?

Have you used the same configuration including the CAcert file before on F14?

Is it possible that this issue is related to https://bugzilla.redhat.com/show_bug.cgi?id=657984 ?

description: SSSD has been working in the past, but I reinstalled a client today and got the error message when trying to authenticate with a password:

Dec 3 13:37:26 prodigy sssd[be[LDAP]]: Could not start TLS encryption. (null)

Unfortunately, the error isn't making it obvious what the problem is. I have also tried running sssd with a higher debug level, and although it gives more detail, I'm still not sure what the error means:

(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x2361690], connected[1], ops[0x236b0e0], ldap[0x2361c00]
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_connect_done] (3): START TLS result: Success(0), (null)
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_connect_done] (3): ldap_install_tls failed: [Connect error] [(null)]
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_handle_release] (8): Trace: sh[0x2361690], connected[1], ops[(nil)], ldap[0x2361c00], destructor_lock[0], release_memory[0]
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [fo_set_port_status] (4): Marking port 389 of server '192.168.36.6' as 'not working'
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, <NULL>) [Internal Error (Interrupted system call)]
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [be_pam_handler_callback] (4): Sending result [4][LDAP]

So I guess I have two questions: a) are there any suggestions about how to find why TLS is failing? and b) is there any way that the error messages could be more helpful? This system is running sssd version sssd-1.4.1-3.fc14.x86_64. Please let me know if there is any other information I should provide. Thanks. => SSSD has been working in the past, but I reinstalled a client today and got the error message when trying to authenticate with a password:

Dec 3 13:37:26 prodigy sssd[be[LDAP]]: Could not start TLS encryption. (null)

Unfortunately, the error isn't making it obvious what the problem is. I have also tried running sssd with a higher debug level, and although it gives more detail, I'm still not sure what the error means:

{{{
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x2361690], connected[1], ops[0x236b0e0], ldap[0x2361c00]
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_connect_done] (3): START TLS result: Success(0), (null)
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_connect_done] (3): ldap_install_tls failed: [Connect error] [(null)]
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_handle_release] (8): Trace: sh[0x2361690], connected[1], ops[(nil)], ldap[0x2361c00], destructor_lock[0], release_memory[0]
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [fo_set_port_status] (4): Marking port 389 of server '192.168.36.6' as 'not working'
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, <NULL>) [Internal Error (Interrupted system call)]
(Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [be_pam_handler_callback] (4): Sending result [4][LDAP]
}}}

So I guess I have two questions: a) are there any suggestions about how to find why TLS is failing? and b) is there any way that the error messages could be more helpful? This system is running sssd version sssd-1.4.1-3.fc14.x86_64. Please let me know if there is any other information I should provide. Thanks.

I finally tracked down what was causing the error; somehow it was not able to find the cacert. This is really weird because /etc/openldap/ldap.conf contained the line "TLS_CACERTDIR /etc/openldap/cacerts", and /etc/openldap/cacerts had a symlink to the cacert. When I added an "ldap_tls_cacert" line to sssd.conf, it started working. It seems like it should have been working without the "ldap_tls_cacert" line since the sssd-ldap man page says "Default: use OpenLDAP defaults, typically in /etc/openldap/ldap.conf".

Unfortunately, I couldn't find any error messages that helped me track this down--it seems like SSSD should be reporting an error like, "no cacert found" or "server's certificate not signed by any known certauth" or something like that.

I am happy to try "ldapsearch -ZZ", but I'm not sure if I need to specify extra options:

[root@genius ~]# ldapsearch -ZZ
ldap_start_tls: Connect error (-11)
[root@genius ~]#

I am pretty sure that I have had the exact same configuration in F14 before.

I think this is unrelated to Fedora bug 657984 because my cert has CA:TRUE.

Thank you for your feedback. It looks like the symlink is not followed as expected. I'll check if this is related to the change from OpenSSL to NSS.

Which version of OpenLDAP are you using? Can you update to the latest version any try again?

Here are the openldap packages we are running:

openldap-2.4.23-4.fc14.x86_64
openldap-devel-2.4.23-4.fc14.x86_64
openldap-2.4.23-4.fc14.i686
openldap-servers-2.4.23-4.fc14.x86_64
openldap-clients-2.4.23-4.fc14.x86_64

There does not seem to be a newer version available in the Fedora 14 repositories.

I'm trying to reproduce your setup, but so far I always succeed.

This is what I have done:

• created a directory /tmp/cacert and set TLS_CACERTDIR in /etc/openldap/ldap.conf to this directory, but not in sssd.conf
• create a symbolic link to the pem file with the CA for my ldap server in /tmp/cacert
• run 'c_rehash .' in /tmp/cacert

Can you tell me how your setup differ?

Btw the additional options for ldapsearch are:

ldapsearch -ZZ -h <hostname_of_the_LDAP_server> -x -b '<base_dn_of_the_LDAP_server>'

This should show you all objects which are accessible with an anonymous bind. To bind as a user add "-D '<dn_of_the_user>' -W" and you will be prompted for the password.

amcnabb, can you please answer Sumit's questions above?

I'm moving this ticket into WORKSFORME due to lack of provided information.

amcnabb, you may reopen this ticket if you can provide answers to the above questions.

coverity: =>
resolution: => worksforme
status: new => closed

I think I have identified how our setups differ.

To reproduce, try making TLS_CACERTDIR set to /etc/openldap/cacerts (the default), and inside /etc/openldap/cacerts, create a symlink called cacert.pem that points to /tmp/cacert/cacert.pem.

Sorry for my late response.

resolution: worksforme =>
status: closed => reopened

Have you called 'c_rehash /etc/openldap/cacerts' after creating the symlink? There must be a symlink in /etc/openldap/cacerts which points to cacert.pem in /etc/openldap/cacerts and has a name like <subject_hash>.0 . Otherwise the CA certificate cannot be found.

upgrade: => 0

Considering that c_rehash does not seem to be installed, I'm pretty sure it has not been run. :) It's interesting that c_rehash apparently does not need to be run when sssd.conf points directly to /tmp/cacert.

Anyway, changing sssd.conf wasn't really a big deal, but it was very frustrating not to have any error message more specific than "Could not start TLS encryption. (null)". It would have been much easier to track down the problem if it had said something about not being able to verify the certificate.

Replying to [comment:12 amcnabb]:

Considering that c_rehash does not seem to be installed, I'm pretty sure it has not been run. :) It's interesting that c_rehash apparently does not need to be run when sssd.conf points directly to /tmp/cacert.

Can you confirm that c_rehash solved the problem?

Anyway, changing sssd.conf wasn't really a big deal, but it was very frustrating not to have any error message more specific than "Could not start TLS encryption. (null)". It would have been much easier to track down the problem if it had said something about not being able to verify the certificate.

Unfortunately, that "(NULL)" you see there was our attempt to pass back up to you the error as it's reported by the openldap libraries we use internally. The openldap libraries gave us no information why it failed, so we couldn't identify it ourselves.

Replying to [comment:13 sgallagh]:

Can you confirm that c_rehash solved the problem?

Is this the c_rehash in the openssl-perl package or is it the cacertdir_rehash program in the authconfig package?

Unfortunately, that "(NULL)" you see there was our attempt to pass back up to you the error as it's reported by the openldap libraries we use internally. The openldap libraries gave us no information why it failed, so we couldn't identify it ourselves.

Would the upstream openssl developers be interested in a bug report? I've seen a number of times when sssd failed to give useful information with TLS problems, and from what you're saying, it sounds like openldap is where the problems really lie.

Replying to [comment:14 amcnabb]:

Replying to [comment:13 sgallagh]:

Can you confirm that c_rehash solved the problem?

Is this the c_rehash in the openssl-perl package or is it the cacertdir_rehash program in the authconfig package?

Both are ok.

I filed a bug upstream with openldap: http://www.openldap.org/its/index.cgi/Incoming?id=6789

In the meantime, I'm closing this as wontfix (from the SSSD perspective).

Thanks for your help with tracking this down!

resolution: => wontfix
status: reopened => closed

Fields changed

milestone: NEEDS_TRIAGE => void

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/1741

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.