I was digging in apache 2.2 to see if SS ... / 2011-08-05

I was digging in apache 2.2 to see if SSLRequireSSL would enable me to make sure locations within the webserver that require passwords would always use SSL without having to duplicate the entire vhost config. And I found a working setup which allows me to give those locations once. On the port 80 server is the specific config:

<VirtualHost *>
        ServerName octagone.idefix.net
        ErrorLog /home/httpd/octagone/logs/error_log
CustomLog /home/httpd/octagone/logs/access_log combined

        AddHandler cgi-script .cgi
        ErrorDocument 403 /youwanthttps.cgi

        Include special/octagone
</VirtualHost>

And on the port 443 server:

<VirtualHost *:443>
        ServerName octagone.idefix.net
        SSLEngine On
        SSLCertificateFile /etc/apache2/ssl/server.crt
        SSLCertificateKeyFile /etc/apache2/ssl/server.key
        ErrorLog /home/httpd/octagone/logs/ssl_error.log
        TransferLog /home/httpd/octagone/logs/ssl_access_log

        Include special/octagone
</VirtualHost>

The shared bit:

        DocumentRoot /home/httpd/octagone/html

        <Directory /home/httpd/octagone/html>
                Options Indexes ExecCGI
                AllowOverride None
                Order allow,deny
                allow from all
                IndexOptions FancyIndexing
        </Directory>

        <Location /test>
                AuthName "Koos z'n Doos beheer"
                AuthType basic
                AuthUserFile /home/httpd/data/sitemanagers
                AuthGroupFile /dev/null
                Require valid-user
                Satisfy All
                SSLRequireSSL
        </Location>

Now an access to http://octagone.idefix.net/test/ will throw a 403 error. I created a simple youwanthttps.cgi which changes this to a temporary redirect to the https equivalent:

#!/usr/bin/perl -wT

use strict;

use CGI qw/:standard/;

my $query = new CGI;

my $redir='https://octagone.idefix.net'.$ENV{"REQUEST_URI"};

print $query->header( -type => 'text/html', -status=> 302, charset=> 'UTF-8', -location=> $redir );

print <<EOF

Go <a href="$redir">here</a>.

EOF
;

The downsides are:

• Other reasons for a 403 error will also see the redirect. But they will get the 'original' 403 error on the https side again.
• This does not mix with Satisfy Any which you use for example because you want a restricted IP or a username/password because then SSL will just be one of the constraints to satisfy.

The other option is to change the 401 (authentication required) handler to do the redirect. I'm also testing that. That would combine better with the Satisfy Any directive which is used in some places in the webserver where I want to implement this.

Ok, this works too. One slight downside to this approach: when the client still has the username/password cached, it will present those and the server will never use its 401 handler. But those sessions will die out soon anyway.

In the end I configured the server with the '401 handler' trick. One upside: I did not need to sprinkle SSLRequireSSL statements, so even the restricted content with address check or username/password check continue to work.