httpd cannot connect via TLS to LDAP server after upgrade to fedora 14

[Ldap Tester]

After upgrading a machine from fedora 13 to fedora 14 (with all
updates), I was suddenly unable to get its httpd to authenticate
with my LDAP servers.  After connecting my browser to the web server
with https, and typing in my username and password,
I get an Internal Server Error response.
My configuration is:

LDAPTrustedGlobalCert CA_BASE64 /etc/pki/tls/certs/ca-bundle.crt
LDAPTrustedGlobalCert CA_BASE64 /etc/openldap/cacerts/cacert.asc
<Directory /var/www/html/ssl>
   AuthType Basic
   AuthName "User Login"
   AuthBasicProvider ldap
   AuthLDAPURL "ldap://serv1.foo.org serv2.foo.org/dc=foo,dc=org" TLS
   AuthzLDAPAuthoritative off
   require valid-user
   SSLOptions +StrictRequire
   SSLRequireSSL
</Directory>

The httpd debugging log shows:
auth_ldap authenticate: user XXXX authentication failed;
URI /ssl/staff/index.shtml
[LDAP: ldap_start_tls_s() failed][Connect error]

Changing AuthLDAPURL to use SSL instead of TLS also fails but with:
[LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]

tcpdump shows that the httpd client connects to the LDAP server,
and is sent:
Start TLSrequest accepted Server willing to negotiate SSL
but no certificate info is exchanged and the client quickly closes
the connection.

Changing AuthLDAPURL to use NONE makes it connect successfully.

serv1 uses a cert purchased from GoDaddy,
and serv2 uses a self signed cert
(which is /etc/openldap/cacerts/cacert.asc).
Both servers are 389-ds.
Both certs mentioned in LDAPTrustedGlobalCert are valid and world
readable.  ldapsearch is able to connect to both servers with TLS.

On another machine with the same httpd configuration, but still at
fedora 13, httpd is able to connect securely even
without the LDAPTrustedGlobalCert lines.


As a side note, after upgrading to fedora 14, I had to add
tls_cacertfile /etc/pki/tls/certs/ca-bundle.crt
to /etc/nss_ldap.conf and /etc/pam_ldap.conf
and also add
TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt
to /etc/openldap/ldap.conf
in order to get those to work.
Under fedora 13, everything worked without those lines.


I don't know if this is a problem with httpd's mod_authnz_ldap
or its mod_ldap or with openldap, or just a configuration mistake
on my part, but it used to work before the upgrade.
I have searched all over for an answer to this problem
because I can't believe that I am the only one having it,
but I have found nothing.
I welcome any ideas.

[Michael Cronenworth]

Ldap Tester wrote:
>  I don't know if this is a problem with httpd's
> mod_authnz_ldap
>  or its mod_ldap or with openldap, or just a configuration mistake
>  on my part, but it used to work before the upgrade.
>  I have searched all over for an answer to this problem
>  because I can't believe that I am the only one having it,
>  but I have found nothing.
>  I welcome any ideas. 
Fedora 14 had an undocumented feature where OpenLDAP switched from using 
OpenSSL to NSS. NSS isn't a mature or bugfree library and each time core 
utilities are switched to it (curl for example) NSS bugs spout their 
ugly heads. I'm not sure where the drive to use NSS-for-everything comes 
from, but that is for a separate thread.

As for your issue, with this change, defaults changed.

If any Red Hat NSS guy is listening, it would be nice to have your 
future work documented as a Fedora feature. Not only would you get 
recognition but there could be testing and documentation to go along 
with your new feature.

[James McKenzie]

On 1/31/11 2:14 PM, Michael Cronenworth wrote:
>  Ldap Tester wrote:
> > I don't know if this is a problem with httpd's mod_authnz_ldap
> > or its mod_ldap or with openldap, or just a configuration mistake
> > on my part, but it used to work before the upgrade.
> > I have searched all over for an answer to this problem
> > because I can't believe that I am the only one having it,
> > but I have found nothing.
> > I welcome any ideas.
>  Fedora 14 had an undocumented feature where OpenLDAP switched from using
>  OpenSSL to NSS. NSS isn't a mature or bugfree library and each time core
>  utilities are switched to it (curl for example) NSS bugs spout their
>  ugly heads. I'm not sure where the drive to use NSS-for-everything comes
>  from, but that is for a separate thread.
>  
I'll chime on this:  OpenSSL is not FIPS-140 compliant and thus is being 
removed from the list of approved Federal Security Software products in 
the United States.  NSS is on the list and thus can be used.

James McKenzie