Excluding a particular directory from SSL requirements does not work as expected

Discussion in 'Server Operation' started by cbj4074, Dec 14, 2011.

  1. cbj4074

    cbj4074 Member HowtoForge Supporter

    I have configured Apache to require an SSL connection for the entire document root, but I would like to exclude certain subdirectories from the SSL requirement.

    This seems like it would be a common requirement, but I can't find any straightforward documentation on the matter.

    Per the relevant Apache documentation ( http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#ssloptions ), this should be possible:

    Based on the above quote, it seems that one should be able to use a Satisfy any directive for the directory that is to be excluded from the SSL requirement.

    If we examine the relevant Satisfy documentation ( http://httpd.apache.org/docs/2.0/mod/core.html#satisfy ), we find the following:

    So, in theory, the following should exclude the directory in question from the SSL requirement:

    File: /etc/apache2/httpd.conf:

    Code:
    <Directory /var/www/example.com>
    Order allow,deny
    Allow from all
    
    # Deny access when SSL is not used for the HTTP request.
    SSLRequireSSL
    
    # Force access via a given host when SSL is used (does not force SSL!); processed after handshake, so certificate mismatches are not avoided.
    SSLRequire %{HTTP_HOST} eq "example.com"
    </Directory>
    
    Apache Directives box for this vhost in ISPConfig interface:

    Code:
    <Location /mysite>
    #Allow from all should be inherited from /etc/apache2/httpd.conf
    Satisfy any
    </Location>
    
    Yet I still receive:

    Code:
    [error] [client XXX.XXX.XXX.XXX] access to /var/www/example.com/web/mysite/ failed, reason: SSL connection required
    
    Could the problem be that I'm not using a Require directive anywhere? After all, the above-referenced documentation does state:

    I don't want to add authentication requirements to the directory in question, as this resource must remain public.
     
    Last edited: Dec 14, 2011

Share This Page