mod_ssl.html.en

<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Option to prefer the server's cipher preference order</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLHonorCipherOrder on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLHonorCipherOrder off</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>When choosing a cipher during an SSLv3 or TLSv1 handshake, normally
the client's preference is used.  If this directive is enabled, the
server's preference will be used instead.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLHonorCipherOrder on</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLInsecureRenegotiation" id="SSLInsecureRenegotiation">SSLInsecureRenegotiation</a> <a name="sslinsecurerenegotiation" id="sslinsecurerenegotiation">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Option to enable support for insecure renegotiation</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLInsecureRenegotiation on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLInsecureRenegotiation off</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Available in httpd 2.2.15 and later, if using OpenSSL 0.9.8m or later</td></tr>
</table>
<p>As originally specified, all versions of the SSL and TLS protocols
(up to and including TLS/1.2) were vulnerable to a Man-in-the-Middle
attack
(<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2009-3555">CVE-2009-3555</a>)
during a renegotiation.  This vulnerability allowed an attacker to
"prefix" a chosen plaintext to the HTTP request as seen by the web
server.  A protocol extension was developed which fixed this
vulnerability if supported by both client and server.</p>

<p>If <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> is linked against OpenSSL version 0.9.8m
or later, by default renegotiation is only supported with
clients supporting the new protocol extension.  If this directive is
enabled, renegotiation will be allowed with old (unpatched) clients,
albeit insecurely.</p>

<div class="warning"><h3>Security warning</h3>
<p>If this directive is enabled, SSL connections will be vulnerable to
the Man-in-the-Middle prefix attack as described
in <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2009-3555">CVE-2009-3555</a>.</p>
</div>

<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLInsecureRenegotiation on</pre>
</div>

<p>The <code>SSL_SECURE_RENEG</code> environment variable can be used
from an SSI or CGI script to determine whether secure renegotiation is
supported for a given SSL connection.</p>


</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPDefaultResponder" id="SSLOCSPDefaultResponder">SSLOCSPDefaultResponder</a> <a name="sslocspdefaultresponder" id="sslocspdefaultresponder">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Set the default responder URI for OCSP validation</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSDefaultResponder <em>uri</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>This option sets the default OCSP responder to use.  If <code class="directive"><a href="#sslocspoverrideresponder">SSLOCSPOverrideResponder</a></code> is not enabled,
the URI given will be used only if no responder URI is specified in
the certificate being verified.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPEnable" id="SSLOCSPEnable">SSLOCSPEnable</a> <a name="sslocspenable" id="sslocspenable">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Enable OCSP validation of the client certificate chain</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPEnable on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLOCSPEnable off</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>This option enables OCSP validation of the client certificate
chain.  If this option is enabled, certificates in the client's
certificate chain will be validated against an OCSP responder after
normal verification (including CRL checks) have taken place.</p>

<p>The OCSP responder used is either extracted from the certificate
itself, or derived by configuration; see the
<code class="directive"><a href="#sslocspdefaultresponder">SSLOCSPDefaultResponder</a></code> and
<code class="directive"><a href="#sslocspoverrideresponder">SSLOCSPOverrideResponder</a></code>
directives.</p>

<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLVerifyClient on
SSLOCSPEnable on
SSLOCSPDefaultResponder "http://responder.example.com:8888/responder"
SSLOCSPOverrideResponder on</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPNoverify" id="SSLOCSPNoverify">SSLOCSPNoverify</a> <a name="sslocspnoverify" id="sslocspnoverify">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>skip the OCSP responder certificates verification</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPNoverify <em>On/Off</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLOCSPNoverify Off</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Available in httpd 2.4.26 and later, if using OpenSSL 0.9.7 or later</td></tr>
</table>
<p>Skip the OCSP responder certificates verification, mostly useful when
testing an OCSP server.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPOverrideResponder" id="SSLOCSPOverrideResponder">SSLOCSPOverrideResponder</a> <a name="sslocspoverrideresponder" id="sslocspoverrideresponder">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Force use of the default responder URI for OCSP validation</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPOverrideResponder on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLOCSPOverrideResponder off</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>This option forces the configured default OCSP responder to be used
during OCSP certificate validation, regardless of whether the
certificate being validated references an OCSP responder.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPProxyURL" id="SSLOCSPProxyURL">SSLOCSPProxyURL</a> <a name="sslocspproxyurl" id="sslocspproxyurl">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Proxy URL to use for OCSP requests</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPProxyURL <em>url</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Available in httpd 2.4.19 and later</td></tr>
</table>
<p>This option allows to set the URL of a HTTP proxy that should be used for
all queries to OCSP responders.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPResponderCertificateFile" id="SSLOCSPResponderCertificateFile">SSLOCSPResponderCertificateFile</a> <a name="sslocsprespondercertificatefile" id="sslocsprespondercertificatefile">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Set of trusted PEM encoded OCSP responder certificates</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPResponderCertificateFile <em>file</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Available in httpd 2.4.26 and later, if using OpenSSL 0.9.7 or later</td></tr>
</table>
<p>This supplies a list of trusted OCSP responder certificates to be used
during OCSP responder certificate validation. The supplied certificates are
implicitly trusted without any further validation. This is typically used
where the OCSP responder certificate is self signed or omitted from the OCSP
response.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPResponderTimeout" id="SSLOCSPResponderTimeout">SSLOCSPResponderTimeout</a> <a name="sslocsprespondertimeout" id="sslocsprespondertimeout">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Timeout for OCSP queries</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPResponderTimeout <em>seconds</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLOCSPResponderTimeout 10</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>This option sets the timeout for queries to OCSP responders, when
<code class="directive"><a href="#sslocspenable">SSLOCSPEnable</a></code> is turned on.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPResponseMaxAge" id="SSLOCSPResponseMaxAge">SSLOCSPResponseMaxAge</a> <a name="sslocspresponsemaxage" id="sslocspresponsemaxage">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Maximum allowable age for OCSP responses</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPResponseMaxAge <em>seconds</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLOCSPResponseMaxAge -1</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>This option sets the maximum allowable age ("freshness") for OCSP responses.
The default value (<code>-1</code>) does not enforce a maximum age,
which means that OCSP responses are considered valid as long as their
<code>nextUpdate</code> field is in the future.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPResponseTimeSkew" id="SSLOCSPResponseTimeSkew">SSLOCSPResponseTimeSkew</a> <a name="sslocspresponsetimeskew" id="sslocspresponsetimeskew">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Maximum allowable time skew for OCSP response validation</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPResponseTimeSkew <em>seconds</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLOCSPResponseTimeSkew 300</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>This option sets the maximum allowable time skew for OCSP responses
(when checking their <code>thisUpdate</code> and <code>nextUpdate</code> fields).</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOCSPUseRequestNonce" id="SSLOCSPUseRequestNonce">SSLOCSPUseRequestNonce</a> <a name="sslocspuserequestnonce" id="sslocspuserequestnonce">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Use a nonce within OCSP queries</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOCSPUseRequestNonce on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLOCSPUseRequestNonce on</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Available in httpd 2.4.10 and later</td></tr>
</table>
<p>This option determines whether queries to OCSP responders should contain
a nonce or not. By default, a query nonce is always used and checked against
the response's one. When the responder does not use nonces (e.g. Microsoft OCSP
Responder), this option should be turned <code>off</code>.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOpenSSLConfCmd" id="SSLOpenSSLConfCmd">SSLOpenSSLConfCmd</a> <a name="sslopensslconfcmd" id="sslopensslconfcmd">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Configure OpenSSL parameters through its <em>SSL_CONF</em> API</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOpenSSLConfCmd <em>command-name</em> <em>command-value</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Available in httpd 2.4.8 and later, if using OpenSSL 1.0.2 or later</td></tr>
</table>
<p>This directive exposes OpenSSL's <em>SSL_CONF</em> API to mod_ssl,
allowing a flexible configuration of OpenSSL parameters without the need
of implementing additional <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> directives when new
features are added to OpenSSL.</p>

<p>The set of available <code class="directive">SSLOpenSSLConfCmd</code> commands
depends on the OpenSSL version being used for <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code>
(at least version 1.0.2 is required). For a list of supported command
names, see the section <em>Supported configuration file commands</em> in the
<a href="http://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html#SUPPORTED-CONFIGURATION-FILE-COMMANDS">SSL_CONF_cmd(3)</a> manual page for OpenSSL.</p>

<p>Some of the <code class="directive">SSLOpenSSLConfCmd</code> commands can be used
as an alternative to existing directives (such as
<code class="directive"><a href="#sslciphersuite">SSLCipherSuite</a></code> or
<code class="directive"><a href="#sslprotocol">SSLProtocol</a></code>),
though it should be noted that the syntax / allowable values for the parameters
may sometimes differ.</p>

<div class="example"><h3>Examples</h3><pre class="prettyprint lang-config">SSLOpenSSLConfCmd Options -SessionTicket,ServerPreference
SSLOpenSSLConfCmd ECDHParameters brainpoolP256r1
SSLOpenSSLConfCmd ServerInfoFile "/usr/local/apache2/conf/server-info.pem"
SSLOpenSSLConfCmd Protocol "-ALL, TLSv1.2"
SSLOpenSSLConfCmd SignatureAlgorithms RSA+SHA384:ECDSA+SHA256</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLOptions" id="SSLOptions">SSLOptions</a> <a name="ssloptions" id="ssloptions">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Configure various SSL engine run-time options</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLOptions [+|-]<em>option</em> ...</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Options</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive can be used to control various run-time options on a
per-directory basis. Normally, if multiple <code>SSLOptions</code>
could apply to a directory, then the most specific one is taken
completely; the options are not merged. However if <em>all</em> the
options on the <code>SSLOptions</code> directive are preceded by a
plus (<code>+</code>) or minus (<code>-</code>) symbol, the options
are merged. Any options preceded by a <code>+</code> are added to the
options currently in force, and any options preceded by a
<code>-</code> are removed from the options currently in force.</p>
<p>
The available <em>option</em>s are:</p>
<ul>
<li><code>StdEnvVars</code>
    <p>
    When this option is enabled, the standard set of SSL related CGI/SSI
    environment variables are created. This per default is disabled for
    performance reasons, because the information extraction step is a
    rather expensive operation. So one usually enables this option for
    CGI and SSI requests only.</p>
</li>
<li><code>ExportCertData</code>
    <p>
    When this option is enabled, additional CGI/SSI environment variables are
    created: <code>SSL_SERVER_CERT</code>, <code>SSL_CLIENT_CERT</code> and
    <code>SSL_CLIENT_CERT_CHAIN_</code><em>n</em> (with <em>n</em> = 0,1,2,..).
    These contain the PEM-encoded X.509 Certificates of server and client for
    the current HTTPS connection and can be used by CGI scripts for deeper
    Certificate checking. Additionally all other certificates of the client
    certificate chain are provided, too. This bloats up the environment a
    little bit which is why you have to use this option to enable it on
    demand.</p>
</li>
<li><code>FakeBasicAuth</code>
    <p>
    When this option is enabled, the Subject Distinguished Name (DN) of the
    Client X509 Certificate is translated into a HTTP Basic Authorization
    username. This means that the standard Apache authentication methods can
    be used for access control. The user name is just the Subject of the
    Client's X509 Certificate (can be determined by running OpenSSL's
    <code>openssl x509</code> command: <code>openssl x509 -noout -subject -in
    </code><em>certificate</em><code>.crt</code>). Note that no password is
    obtained from the user. Every entry in the user file needs this password:
    ``<code>xxj31ZMTZzkVA</code>'', which is the DES-encrypted version of the
    word `<code>password</code>''. Those who live under MD5-based encryption
    (for instance under FreeBSD or BSD/OS, etc.) should use the following MD5
    hash of the same word: ``<code>$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/</code>''.</p>

    <p>Note that the <code class="directive"><a href="../mod/mod_auth_basic.html#authbasicfake">AuthBasicFake</a></code>
    directive within <code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code> can be used as a more
    general mechanism for faking basic authentication, giving control over the
    structure of both the username and password.</p>
</li>
<li><code>StrictRequire</code>
    <p>
    This <em>forces</em> forbidden access when <code>SSLRequireSSL</code> or
    <code>SSLRequire</code> successfully decided that access should be
    forbidden. Usually the default is that in the case where a ``<code>Satisfy
    any</code>'' directive is used, and other access restrictions are passed,
    denial of access due to <code>SSLRequireSSL</code> or
    <code>SSLRequire</code> is overridden (because that's how the Apache
    <code>Satisfy</code> mechanism should work.) But for strict access restriction
    you can use <code>SSLRequireSSL</code> and/or <code>SSLRequire</code> in
    combination with an ``<code>SSLOptions +StrictRequire</code>''. Then an
    additional ``<code>Satisfy Any</code>'' has no chance once mod_ssl has
    decided to deny access.</p>
</li>
<li><code>OptRenegotiate</code>
    <p>
    This enables optimized SSL connection renegotiation handling when SSL
    directives are used in per-directory context. By default a strict
    scheme is enabled where <em>every</em> per-directory reconfiguration of
    SSL parameters causes a <em>full</em> SSL renegotiation handshake. When this
    option is used mod_ssl tries to avoid unnecessary handshakes by doing more
    granular (but still safe) parameter checks. Nevertheless these granular
    checks sometimes may not be what the user expects, so enable this on a
    per-directory basis only, please.</p>
</li>
<li><code>LegacyDNStringFormat</code>
    <p>
    This option influences how values of the
    <code>SSL_{CLIENT,SERVER}_{I,S}_DN</code> variables are formatted. Since
    version 2.3.11, Apache HTTPD uses a RFC 2253 compatible format by
    default. This uses commas as delimiters between the attributes, allows the
    use of non-ASCII characters (which are converted to UTF8), escapes
    various special characters with backslashes, and sorts the attributes
    with the "C" attribute last.</p>

    <p>If <code>LegacyDNStringFormat</code> is set, the old format will be
    used which sorts the "C" attribute first, uses slashes as separators, and
    does not handle non-ASCII and special characters in any consistent way.
    </p>
</li>
</ul>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLOptions +FakeBasicAuth -StrictRequire
&lt;Files ~ "\.(cgi|shtml)$"&gt;
    SSLOptions +StdEnvVars -ExportCertData
&lt;/Files&gt;</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLPassPhraseDialog" id="SSLPassPhraseDialog">SSLPassPhraseDialog</a> <a name="sslpassphrasedialog" id="sslpassphrasedialog">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Type of pass phrase dialog for encrypted private
keys</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLPassPhraseDialog <em>type</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLPassPhraseDialog builtin</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
When Apache starts up it has to read the various Certificate (see
<code class="directive"><a href="#sslcertificatefile">SSLCertificateFile</a></code>) and
Private Key (see <code class="directive"><a href="#sslcertificatekeyfile">SSLCertificateKeyFile</a></code>) files of the
SSL-enabled virtual servers. Because for security reasons the Private
Key files are usually encrypted, mod_ssl needs to query the
administrator for a Pass Phrase in order to decrypt those files. This
query can be done in two ways which can be configured by
<em>type</em>:</p>
<ul>
<li><code>builtin</code>
    <p>
    This is the default where an interactive terminal dialog occurs at startup
    time just before Apache detaches from the terminal. Here the administrator
    has to manually enter the Pass Phrase for each encrypted Private Key file.
    Because a lot of SSL-enabled virtual hosts can be configured, the
    following reuse-scheme is used to minimize the dialog: When a Private Key
    file is encrypted, all known Pass Phrases (at the beginning there are
    none, of course) are tried. If one of those known Pass Phrases succeeds no
    dialog pops up for this particular Private Key file. If none succeeded,
    another Pass Phrase is queried on the terminal and remembered for the next
    round (where it perhaps can be reused).</p>
    <p>
    This scheme allows mod_ssl to be maximally flexible (because for N encrypted
    Private Key files you <em>can</em> use N different Pass Phrases - but then
    you have to enter all of them, of course) while minimizing the terminal
    dialog (i.e. when you use a single Pass Phrase for all N Private Key files
    this Pass Phrase is queried only once).</p></li>

<li><code>|/path/to/program [args...]</code>

   <p>This mode allows an external program to be used which acts as a
   pipe to a particular input device; the program is sent the standard
   prompt text used for the <code>builtin</code> mode on
   <code>stdin</code>, and is expected to write password strings on
   <code>stdout</code>.  If several passwords are needed (or an
   incorrect password is entered), additional prompt text will be
   written subsequent to the first password being returned, and more
   passwords must then be written back.</p></li>

<li><code>exec:/path/to/program</code>
    <p>
    Here an external program is configured which is called at startup for each
    encrypted Private Key file. It is called with two arguments (the first is
    of the form ``<code>servername:portnumber</code>'', the second is either
    ``<code>RSA</code>'', ``<code>DSA</code>'', ``<code>ECC</code>'' or an
    integer index starting at 3 if more than three keys are configured), which
    indicate for which server and algorithm it has to print the corresponding
    Pass Phrase to <code>stdout</code>. In versions 2.4.8 (unreleased)
    and 2.4.9, it is called with one argument, a string of the
    form ``<code>servername:portnumber:index</code>'' (with <code>index</code>
    being a zero-based integer number), which indicate the server, TCP port
    and certificate number.  The intent is that this external
    program first runs security checks to make sure that the system is not
    compromised by an attacker, and only when these checks were passed
    successfully it provides the Pass Phrase.</p>
    <p>
    Both these security checks, and the way the Pass Phrase is determined, can
    be as complex as you like. Mod_ssl just defines the interface: an
    executable program which provides the Pass Phrase on <code>stdout</code>.
    Nothing more or less! So, if you're really paranoid about security, here
    is your interface. Anything else has to be left as an exercise to the
    administrator, because local security requirements are so different.</p>
    <p>
    The reuse-algorithm above is used here, too. In other words: The external
    program is called only once per unique Pass Phrase.</p></li>
</ul>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLPassPhraseDialog "exec:/usr/local/apache/sbin/pp-filter"</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProtocol" id="SSLProtocol">SSLProtocol</a> <a name="sslprotocol" id="sslprotocol">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Configure usable SSL/TLS protocol versions</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProtocol [+|-]<em>protocol</em> ...</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProtocol all -SSLv3 (up to 2.4.16: all)</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive can be used to control which versions of the SSL/TLS protocol
will be accepted in new connections.</p>
<p>
The available (case-insensitive) <em>protocol</em>s are:</p>
<ul>
<li><code>SSLv3</code>
    <p>
    This is the Secure Sockets Layer (SSL) protocol, version 3.0, from
    the Netscape Corporation.
    It is the successor to SSLv2 and the predecessor to TLSv1, but is
    deprecated in <a href="http://www.ietf.org/rfc/rfc7568.txt">RFC 7568</a>.</p></li>

<li><code>TLSv1</code>
    <p>
    This is the Transport Layer Security (TLS) protocol, version 1.0.
    It is the successor to SSLv3 and is defined in
    <a href="http://www.ietf.org/rfc/rfc2246.txt">RFC 2246</a>.
    It is supported by nearly every client.</p></li>

<li><code>TLSv1.1</code> (when using OpenSSL 1.0.1 and later)
    <p>
    A revision of the TLS 1.0 protocol, as defined in
    <a href="http://www.ietf.org/rfc/rfc4346.txt">RFC 4346</a>.</p></li>

<li><code>TLSv1.2</code> (when using OpenSSL 1.0.1 and later)
    <p>
    A revision of the TLS 1.1 protocol, as defined in
    <a href="http://www.ietf.org/rfc/rfc5246.txt">RFC 5246</a>.</p></li>

<li><code>all</code>
    <p>
    This is a shortcut for ``<code>+SSLv3 +TLSv1</code>'' or
    - when using OpenSSL 1.0.1 and later -
    ``<code>+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2</code>'', respectively
    (except for OpenSSL versions compiled with the ``no-ssl3'' configuration
    option, where <code>all</code> does not include <code>+SSLv3</code>).</p></li>
</ul>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProtocol TLSv1</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCACertificateFile" id="SSLProxyCACertificateFile">SSLProxyCACertificateFile</a> <a name="sslproxycacertificatefile" id="sslproxycacertificatefile">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>File of concatenated PEM-encoded CA Certificates
for Remote Server Auth</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCACertificateFile <em>file-path</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets the <em>all-in-one</em> file where you can assemble the
Certificates of Certification Authorities (CA) whose <em>remote servers</em> you deal
with. These are used for Remote Server Authentication. Such a file is simply the
concatenation of the various PEM-encoded Certificate files, in order of
preference. This can be used alternatively and/or additionally to
<code class="directive"><a href="#sslproxycacertificatepath">SSLProxyCACertificatePath</a></code>.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyCACertificateFile "/usr/local/apache2/conf/ssl.crt/ca-bundle-remote-server.crt"</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCACertificatePath" id="SSLProxyCACertificatePath">SSLProxyCACertificatePath</a> <a name="sslproxycacertificatepath" id="sslproxycacertificatepath">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Directory of PEM-encoded CA Certificates for
Remote Server Auth</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCACertificatePath <em>directory-path</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets the directory where you keep the Certificates of
Certification Authorities (CAs) whose remote servers you deal with. These are used to
verify the remote server certificate on Remote Server Authentication.</p>
<p>
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you can't just place the Certificate files
there: you also have to create symbolic links named
<em>hash-value</em><code>.N</code>. And you should always make sure this directory
contains the appropriate symbolic links.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyCACertificatePath "/usr/local/apache2/conf/ssl.crt/"</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCARevocationCheck" id="SSLProxyCARevocationCheck">SSLProxyCARevocationCheck</a> <a name="sslproxycarevocationcheck" id="sslproxycarevocationcheck">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Enable CRL-based revocation checking for Remote Server Auth</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCARevocationCheck chain|leaf|none</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyCARevocationCheck none</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
Enables certificate revocation list (CRL) checking for the
<em>remote servers</em> you deal with. At least one of
<code class="directive"><a href="#sslproxycarevocationfile">SSLProxyCARevocationFile</a></code>
or <code class="directive"><a href="#sslproxycarevocationpath">SSLProxyCARevocationPath</a></code> must be
configured. When set to <code>chain</code> (recommended setting),
CRL checks are applied to all certificates in the chain, while setting it to
<code>leaf</code> limits the checks to the end-entity cert.
</p>
<div class="note">
<h3>When set to <code>chain</code> or <code>leaf</code>,
CRLs <em>must</em> be available for successful validation</h3>
<p>
Prior to version 2.3.15, CRL checking in mod_ssl also succeeded when
no CRL(s) were found in any of the locations configured with
<code class="directive"><a href="#sslproxycarevocationfile">SSLProxyCARevocationFile</a></code>
or <code class="directive"><a href="#sslproxycarevocationpath">SSLProxyCARevocationPath</a></code>.
With the introduction of this directive, the behavior has been changed:
when checking is enabled, CRLs <em>must</em> be present for the validation
to succeed - otherwise it will fail with an
<code>"unable to get certificate CRL"</code> error.
</p>
</div>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyCARevocationCheck chain</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCARevocationFile" id="SSLProxyCARevocationFile">SSLProxyCARevocationFile</a> <a name="sslproxycarevocationfile" id="sslproxycarevocationfile">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>File of concatenated PEM-encoded CA CRLs for
Remote Server Auth</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCARevocationFile <em>file-path</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets the <em>all-in-one</em> file where you can
assemble the Certificate Revocation Lists (CRL) of Certification
Authorities (CA) whose <em>remote servers</em> you deal with. These are used
for Remote Server Authentication.  Such a file is simply the concatenation of
the various PEM-encoded CRL files, in order of preference. This can be
used alternatively and/or additionally to <code class="directive"><a href="#sslproxycarevocationpath">SSLProxyCARevocationPath</a></code>.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyCARevocationFile "/usr/local/apache2/conf/ssl.crl/ca-bundle-remote-server.crl"</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCARevocationPath" id="SSLProxyCARevocationPath">SSLProxyCARevocationPath</a> <a name="sslproxycarevocationpath" id="sslproxycarevocationpath">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Directory of PEM-encoded CA CRLs for
Remote Server Auth</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCARevocationPath <em>directory-path</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets the directory where you keep the Certificate Revocation
Lists (CRL) of Certification Authorities (CAs) whose remote servers you deal with.
These are used to revoke the remote server certificate on Remote Server Authentication.</p>
<p>
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you have not only to place the CRL files there.
Additionally you have to create symbolic links named
<em>hash-value</em><code>.rN</code>. And you should always make sure this directory
contains the appropriate symbolic links.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyCARevocationPath "/usr/local/apache2/conf/ssl.crl/"</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCheckPeerCN" id="SSLProxyCheckPeerCN">SSLProxyCheckPeerCN</a> <a name="sslproxycheckpeercn" id="sslproxycheckpeercn">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Whether to check the remote server certificate's CN field
</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCheckPeerCN on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyCheckPeerCN on</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets whether the remote server certificate's CN field is
compared against the hostname of the request URL. If both are not equal
a 502 status code (Bad Gateway) is sent. <code>SSLProxyCheckPeerCN</code> is
superseded by <code class="directive"><a href="#sslproxycheckpeername">SSLProxyCheckPeerName</a></code>
in release 2.4.5 and later. 
</p>
<p>
In all releases 2.4.5 through 2.4.20, setting
<code>SSLProxyCheckPeerName off</code> was sufficient to enable this behavior
(as the <code>SSLProxyCheckPeerCN</code> default was <code>on</code>.) In 
these releases, both directives must be set to <code>off</code> to completely
avoid remote server certificate name validation. Many users reported this
to be very confusing.
</p>
<p>
As of release 2.4.21, all configurations which enable either one of the
<code>SSLProxyCheckPeerName</code> or <code>SSLProxyCheckPeerCN</code> options
will use the new <code class="directive"><a href="#sslproxycheckpeername">SSLProxyCheckPeerName</a></code>
behavior, and all configurations which disable either one of the 
<code>SSLProxyCheckPeerName</code> or <code>SSLProxyCheckPeerCN</code> options
will suppress all remote server certificate name validation. Only the following
configuration will trigger the legacy certificate CN comparison in 2.4.21 and
later releases;
</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyCheckPeerCN on
SSLProxyCheckPeerName off</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCheckPeerExpire" id="SSLProxyCheckPeerExpire">SSLProxyCheckPeerExpire</a> <a name="sslproxycheckpeerexpire" id="sslproxycheckpeerexpire">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Whether to check if remote server certificate is expired
</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCheckPeerExpire on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyCheckPeerExpire on</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets whether it is checked if the remote server certificate
is expired or not. If the check fails a 502 status code (Bad Gateway) is
sent.
</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyCheckPeerExpire on</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCheckPeerName" id="SSLProxyCheckPeerName">SSLProxyCheckPeerName</a> <a name="sslproxycheckpeername" id="sslproxycheckpeername">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Configure host name checking for remote server certificates
</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCheckPeerName on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyCheckPeerName on</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Apache HTTP Server 2.4.5 and later</td></tr>
</table>
<p>
This directive configures host name checking for server certificates when 
mod_ssl is acting as an SSL client. The check will succeed if the host name 
from the request URI matches one of the CN attribute(s) of the certificate's 
subject, or matches the subjectAltName extension. If the check fails, the SSL 
request is aborted and a 502 status code (Bad Gateway) is returned.
</p>
<p>
Wildcard matching is supported for specific cases: an subjectAltName entry
of type dNSName, or CN attributes starting with <code>*.</code> will match
with any host name of the same number of name elements and the same suffix.
E.g. <code>*.example.org</code> will match <code>foo.example.org</code>,
but will not match <code>foo.bar.example.org</code>, because the number of
elements in the respective host names differs.
</p>
<p>
This feature was introduced in 2.4.5 and superseded the behavior of the 
<code class="directive"><a href="#sslproxycheckpeercn">SSLProxyCheckPeerCN</a></code> directive, which 
only tested the exact value in the first CN attribute against the host name.
However, many users were confused by the behavior of using these directives
individually, so the mutual behavior of <code>SSLProxyCheckPeerName</code> 
and <code>SSLProxyCheckPeerCN</code> directives were improved in release 
2.4.21. See the <code class="directive"><a href="#sslproxycheckpeercn">SSLProxyCheckPeerCN</a></code> 
directive description for the original behavior and details of these 
improvements.
</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyCipherSuite" id="SSLProxyCipherSuite">SSLProxyCipherSuite</a> <a name="sslproxyciphersuite" id="sslproxyciphersuite">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Cipher Suite available for negotiation in SSL
proxy handshake</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyCipherSuite <em>cipher-spec</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>AuthConfig</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>Equivalent to <code class="directive"><a href="#sslciphersuite">SSLCipherSuite</a></code>, but
for the proxy connection.
Please refer to <code class="directive"><a href="#sslciphersuite">SSLCipherSuite</a></code>
for additional information.</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyEngine" id="SSLProxyEngine">SSLProxyEngine</a> <a name="sslproxyengine" id="sslproxyengine">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>SSL Proxy Engine Operation Switch</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyEngine on|off</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyEngine off</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive toggles the usage of the SSL/TLS Protocol Engine for proxy. This
is usually used inside a <code class="directive"><a href="../mod/core.html#virtualhost">&lt;VirtualHost&gt;</a></code> section to enable SSL/TLS for proxy
usage in a particular virtual host. By default the SSL/TLS Protocol Engine is
disabled for proxy both for the main server and all configured virtual hosts.</p>

<p>Note that the <code class="directive">SSLProxyEngine</code> directive should not, in
general, be included in a virtual host that will be acting as a
forward proxy (using <code class="directive"><a href="../mod/mod_proxy.html#proxy">&lt;Proxy&gt;</a></code>
or <code class="directive"><a href="../mod/mod_proxy.html#proxyrequests">ProxyRequests</a></code> directives).
<code class="directive">SSLProxyEngine</code> is not required to enable a forward proxy
server to proxy SSL/TLS requests.</p>

<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">&lt;VirtualHost _default_:443&gt;
    SSLProxyEngine on
    #...
&lt;/VirtualHost&gt;</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyMachineCertificateChainFile" id="SSLProxyMachineCertificateChainFile">SSLProxyMachineCertificateChainFile</a> <a name="sslproxymachinecertificatechainfile" id="sslproxymachinecertificatechainfile">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>File of concatenated PEM-encoded CA certificates to be used by the proxy for choosing a certificate</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyMachineCertificateChainFile <em>filename</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Not applicable</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets the all-in-one file where you keep the certificate chain
for all of the client certs in use. This directive will be needed if the
remote server presents a list of CA certificates that are not direct signers
of one of the configured client certificates.
</p>
<p>
This referenced file is simply the concatenation of the various PEM-encoded
certificate files. Upon startup, each client certificate configured will
be examined and a chain of trust will be constructed.
</p>
<div class="warning"><h3>Security warning</h3>
<p>If this directive is enabled, all of the certificates in the file will be
trusted as if they were also in <code class="directive"><a href="#sslproxycacertificatefile">
SSLProxyCACertificateFile</a></code>.</p>
</div>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyMachineCertificateChainFile "/usr/local/apache2/conf/ssl.crt/proxyCA.pem"</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyMachineCertificateFile" id="SSLProxyMachineCertificateFile">SSLProxyMachineCertificateFile</a> <a name="sslproxymachinecertificatefile" id="sslproxymachinecertificatefile">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>File of concatenated PEM-encoded client certificates and keys to be used by the proxy</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyMachineCertificateFile <em>filename</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Not applicable</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets the all-in-one file where you keep the certificates and
keys used for authentication of the proxy server to remote servers.
</p>
<p>
This referenced file is simply the concatenation of the various PEM-encoded
certificate files, in order of preference. Use this directive alternatively
or additionally to <code>SSLProxyMachineCertificatePath</code>.
</p>
<div class="warning">
<p>Currently there is no support for encrypted private keys</p>
</div>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyMachineCertificateFile "/usr/local/apache2/conf/ssl.crt/proxy.pem"</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyMachineCertificatePath" id="SSLProxyMachineCertificatePath">SSLProxyMachineCertificatePath</a> <a name="sslproxymachinecertificatepath" id="sslproxymachinecertificatepath">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Directory of PEM-encoded client certificates and keys to be used by the proxy</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyMachineCertificatePath <em>directory</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Not applicable</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets the directory where you keep the certificates and
keys used for authentication of the proxy server to remote servers.
</p>
<p>The files in this directory must be PEM-encoded and are accessed through
hash filenames. Additionally, you must create symbolic links named
<code><em>hash-value</em>.N</code>. And you should always make sure this
directory contains the appropriate symbolic links.</p>
<div class="warning">
<p>Currently there is no support for encrypted private keys</p>
</div>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyMachineCertificatePath "/usr/local/apache2/conf/proxy.crt/"</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyProtocol" id="SSLProxyProtocol">SSLProxyProtocol</a> <a name="sslproxyprotocol" id="sslproxyprotocol">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Configure usable SSL protocol flavors for proxy usage</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyProtocol [+|-]<em>protocol</em> ...</code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyProtocol all -SSLv3 (up to 2.4.16: all)</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Override">Override:</a></th><td>Options</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>

<p>
This directive can be used to control the SSL protocol flavors mod_ssl should
use when establishing its server environment for proxy . It will only connect
to servers using one of the provided protocols.</p>
<p>Please refer to <code class="directive"><a href="#sslprotocol">SSLProtocol</a></code>
for additional information.
</p>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyVerify" id="SSLProxyVerify">SSLProxyVerify</a> <a name="sslproxyverify" id="sslproxyverify">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Type of remote server Certificate verification</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyVerify <em>level</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyVerify none</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>

<p>When a proxy is configured to forward requests to a remote SSL
server, this directive can be used to configure certificate
verification of the remote server. </p>
<p>
The following levels are available for <em>level</em>:</p>
<ul>
<li><strong>none</strong>:
     no remote server Certificate is required at all</li>
<li><strong>optional</strong>:
     the remote server <em>may</em> present a valid Certificate</li>
<li><strong>require</strong>:
     the remote server <em>has to</em> present a valid Certificate</li>
<li><strong>optional_no_ca</strong>:
     the remote server may present a valid Certificate<br />
     but it need not to be (successfully) verifiable.</li>
</ul>
<p>In practice only levels <strong>none</strong> and
<strong>require</strong> are really interesting, because level
<strong>optional</strong> doesn't work with all servers and level
<strong>optional_no_ca</strong> is actually against the idea of
authentication (but can be used to establish SSL test pages, etc.)</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyVerify require</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLProxyVerifyDepth" id="SSLProxyVerifyDepth">SSLProxyVerifyDepth</a> <a name="sslproxyverifydepth" id="sslproxyverifydepth">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Maximum depth of CA Certificates in Remote Server
Certificate verification</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLProxyVerifyDepth <em>number</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">Default:</a></th><td><code>SSLProxyVerifyDepth 1</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This directive sets how deeply mod_ssl should verify before deciding that the
remote server does not have a valid certificate. </p>
<p>
The depth actually is the maximum number of intermediate certificate issuers,
i.e. the number of CA certificates which are max allowed to be followed while
verifying the remote server certificate. A depth of 0 means that self-signed
remote server certificates are accepted only, the default depth of 1 means
the remote server certificate can be self-signed or has to be signed by a CA
which is directly known to the server (i.e. the CA's certificate is under
<code class="directive"><a href="#sslproxycacertificatepath">SSLProxyCACertificatePath</a></code>), etc.</p>
<div class="example"><h3>Example</h3><pre class="prettyprint lang-config">SSLProxyVerifyDepth 10</pre>
</div>

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLRandomSeed" id="SSLRandomSeed">SSLRandomSeed</a> <a name="sslrandomseed" id="sslrandomseed">Directive</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Pseudo Random Number Generator (PRNG) seeding
source</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntax:</a></th><td><code>SSLRandomSeed <em>context</em> <em>source</em>
[<em>bytes</em>]</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Context:</a></th><td>server config</td></tr>
<tr><th><a href="directive-dict.html#Status">Status:</a></th><td>Extension</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_ssl</td></tr>
</table>
<p>
This configures one or more sources for seeding the Pseudo Random Number
Generator (PRNG) in OpenSSL at startup time (<em>context</em> is
<code>startup</code>) and/or just before a new SSL connection is established
(<em>context</em> is <code>connect</code>). This directive can only be used
in the global server context because the PRNG is a global facility.</p>
<p>
The following <em>source</em> variants are available:</p>
<ul>
<li><code>builtin</code>
    <p> This is the always available builtin seeding source. Its usage
    consumes minimum CPU cycles under runtime and hence can be always used
    without drawbacks. The source used for seeding the PRNG contains of the
    current time, the current process id and (when applicable) a randomly
    chosen 1KB extract of the inter-process scoreboard structure of Apache.
    The drawback is that this is not really a strong source and at startup
    time (where the scoreboard is still not available) this source just
    produces a few bytes of entropy. So you should always, at least for the
    startup, use an additional seeding source.</p></li>
<li><code>file:/path/to/source</code>
    <p>
    This variant uses an external file <code>/path/to/source</code> as the
    source for seeding the PRNG. When <em>bytes</em> is specified, only the
    first <em>bytes</em> number of bytes of the file form the entropy (and
    <em>bytes</em> is given to <code>/path/to/source</code> as the first
    argument). When <em>bytes</em> is not specified the whole file forms the
    entropy (and <code>0</code> is given to <code>/path/to/source</code> as
    the first argument). Use this especially at startup time, for instance
    with an available <code>/dev/random</code> and/or
    <code>/dev/urandom</code> devices (which usually exist on modern Unix
    derivatives like FreeBSD and Linux).</p>
    <p>
    <em>But be careful</em>: Usually <code>/dev/random</code> provides only as
    much entropy data as it actually has, i.e. when you request 512 bytes of
    entropy, but the device currently has only 100 bytes available two things
    can happen: On some platforms you receive only the 100 bytes while on
    other platforms the read blocks until enough bytes are available (which
    can take a long time). Here using an existing <code>/dev/urandom</code> is
    better, because it never blocks and actually gives the amount of requested
    data. The drawback is just that the quality of the received data may not
    be the best.</p></li>

<li><code>exec:/path/to/program</code>
    <p>
    This variant uses an external executable
    <code>/path/to/program</code> as the source for seeding the
    PRNG. When <em>bytes</em> is specified, only the first
    <em>bytes</em> number of bytes of its <code>stdout</code> contents
    form the entropy. When <em>bytes</em> is not specified, the