Description of problem: sudo refuses to connect to the LDAP server to fetch the user data via LDAP-enabled NSS. The inspection of the communication reveals that it does not recognize server certificate. Other services fetching data via NSS has no such a problem. This is a blocker bug for sudo in LDAP enabled configuration. Version-Release number of selected component (if applicable): sudo-1.6.8p12-10 How reproducible: Always. Steps to Reproduce: 1. configure your box to autenticate against a LDAPS server that has your own certificate. 2. verify that other services work (ssh, ls -l, getent passwd, etc) 3. try sudo -s - it will keep retrying the server connection and logging messages in the log. Actual results: sudo -s hangs Expected results: sudo -s logs in. Additional info: sudo logs messages "sudo: nss_ldap: failed to bind to LDAP server ldaps://server/: Can't contact LDAP server" When "debug 1" is added to /etc/ldap.conf, sudo -s outputs following: TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=SE/ST=Stockholms laen/O=Royal Institute of Technology/OU=Theoretical Chemistry/CN=Theoretical Chemistry CA, issuer: /C=SE/ST=Stockholms laen/O=Royal Institute of Technology/OU=Theoretical Chemistry/CN=Theoretical Chemistry CA TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect. for comparison, "ls -l" displays TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 0, subject: /C=SE/ST=Stockholms laen/O=Royal Institute of Technology/OU=Theoretical Chemistry/CN=Th eoretical Chemistry CA, issuer: /C=SE/ST=Stockholms laen/O=Royal Institute of Technology/OU=Theoretical Chemistry/CN=Theoretical Chemistry CA TLS certificate verification: depth: 0, err: 0, subject: /C=SE/ST=Stockholms laen/L=Stockholm/O=Royal Institute of Technology/OU=Theoretical Che mistry/CN=server, issuer: /C=SE/ST=Stockholms laen/O=Royal Institute of Technology/OU=Theoretical Chemistry/CN=Theoretical Chemistry CA TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A IT seems that tls_cacert setting in /etc/ldap.conf is ignored. Some people mention sudo-specific "tls_cacertfile" flag but it does not appear to give expected result, either.
As it often happens, I succeeded to find a workaround. The relevant parts of my /etc/ldap.conf file used to be: --- cut here --- uri ldaps://neo.biotech.kth.se/ tls_cacertfile /etc/openldap/cacerts/cacert.pem tls_checkpeer yes --- cut here --- It turns out, that one has to add a redudant "ssl on" to make sudo read the CA certificate. Nothing else needs that...
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This appears to be fixed in F8.