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
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.
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"
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.
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.
You might ask RedHat, the Apache user support mailing list, or another forum such as serverfault.com.
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.
Happening when the ldap server is using self-signed certificates. Try : LDAPVerifyServerCert Off or more secure : LDAPTrustedGlobalCert with your ca certificate Nf
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.
> 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?
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.
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.
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
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
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.