Bug 50630 - Apache return 500 error with authentication by LDAP secure port (ldaps)
Summary: Apache return 500 error with authentication by LDAP secure port (ldaps)
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_authz_ldap (show other bugs)
Version: 2.2.13
Hardware: PC Linux
: P2 normal with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2011-01-21 08:36 UTC by Ignasi
Modified: 2018-11-07 21:08 UTC (History)
3 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ignasi 2011-01-21 08:36:03 UTC
We have Linux RHEL6 with httpd 2.2.15, and after loged with LDAP username and
password, apache return 500 error. Return this error only if you use ldaps (port 636), for ldap (port 389) works fine.

No information available about this error in the server error log.

With the follow configuration:

# vim: syntax=apache

<VirtualHost _default_:443>
    SSLEngine On
    SSLProtocol all -SSLv2
    SSLCipherSuite HIGH:MEDIUM
    SSLCertificateFile /etc/pki/tls/certs/xxx.crt
    SSLCertificateKeyFile /etc/pki/tls/private/xxxxxxxxx.key
    ServerName xxxxxxxxxx
    ServerAlias xxxxxxxxxxxxx
    DocumentRoot /var/www/xxxxxxxx
    # Specific configuration
    <Location /private/status>
        SetHandler server-status
    </Location>
    <Location />
        AuthType Basic
        AuthName "Admin xxxxxx"
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative on
        AuthLDAPURL ldaps://ldap.xxxxxxxx.com/ou=People,dc=xxxxx,dc=com?uid?one
        Require ldap-user xxxx xxxx
    </Location>
    ErrorLog logs/xxxxxxxx-ssl-error_log
    CustomLog logs/xxxxxxxxx-ssl-access_log combined
</VirtualHost>

Modules loaded:

auth_basic_module
ldap_module
authnz_ldap_module


The same configuration works with RHEL5.x and httpd 2.2.3
Comment 1 Eric Covener 2011-01-21 09:16:26 UTC
Set LogLevel debug and attach the messages that accompany the LDAP authentication/authorization.  If you don't see any, you're not looking in the right log.
Comment 2 Ignasi 2011-01-21 10:01:23 UTC
We stopped httpd, we deleted all the logs and then we started httpd and tried to access the site, just once. Apache does not write anything in any error log file when the 500 Internal Server Error happens. 

# ls -al /var/log/httpd/
total 16
drwx------. 2 apache apache 4096 Jan 21 15:56 .
drwxr-xr-x. 8 root   root   4096 Jan 18 13:50 ..
-rw-r--r--. 1 root   root      0 Jan 21 15:56 access_log
-rw-r--r--. 1 root   root   3038 Jan 21 15:56 error_log
-rw-r--r--. 1 root   root    595 Jan 21 15:56 takeover-ssl-access_log
-rw-r--r--. 1 root   root      0 Jan 21 15:56 takeover-ssl-error_log

# cat /var/log/httpd/*
[Fri Jan 21 15:56:13 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:SystemLow
[Fri Jan 21 15:56:13 2011] [info] Init: Seeding PRNG with 0 bytes of entropy
[Fri Jan 21 15:56:13 2011] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Fri Jan 21 15:56:13 2011] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Fri Jan 21 15:56:13 2011] [warn] Init: Session Cache is not configured [hint: SSLSessionCache]
[Fri Jan 21 15:56:13 2011] [info] Init: Initializing (virtual) servers for SSL
[Fri Jan 21 15:56:13 2011] [info] mod_ssl/2.2.15 compiled against Server: Apache/2.2.15, Library: OpenSSL/1.0.0-fips
[Fri Jan 21 15:56:13 2011] [debug] util_ldap.c(2058): LDAP merging Shared Cache conf: shm=0x7fe25bad19f8 rmm=0x7fe25bad1a50 for VHOST: takeover.fluendo.lan
[Fri Jan 21 15:56:13 2011] [info] APR LDAP: Built with OpenLDAP LDAP SDK
[Fri Jan 21 15:56:13 2011] [info] LDAP: SSL support available
[Fri Jan 21 15:56:13 2011] [info] Init: Seeding PRNG with 0 bytes of entropy
[Fri Jan 21 15:56:13 2011] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Fri Jan 21 15:56:13 2011] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Fri Jan 21 15:56:13 2011] [info] Init: Initializing (virtual) servers for SSL
[Fri Jan 21 15:56:13 2011] [info] mod_ssl/2.2.15 compiled against Server: Apache/2.2.15, Library: OpenSSL/1.0.0-fips
[Fri Jan 21 15:56:13 2011] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 0 in child 25893 for worker proxy:reverse
[Fri Jan 21 15:56:13 2011] [debug] proxy_util.c(1934): proxy: initialized single connection worker 0 in child 25893 for (*)
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 0 in child 25894 for worker proxy:reverse
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1837): proxy: worker proxy:reverse already initialized
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1934): proxy: initialized single connection worker 0 in child 25894 for (*)
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 0 in child 25895 for worker proxy:reverse
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1837): proxy: worker proxy:reverse already initialized
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1934): proxy: initialized single connection worker 0 in child 25895 for (*)
[Fri Jan 21 15:56:14 2011] [notice] Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured -- resuming normal operations
[Fri Jan 21 15:56:14 2011] [info] Server built: Aug 14 2010 08:53:20
[Fri Jan 21 15:56:14 2011] [debug] prefork.c(1013): AcceptMutex: sysvsem (default: sysvsem)
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 0 in child 25896 for worker proxy:reverse
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1837): proxy: worker proxy:reverse already initialized
[Fri Jan 21 15:56:14 2011] [debug] proxy_util.c(1934): proxy: initialized single connection worker 0 in child 25896 for (*)
172.17.5.59 - - [21/Jan/2011:15:56:32 +0100] "GET / HTTP/1.1" 401 401 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10"
172.17.5.59 - sgafsgaf [21/Jan/2011:15:56:42 +0100] "GET / HTTP/1.1" 500 536 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10"
172.17.5.59 - sgafsgaf [21/Jan/2011:15:56:42 +0100] "GET /favicon.ico HTTP/1.1" 500 536 "-" "Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10"
Comment 3 Eric Covener 2011-01-21 10:26:58 UTC
I don't see any way for mod_authnz_ldap to return an error before logging anything.  It should be quite noisy at LogLevel debug.
Comment 4 Ignasi 2011-01-21 10:42:37 UTC
What do you recommend? 

I don't know if httpd version 2.2.15 with RHEL6 can be important. Because the same configuration works with httpd (2.2.3) and RHEL5.2.
Comment 5 Eric Covener 2011-01-21 10:54:13 UTC
You might ask RedHat, the Apache user support mailing list, or another forum such as serverfault.com.
Comment 6 Scott A. Hendrickson 2011-07-25 23:17:41 UTC
The exact same thing is happening to us. We're also using RHEL 6 and Apache 2.2.15 and the error only occurs after a successful login. Nothing is sent to the log files even with LogLevel debug.
Comment 7 Nicolas Fillot 2011-09-26 18:10:56 UTC
Happening when the ldap server is using self-signed certificates.

Try :
    LDAPVerifyServerCert Off

or more secure :
   LDAPTrustedGlobalCert with your ca certificate

Nf
Comment 8 Andrew Daviel 2011-09-28 19:08:20 UTC
I have seen this on httpd.2.15-9 on SL 6.1 (RHEL 6.1 recompile)
with openssl-1.0.0 and openldap-2.4.23

Openldap now checks the certificate chain against a certificate bundle. On RHEL6 this is located in /etc/pki/tls/certs/ca-bundle.crt
Openldap reads a configuration file /etc/openldap/ldap.conf and uses the value of TLS_CACERT to locate this bundle.
If it does not locate the bundle, or the LDAP server certificate chains to a root certificate that is not included in the bundle, openldap returns an error.

(ldapsearch on the command line returns 
 ldap_start_tls: Connect error (-11)
    additional info: TLS error -8172:Unknown code ___f 20
With the "-d 1" option, it says that the server certificate is not valid.)

From the point of view of mod_authnz_ldap, I infer that the module is not properly handling an error return from the LDAP library. It should generate an error message in the webserver log to give the server admin a clue to the real problem.
Comment 9 Eric Covener 2011-09-28 19:47:16 UTC
> From the point of view of mod_authnz_ldap, I infer that the module is not
> properly handling an error return from the LDAP library. It should generate an
> error message in the webserver log to give the server admin a clue to the real
> problem.

no logs at all currently as in OP? Or just not alluding to trust issue?
Comment 10 Andrew Daviel 2011-09-28 19:54:28 UTC
I could not see any error message in /var/log/httpd/* apart from a single
192.168.2.1  - advax [28/Sep/2011:12:51:01 -0700] "GET /index.shtml HTTP/1.0" 500 631

wget as client returns 
  HTTP/1.1 500 Internal Server Error

Generally, errors in CGI scripts etc. generate something in error_log from the script itself, e.g. sigsegv, runtime errors etc.
Comment 11 Mark A. Ziesemer 2012-02-25 20:09:52 UTC
Same issue here - httpd-2.2.22, compiled against openldap-2.4.29 under RHEL 5.7.

Adding "LDAPVerifyServerCert Off" works.  However, I prefer the more secure option of using "LDAPTrustedGlobalCert" - but this does not work, and still, no logging to help point to why.

I did add the same certificate to ldap.conf using TLS_CACERT - and this allows ldapsearch to work using the command line ldapsearch (with -Z for "Start TLS request").  However, this doesn't seem to help httpd any.
Comment 12 Jirong Hu 2013-09-24 15:17:02 UTC
I am running into the exact same issue, "Internal Server Error" with no error message at all. Log message same as Comment 2. Even we are using port 389, and set LDAPVerifyServerCert Off also doesn’t resolve my issue.

Here is my software versions:

Linux 2.6.32-358.18.1.el6.x86_64 x86_64
Apache/2.2.15 (Red Hat) Server at cmtoldsvnapp01.dev.bmocm.com Port 443
svn, version 1.6.11 (r934486)  compiled Apr  2 2013, 08:56:54
Comment 13 Dominik George 2014-05-30 07:08:04 UTC
We have a very related issue here. The funny thing is, however, that the problem only starts to occur a few hours after Apache was started. Before that, the LDAPS connections work just fine.

When the problem occurs, we see the LDAP server send TCP connection resets after the SSL negotiation.

Apache Server version: 2.2.22
OS version: Debian GNU/Linux 7.5 amd64

Cheers,
Dominik George

-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-319 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Comment 14 William A. Rowe Jr. 2018-11-07 21:08:23 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.