docs/manual/ssl/ssl_howto.xml - httpd - Git at Google

 <?xml version='1.0' encoding='UTF-8' ?>
 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
 <!-- $LastChangedRevision$ -->

 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
 -->

 <manualpage metafile="ssl_howto.xml.meta">
 <parentdocument href="./">SSL/TLS</parentdocument>

   <title>SSL/TLS Strong Encryption: How-To</title>

 <summary>
 <blockquote>
 <p>The solution to this problem is trivial
 and is left as an exercise for the reader.</p>

 <p class="cite">-- <cite>Standard textbook cookie</cite></p>
 </blockquote>

 <p>How to solve particular security problems for an SSL-aware
 webserver is not always obvious because of the interactions between SSL,
 HTTP and Apache's way of processing requests. This chapter gives
 instructions on how to solve some typical situations. Treat it as a first
 step to find out the final solution, but always try to understand the
 stuff before you use it. Nothing is worse than using a security solution
 without knowing its restrictions and how it interacts with other systems.</p>
 </summary>

 <section id="ciphersuites">
 <title>Cipher Suites and Enforcing Strong Security</title>
 <ul>
 <li><a href="#realssl">How can I create a real SSLv2-only server?</a></li>
 <li><a href="#onlystrong">How can I create an SSL server which accepts strong encryption only?</a></li>
 <li><a href="#upgradeenc">How can I create an SSL server which accepts strong encryption only, but allows
 export browsers to upgrade to stronger encryption?</a></li>
 <li><a href="#strongurl">How can I create an SSL server which accepts all types of ciphers in general, but
 requires a strong cipher for access to a particular URL?</a></li>
 </ul>

 <section id="realssl">
 <title>How can I create a real SSLv2-only server?</title>
     <p>The following creates an SSL server which speaks only the SSLv2 protocol and
     its ciphers.</p>

     <example><title>httpd.conf</title>
       SSLProtocol -all +SSLv2<br />
       SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP<br />
     </example>
 </section>

 <section id="onlystrong">
 <title>How can I create an SSL server which accepts strong encryption
 only?</title>
     <p>The following enables only the seven strongest ciphers:</p>
     <example><title>httpd.conf</title>
       SSLProtocol all<br />
       SSLCipherSuite HIGH:MEDIUM<br />
     </example>
 </section>

 <section id="upgradeenc">
 <title>How can I create an SSL server which accepts strong encryption
 only, but allows export browsers to upgrade to stronger encryption?</title>
     <p>This facility is called Server Gated Cryptography (SGC) and requires
     a Global ID server certificate, signed by a special CA certificate
     from Verisign. This enables strong encryption in 'export' versions of
     browsers, which traditionally could not support it (because of US export
     restrictions).</p>
     <p>When a browser connects with an export cipher, the server sends its Global
     ID certificate. The browser verifies this, and can then upgrade its
     cipher suite before any HTTP communication takes place. The problem
     lies in allowing browsers to upgrade in this fashion, but still requiring
     strong encryption. In other words, we want browsers to either start a
     connection with strong encryption, or to start with export ciphers but
     upgrade to strong encryption before beginning HTTP communication.</p>
     <p>This can be done as follows:</p>
     <example><title>httpd.conf</title>
       # allow all ciphers for the initial handshake,<br />
       # so export browsers can upgrade via SGC facility<br />
       SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
       <br />
       &lt;Directory /usr/local/apache2/htdocs&gt;<br />
       # but finally deny all browsers which haven't upgraded<br />
       SSLRequire %{SSL_CIPHER_USEKEYSIZE} &gt;= 128<br />
       &lt;/Directory&gt;
     </example>
 </section>

 <section id="strongurl">
 <title>How can I create an SSL server which accepts all types of ciphers
 in general, but requires a strong ciphers for access to a particular
 URL?</title>
     <p>Obviously, a server-wide <directive
     module="mod_ssl">SSLCipherSuite</directive> which restricts
     ciphers to the strong variants, isn't the answer here. However,
     <module>mod_ssl</module> can be reconfigured within <code>Location</code>
     blocks, to give a per-directory solution, and can automatically force
     a renegotiation of the SSL parameters to meet the new configuration.
     This can be done as follows:</p>
     <example>
       # be liberal in general<br />
       SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
       <br />
       &lt;Location /strong/area&gt;<br />
       # but https://hostname/strong/area/ and below<br />
       # requires strong ciphers<br />
       SSLCipherSuite HIGH:MEDIUM<br />
       &lt;/Location&gt;
     </example>
 </section>
 </section>
 <!-- /ciphersuites -->

 <section id="accesscontrol">
 <title>Client Authentication and Access Control</title>
 <ul>
 <li><a href="#allclients">How can I force clients to authenticate using certificates?</a></li>
 <li><a href="#arbitraryclients">How can I force clients to authenticate using certificates for a
         particular URL, but still allow arbitrary clients to access the rest of the server?</a></li>
 <li><a href="#certauthenticate">How can I allow only clients who have certificates to access a
         particular URL, but allow all clients to access the rest of the server?</a></li>
 <li><a href="#intranet">How can I require HTTPS with strong ciphers, and either
 basic authentication or client certificates, for access to part of the
 Intranet website, for clients coming from the Internet?</a></li>
 </ul>

 <section id="allclients">
 <title>How can I force clients to authenticate using certificates?</title>

     <p>When you know all of your users (eg, as is often the case on a corporate
     Intranet), you can require plain certificate authentication. All you
     need to do is to create client certificates signed by your own CA
     certificate (<code>ca.crt</code>) and then verify the clients against this
     certificate.</p>
     <example><title>httpd.conf</title>
       # require a client certificate which has to be directly<br />
       # signed by our CA certificate in ca.crt<br />
       SSLVerifyClient require<br />
       SSLVerifyDepth 1<br />
       SSLCACertificateFile conf/ssl.crt/ca.crt
     </example>
 </section>

 <section id="arbitraryclients">
 <title>How can I force clients to authenticate using certificates for a
   particular URL, but still allow arbitrary clients to access the rest of the server?</title>

     <p>To force clients to authenticate using certificates for a particular URL,
     you can use the per-directory reconfiguration features of
     <module>mod_ssl</module>:</p>

     <example><title>httpd.conf</title>
     SSLVerifyClient none<br />
     SSLCACertificateFile conf/ssl.crt/ca.crt<br />
     <br />
     &lt;Location /secure/area&gt;<br />
     SSLVerifyClient require<br />
     SSLVerifyDepth 1<br />
     &lt;/Location&gt;<br />
     </example>
 </section>

 <section id="certauthenticate">
 <title>How can I allow only clients who have certificates to access a
   particular URL, but allow all clients to access the rest of the server?</title>

     <p>The key to doing this is checking that part of the client certificate
     matches what you expect. Usually this means checking all or part of the
     Distinguished Name (DN), to see if it contains some known string.
     There are two ways to do this, using either <module>mod_auth_basic</module> or
     <directive module="mod_ssl">SSLRequire</directive>.</p>

     <p>The <module>mod_auth_basic</module> method is generally required when
     the certificates are completely arbitrary, or when their DNs have
     no common fields (usually the organisation, etc.). In this case,
     you should establish a password database containing <em>all</em>
     clients allowed, as follows:</p>

     <example><title>httpd.conf</title><pre>
 SSLVerifyClient      none
 &lt;Directory /usr/local/apache2/htdocs/secure/area&gt;

 SSLVerifyClient      require
 SSLVerifyDepth       5
 SSLCACertificateFile conf/ssl.crt/ca.crt
 SSLCACertificatePath conf/ssl.crt
 SSLOptions           +FakeBasicAuth
 SSLRequireSSL
 AuthName             "Snake Oil Authentication"
 AuthType             Basic
 AuthBasicProvider    file
 AuthUserFile         /usr/local/apache2/conf/httpd.passwd
 Require              valid-user
 &lt;/Directory&gt;</pre>
     </example>

     <p>The password used in this example is the DES encrypted string "password".
     See the <directive module="mod_ssl">SSLOptions</directive> docs for more
     information.</p>

     <example><title>httpd.passwd</title><pre>
 /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
 /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
 /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA</pre>
     </example>

     <p>When your clients are all part of a common hierarchy, which is encoded
     into the DN, you can match them more easily using <directive module="mod_ssl"
     >SSLRequire</directive>, as follows:</p>


     <example><title>httpd.conf</title><pre>
 SSLVerifyClient      none
 &lt;Directory /usr/local/apache2/htdocs/secure/area&gt;

   SSLVerifyClient      require
   SSLVerifyDepth       5
   SSLCACertificateFile conf/ssl.crt/ca.crt
   SSLCACertificatePath conf/ssl.crt
   SSLOptions           +FakeBasicAuth
   SSLRequireSSL
   SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
                and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
 &lt;/Directory&gt;</pre>
     </example>
 </section>

 <section id="intranet">
 <title>How can I require HTTPS with strong ciphers, and either basic
 authentication or client certificates, for access to part of the
 Intranet website, for clients coming from the Internet? I still want to allow
 plain HTTP access for clients on the Intranet.</title>

    <p>These examples presume that clients on the Intranet have IPs in the range
    192.168.1.0/24, and that the part of the Intranet website you want to allow
    internet access to is <code>/usr/local/apache2/htdocs/subarea</code>.
    This configuration should remain outside of your HTTPS virtual host, so
    that it applies to both HTTPS and HTTP.</p>

     <example><title>httpd.conf</title><pre>
 SSLCACertificateFile conf/ssl.crt/company-ca.crt

 &lt;Directory /usr/local/apache2/htdocs&gt;
 #   Outside the subarea only Intranet access is granted
 Order                deny,allow
 Deny                 from all
 Allow                from 192.168.1.0/24
 &lt;/Directory&gt;

 &lt;Directory /usr/local/apache2/htdocs/subarea&gt;
 #   Inside the subarea any Intranet access is allowed
 #   but from the Internet only HTTPS + Strong-Cipher + Password
 #   or the alternative HTTPS + Strong-Cipher + Client-Certificate

 #   If HTTPS is used, make sure a strong cipher is used.
 #   Additionally allow client certs as alternative to basic auth.
 SSLVerifyClient      optional
 SSLVerifyDepth       1
 SSLOptions           +FakeBasicAuth +StrictRequire
 SSLRequire           %{SSL_CIPHER_USEKEYSIZE} &gt;= 128

 #   Force clients from the Internet to use HTTPS
 RewriteEngine        on
 RewriteCond          %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
 RewriteCond          %{HTTPS} !=on
 RewriteRule          .* - [F]

 #   Allow Network Access and/or Basic Auth
 Satisfy              any

 #   Network Access Control
 Order                deny,allow
 Deny                 from all
 Allow                192.168.1.0/24

 #   HTTP Basic Authentication
 AuthType             basic
 AuthName             "Protected Intranet Area"
 AuthBasicProvider    file
 AuthUserFile         conf/protected.passwd
 Require              valid-user
 &lt;/Directory&gt;</pre>
     </example>
 </section>
 </section>
 <!-- /access control -->

 </manualpage>
	<?xml version='1.0' encoding='UTF-8' ?>
	<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
	<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
	<!-- $LastChangedRevision$ -->

	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->

	<manualpage metafile="ssl_howto.xml.meta">
	<parentdocument href="./">SSL/TLS</parentdocument>

	<title>SSL/TLS Strong Encryption: How-To</title>

	<summary>
	<blockquote>
	<p>The solution to this problem is trivial
	and is left as an exercise for the reader.</p>

	<p class="cite">-- <cite>Standard textbook cookie</cite></p>
	</blockquote>

	<p>How to solve particular security problems for an SSL-aware
	webserver is not always obvious because of the interactions between SSL,
	HTTP and Apache's way of processing requests. This chapter gives
	instructions on how to solve some typical situations. Treat it as a first
	step to find out the final solution, but always try to understand the
	stuff before you use it. Nothing is worse than using a security solution
	without knowing its restrictions and how it interacts with other systems.</p>
	</summary>

	<section id="ciphersuites">
	<title>Cipher Suites and Enforcing Strong Security</title>
	<ul>
	<li><a href="#realssl">How can I create a real SSLv2-only server?</a></li>
	<li><a href="#onlystrong">How can I create an SSL server which accepts strong encryption only?</a></li>
	<li><a href="#upgradeenc">How can I create an SSL server which accepts strong encryption only, but allows
	export browsers to upgrade to stronger encryption?</a></li>
	<li><a href="#strongurl">How can I create an SSL server which accepts all types of ciphers in general, but
	requires a strong cipher for access to a particular URL?</a></li>
	</ul>

	<section id="realssl">
	<title>How can I create a real SSLv2-only server?</title>
	<p>The following creates an SSL server which speaks only the SSLv2 protocol and
	its ciphers.</p>

	<example><title>httpd.conf</title>
	SSLProtocol -all +SSLv2<br />
	SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP<br />
	</example>
	</section>

	<section id="onlystrong">
	<title>How can I create an SSL server which accepts strong encryption
	only?</title>
	<p>The following enables only the seven strongest ciphers:</p>
	<example><title>httpd.conf</title>
	SSLProtocol all<br />
	SSLCipherSuite HIGH:MEDIUM<br />
	</example>
	</section>

	<section id="upgradeenc">
	<title>How can I create an SSL server which accepts strong encryption
	only, but allows export browsers to upgrade to stronger encryption?</title>
	<p>This facility is called Server Gated Cryptography (SGC) and requires
	a Global ID server certificate, signed by a special CA certificate
	from Verisign. This enables strong encryption in 'export' versions of
	browsers, which traditionally could not support it (because of US export
	restrictions).</p>
	<p>When a browser connects with an export cipher, the server sends its Global
	ID certificate. The browser verifies this, and can then upgrade its
	cipher suite before any HTTP communication takes place. The problem
	lies in allowing browsers to upgrade in this fashion, but still requiring
	strong encryption. In other words, we want browsers to either start a
	connection with strong encryption, or to start with export ciphers but
	upgrade to strong encryption before beginning HTTP communication.</p>
	<p>This can be done as follows:</p>
	<example><title>httpd.conf</title>
	# allow all ciphers for the initial handshake,<br />
	# so export browsers can upgrade via SGC facility<br />
	SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
	<br />
	<Directory /usr/local/apache2/htdocs><br />
	# but finally deny all browsers which haven't upgraded<br />
	SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128<br />
	</Directory>
	</example>
	</section>

	<section id="strongurl">
	<title>How can I create an SSL server which accepts all types of ciphers
	in general, but requires a strong ciphers for access to a particular
	URL?</title>
	<p>Obviously, a server-wide <directive
	module="mod_ssl">SSLCipherSuite</directive> which restricts
	ciphers to the strong variants, isn't the answer here. However,
	<module>mod_ssl</module> can be reconfigured within <code>Location</code>
	blocks, to give a per-directory solution, and can automatically force
	a renegotiation of the SSL parameters to meet the new configuration.
	This can be done as follows:</p>
	<example>
	# be liberal in general<br />
	SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
	<br />
	<Location /strong/area><br />
	# but https://hostname/strong/area/ and below<br />
	# requires strong ciphers<br />
	SSLCipherSuite HIGH:MEDIUM<br />
	</Location>
	</example>
	</section>
	</section>
	<!-- /ciphersuites -->

	<section id="accesscontrol">
	<title>Client Authentication and Access Control</title>
	<ul>
	<li><a href="#allclients">How can I force clients to authenticate using certificates?</a></li>
	<li><a href="#arbitraryclients">How can I force clients to authenticate using certificates for a
	particular URL, but still allow arbitrary clients to access the rest of the server?</a></li>
	<li><a href="#certauthenticate">How can I allow only clients who have certificates to access a
	particular URL, but allow all clients to access the rest of the server?</a></li>
	<li><a href="#intranet">How can I require HTTPS with strong ciphers, and either
	basic authentication or client certificates, for access to part of the
	Intranet website, for clients coming from the Internet?</a></li>
	</ul>

	<section id="allclients">
	<title>How can I force clients to authenticate using certificates?</title>

	<p>When you know all of your users (eg, as is often the case on a corporate
	Intranet), you can require plain certificate authentication. All you
	need to do is to create client certificates signed by your own CA
	certificate (<code>ca.crt</code>) and then verify the clients against this
	certificate.</p>
	<example><title>httpd.conf</title>
	# require a client certificate which has to be directly<br />
	# signed by our CA certificate in ca.crt<br />
	SSLVerifyClient require<br />
	SSLVerifyDepth 1<br />
	SSLCACertificateFile conf/ssl.crt/ca.crt
	</example>
	</section>

	<section id="arbitraryclients">
	<title>How can I force clients to authenticate using certificates for a
	particular URL, but still allow arbitrary clients to access the rest of the server?</title>

	<p>To force clients to authenticate using certificates for a particular URL,
	you can use the per-directory reconfiguration features of
	<module>mod_ssl</module>:</p>

	<example><title>httpd.conf</title>
	SSLVerifyClient none<br />
	SSLCACertificateFile conf/ssl.crt/ca.crt<br />
	<br />
	<Location /secure/area><br />
	SSLVerifyClient require<br />
	SSLVerifyDepth 1<br />
	</Location><br />
	</example>
	</section>

	<section id="certauthenticate">
	<title>How can I allow only clients who have certificates to access a
	particular URL, but allow all clients to access the rest of the server?</title>

	<p>The key to doing this is checking that part of the client certificate
	matches what you expect. Usually this means checking all or part of the
	Distinguished Name (DN), to see if it contains some known string.
	There are two ways to do this, using either <module>mod_auth_basic</module> or
	<directive module="mod_ssl">SSLRequire</directive>.</p>

	<p>The <module>mod_auth_basic</module> method is generally required when
	the certificates are completely arbitrary, or when their DNs have
	no common fields (usually the organisation, etc.). In this case,
	you should establish a password database containing <em>all</em>
	clients allowed, as follows:</p>

	<example><title>httpd.conf</title><pre>
	SSLVerifyClient none
	<Directory /usr/local/apache2/htdocs/secure/area>

	SSLVerifyClient require
	SSLVerifyDepth 5
	SSLCACertificateFile conf/ssl.crt/ca.crt
	SSLCACertificatePath conf/ssl.crt
	SSLOptions +FakeBasicAuth
	SSLRequireSSL
	AuthName "Snake Oil Authentication"
	AuthType Basic
	AuthBasicProvider file
	AuthUserFile /usr/local/apache2/conf/httpd.passwd
	Require valid-user
	</Directory></pre>
	</example>

	<p>The password used in this example is the DES encrypted string "password".
	See the <directive module="mod_ssl">SSLOptions</directive> docs for more
	information.</p>

	<example><title>httpd.passwd</title><pre>
	/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
	/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
	/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA</pre>
	</example>

	<p>When your clients are all part of a common hierarchy, which is encoded
	into the DN, you can match them more easily using <directive module="mod_ssl"
	>SSLRequire</directive>, as follows:</p>


	<example><title>httpd.conf</title><pre>
	SSLVerifyClient none
	<Directory /usr/local/apache2/htdocs/secure/area>

	SSLVerifyClient require
	SSLVerifyDepth 5
	SSLCACertificateFile conf/ssl.crt/ca.crt
	SSLCACertificatePath conf/ssl.crt
	SSLOptions +FakeBasicAuth
	SSLRequireSSL
	SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
	and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
	</Directory></pre>
	</example>
	</section>

	<section id="intranet">
	<title>How can I require HTTPS with strong ciphers, and either basic
	authentication or client certificates, for access to part of the
	Intranet website, for clients coming from the Internet? I still want to allow
	plain HTTP access for clients on the Intranet.</title>

	<p>These examples presume that clients on the Intranet have IPs in the range
	192.168.1.0/24, and that the part of the Intranet website you want to allow
	internet access to is <code>/usr/local/apache2/htdocs/subarea</code>.
	This configuration should remain outside of your HTTPS virtual host, so
	that it applies to both HTTPS and HTTP.</p>

	<example><title>httpd.conf</title><pre>
	SSLCACertificateFile conf/ssl.crt/company-ca.crt

	<Directory /usr/local/apache2/htdocs>
	# Outside the subarea only Intranet access is granted
	Order deny,allow
	Deny from all
	Allow from 192.168.1.0/24
	</Directory>

	<Directory /usr/local/apache2/htdocs/subarea>
	# Inside the subarea any Intranet access is allowed
	# but from the Internet only HTTPS + Strong-Cipher + Password
	# or the alternative HTTPS + Strong-Cipher + Client-Certificate

	# If HTTPS is used, make sure a strong cipher is used.
	# Additionally allow client certs as alternative to basic auth.
	SSLVerifyClient optional
	SSLVerifyDepth 1
	SSLOptions +FakeBasicAuth +StrictRequire
	SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128

	# Force clients from the Internet to use HTTPS
	RewriteEngine on
	RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
	RewriteCond %{HTTPS} !=on
	RewriteRule .* - [F]

	# Allow Network Access and/or Basic Auth
	Satisfy any

	# Network Access Control
	Order deny,allow
	Deny from all
	Allow 192.168.1.0/24

	# HTTP Basic Authentication
	AuthType basic
	AuthName "Protected Intranet Area"
	AuthBasicProvider file
	AuthUserFile conf/protected.passwd
	Require valid-user
	</Directory></pre>
	</example>
	</section>
	</section>
	<!-- /access control -->

	</manualpage>