Bug 46290 - 'SSLVerifyClient require' in httpd.conf creates SSL handshake error
'SSLVerifyClient require' in httpd.conf creates SSL handshake error
Product: Red Hat Linux
Classification: Retired
Component: apache (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-06-27 13:23 EDT by doug johnson
Modified: 2007-04-18 12:34 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-21 06:46:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description doug johnson 2001-06-27 13:23:38 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
I have the following lines within the SSL VirtualDirectory tags in my 
httpd.conf file:

Alias /test/ /home/test/
<Directory /home/test/>
        Options all
        SSLVerifyClient require
        SSLVerifyDepth 9
        Allow from all
        SSLOptions      +StrictRequire +StdEnvVars +ExportCertData

The important line here is SSLVerifyClient require.
This should verify a client's personal certificate, and only allow him 
access to this directory if the certificate is valid.

However, when I point my browser to https://my.site/test/ I am asked which 
personal certificate I wish to use, and then receive a 'Server not found' 
error. The following lines appear in my apache error_log:

[Thu May 31 08:58:52 2001] [error] mod_ssl: Re-negotiation handshake
failed: Not accepted by client!?
[Thu May 31 08:58:52 2001] [error] mod_ssl: SSL error on writing data
(OpenSSL library error follows)
[Thu May 31 08:58:52 2001] [error] OpenSSL: error:1409E0E5:SSL
routines:SSL3_WRITE_BYTES:ssl handshake failure
[Thu May 31 08:58:54 2001] [error] mod_ssl: Certificate Verification:
Error (7): certificate signature failure
[Thu May 31 08:58:54 2001] [error] mod_ssl: Re-negotiation handshake
failed: Not accepted by client!?
[Thu May 31 08:58:54 2001] [error] mod_ssl: SSL error on writing data
(OpenSSL library error follows)
[Thu May 31 08:58:54 2001] [error] OpenSSL: error:1408F071:SSL
routines:SSL3_GET_RECORD:bad mac decode [Hint: Browser still re
membered details of a re-created server certificate?]

How reproducible:

Steps to Reproduce:
1. Install the webserver package
2. Install the mod_ssl package
3. Add the above lines to httpd.conf
4. Start webserver

Actual Results:  SSL handshake fails
Page cannot be displayed

Expected Results:  Page should be displayed

Additional info:

The problem goes away if you download the most recent version of apache, 
openssl, mod_ssl etc and do a static compile of the modules. I haven't 
tested recompiling and loading the modules as DSOs, because I want them to 
be static anyway. The document below explains the process:


This document outlines the procedure for compiling, making and installing 
apache with php, modssl and modperl statically
built in to apache (as opposed to the DSO method). This results in better 
performance, and also overcomes the problem that
users of the RedHat apache binary may experience when trying to 
implement 'SSLVerifyClient require' in httpd.conf.

These instructions assume that you currently have the standard RedHat 
binary of apache installed on your machine. If this is
the case, your httpd.conf file is likely to be found 
in /etc/httpd/conf/httpd.conf. If you follow these instructions, your
webserver should only experience a couple of seconds of downtime while you 
change over from the 'old' apache to the 'new'.

First of all, download the latest source tarballs of apache, openssl, 
modssl, php and modperl and save them in
/usr/local/src. At the time of writing these were the latest versions 

mod_ssl-2.8.4-1.3.20.tar.gz (make sure you have the correct version for 
your version of apache)

1. Unpack all of the tarballs:

  tar -xzvf apache_1.3.20.tar.gz

2. Install OpenSSL 
(if you already have a binary rpm-based version of openssl running, the 
two will run side-by-side)

  cd openssl-0.9.6a
  ./config no-threads           # no-threads because apache doesn't use 
  make test
  make install
  cd ..

3. Install mod_perl's Perl src and prepare the Apache src - skip this if 
you don't want mod_perl installed

  cd mod_perl-1.25
  perl Makefile.PL \
      APACHE_SRC=../apache_1.3.20/src \
      NO_HTTPD=1 \
      USE_APACI=1 \
      PREP_HTTPD=1 \
  make install
  cd ..

4. Prepare the Apache src for mod_ssl

  cd mod_ssl-2.8.4-1.3.20
  ./configure --with-apache=../apache_1.3.20
  cd ..

5. Install php's src and prepare the Apache src (execute the php function 
phpinfo() to see the configutation options of your
current version of php) - skip this if you don't want php installed

  cd php-4.0.6
  ./configure --with-apache=../apache_1.3.20  [--with any other 
configuration options you require]
  make install
  cd ..

6. Install the apache src with the required modules built in

  cd apache_1.3.20
  SSL_BASE=../openssl-0.9.6a \
  ./configure \
  --enable-module=ssl \
  --prefix=/usr/local/apache \
  --enable-module=so \
  --enable-rule=SHARED_CORE \
  --activate-module=src/modules/php4/libphp4.a \        #only include this 
line if you want to install php
  --activate-module=src/modules/perl/libperl.a          #only include this 
line if you want to install mod_perl  
  make install

7. If your server certificates are currently in /etc/httpd/conf/ssl.*** 
directories, copy them to the corresponding
directories in /usr/local/apache/conf/ssl.***

8. Make a copy of your existing httpd.conf file and move it 
to /usr/local/apache/conf, making sure that you don't overwrite
the new one that's already there:

cp /etc/httpd/conf/httpd.conf /usr/local/apache/conf/httpd.conf.old_redhat

9. Edit /usr/local/apache/conf/httpd.conf with your required settings. You 
will see that the main difference between the new
httpd.conf file and your old one is the DSO section. In the new one there 
should be NO LoadModule directives.
  Lines you are likely to have to copy from your old httpd.conf file: 
(line numbers refer to the new file)
    If you are running VirtualHosts you may need to add a BindAddress 
(line 187)
    ServerAdmin (line 269)
    ServerName (line 287)
    DocumentRoot (line 294)
    <Directory> (line 319)
    Your Icons and ScriptAlias Aliases - if you use them - (lines 553 - 
    Uncomment the relevant AddType and AddHandler lines for php and / or 
cgi (lines 776 & 791)
    Add any VirtualHost directives (lines 956 - 989)
    Change the SSL VirtualHost Settings:
      ServerAdmin  (lines 1066 - 1068)
    Add the path to your SSLCertificateFile (line 1089)
    Add the path to your SSLCertificateKeyFile (line 1097)
    Uncomment the SSLCACertificateFile line and add the path to your ca-
bundle.crt file (line 1117)
    Add the DRumKit Alias and <Directory> settings just before the 
</VirtualHost> tag (line 1224)
      (See the DRumKit documentation for exactly what to put here)
      Please note, if you are going to create an Alias, point it to a 
directory outside your DocumentRoot.

10. Stop your old server running, and start the new one:

  killall -9 httpd
  /usr/local/apache/bin/apachectl startssl

11. Test your new server. If you need to revert to your old server, do the 

  /usr/local/apache/bin/apachectl stop
  httpd -DHAVE_SSL

12. When you are confident that your new server is configured and running 
properly, you can uninstall the RedHat apache
  rpm -e mod_ssl
  rpm -e apache

  If you feel like doing rpm -e mod_perl, afterwards you will have to go 
back to /usr/local/src/mod_perl-1.25/ and run make
install again to copy the .pm perl packages back to where they should be.
Comment 1 Joe Orton 2004-09-21 06:46:40 EDT
Thanks for the report.  This is a mass bug update; since this release
of Red Hat Linux is no longer supported, please either:

a) try and reproduce the bug with a supported version of Red Hat
Enterprise Linux or Fedora Core, and re-open this bug as appropriate
after changing the Product field, or,

b) if relevant, try and reproduce this bug using the current version
of the upstream package, and report the bug upstream.

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