Bug 26390

Summary: LDAPTrustedCA inside VirtualHost
Product: Apache httpd-2 Reporter: giuliano carlini <stuff-1-apache>
Component: mod_ldapAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: CLOSED FIXED    
Severity: normal    
Priority: P3    
Version: 2.0.48   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description giuliano carlini 2004-01-24 00:50:54 UTC
LDAPTrustedCA inside of VirtualHost doesn't work. While it processed, as
demonstrated by the debug log:

    [Fri Jan 23 16:43:12 2004] [debug] util_ldap.c(1038): LDAP: SSL trusted
certificate authority file - /usr/share/ssl/CA/certs/ca-bundle.cert.pem
    [Fri Jan 23 16:43:12 2004] [debug] util_ldap.c(1054): LDAP: SSL trusted
certificate authority file type - BASE64_FILE
    ....
    [Fri Jan 23 16:46:12 2004] [debug] mod_auth_ldap.c(829): LDAP: auth_ldap
using SSL connections

It isn't used by the code in util_ldap_post_config()

    [Fri Jan 23 16:46:12 2004] [notice] LDAP: Built with OpenLDAP LDAP SDK
    [Fri Jan 23 16:46:12 2004] [notice] LDAP: SSL support unavailable

However, if the LDAPTrustedCA is moved outside of the VirtualHost to the global
context, then it works.

My guess is that st->cert_auth_file is being copied from the global context
rather than from the virtual host context.
Comment 1 Graham Leggett 2004-05-21 01:39:00 UTC
At the moment, the LDAPTrustedCA directive is only valid in the global context.

OpenLDAP supports setting the CA certs per connection, but I am not sure whether
the Netware, Microsoft or Netscape SDKs do. This won't be practical until more
info can be found on the other SDKs.
Comment 2 Graham Leggett 2004-05-21 20:07:52 UTC
Comment from dev@httpd.apache.org:

Brad Nicholes wrote:
>    This is something that I have been wanting to do for sometime but
> haven't given it much thought until now.  I talked to some of our Novell
> LDAP engineers to get a better perspective on this.  According to them,
> per-session certificates will not work in Novell LDAP and they also
> believe that it doesn't work for Netscape or Microsoft either.  They
> also had some concerns about OpenLDAP as well and although per-session
> certificates appear to be supported, they weren't sure how well it
> actually worked.  
>   Just looking at the code in the util_ldap_post_config() routine and
> how each of them set up the certificates, I wouldn't expect Netscape,
> Novell or Microsoft SDK's to support per-session certificates.  The
> Netscape SDK and the Novell SDK use the same function to initialize the
> SSL libraries, but even though the current util_ldap code for Novell
> isn't written this way, the Novell SDK allows the user to configure a
> list of certificates rather than a single certificate by calling
> ldapssl_add_trusted_cert().  The Netscape SDK probably allows for the
> same thing through their CERT7 database file which is required.  The
> Microsoft SDK appears to pull its certificate from the registry so I
> have no idea if it even allows for multiple certificates.  All of these
> methods appear to be global rather than per-session.  
>   My feeling is that about the best we could do is to allow the
> LDAPTrustedCA and LDAPTrustedCAType directives to be callable from
> within a virtualhost configurtion and keep a list of certificates that
> can then be passed to the LDAP libraries during the post_config.  But
> this would really only make sense for OpenLDAP and Novell.  Since
> Netscape requires a CERT7 database file, it wouldn't know how to handle
> multiple files and these directives are NOOPs for Microsoft.  Then it
> might lead the administrator to believe that certain virtual hosts are
> using certain certificates when in fact that wouldn't be the case.  All
> virtual hosts would use all specified certificates.
Comment 3 Graham Leggett 2004-05-22 01:16:28 UTC
Resolved to keep these directives global in scope for now, commit a fix to
v2.1.0-dev to throw an error if an attempt is made to place these directives
inside virtualhosts.
Comment 4 Graham Leggett 2004-05-25 16:53:47 UTC
Due to limitations in the LDAP libraries, CA cert settings are server wide.
v2.1.0-dev and v2.0.50 will throw an error if an attempt is made to define these
directives inside a virtualhost.