Bug 244797 - sudo requires redundant "ssl on" in /etc/ldap.conf
sudo requires redundant "ssl on" in /etc/ldap.conf
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: sudo (Show other bugs)
6
All Linux
medium Severity high
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-19 04:46 EDT by Pawel Salek
Modified: 2008-04-04 04:44 EDT (History)
1 user (show)

See Also:
Fixed In Version: 1.6.9p4-4.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 04:44:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pawel Salek 2007-06-19 04:46:06 EDT
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.
Comment 1 Pawel Salek 2007-06-19 04:57:56 EDT
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...
Comment 2 Bug Zapper 2008-04-04 03:25:33 EDT
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
Comment 3 Pawel Salek 2008-04-04 04:44:15 EDT
This appears to be fixed in F8.

Note You need to log in before you can comment on or make changes to this bug.