mod_ssl.html.en

最新apache的源代码

    as determined by the platform and APR.</p></li>
</ul>
<div class="example"><h3>Example</h3><p><code>
SSLMutex file:/usr/local/apache/logs/ssl_mutex
</code></p></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>CompatEnvVars</code>
    <p>
    When this option is enabled, additional CGI/SSI environment variables are
    created for backward compatibility to other Apache SSL solutions. Look in
    the <a href="../ssl/ssl_compat.html">Compatibility</a> chapter for details
    on the particular variables generated.</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>
</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 maybe not what the user expects, so enable this on a
    per-directory basis only, please.</p>
</li>
</ul>
<div class="example"><h3>Example</h3><p><code>
SSLOptions +FakeBasicAuth -StrictRequire<br />
&lt;Files ~ "\.(cgi|shtml)$"&gt;<br />
    SSLOptions +StdEnvVars +CompatEnvVars -ExportCertData<br />
&lt;Files&gt;
</code></p></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>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>'' or ``<code>DSA</code>''), which indicate for which
    server and algorithm it has to print the corresponding Pass Phrase to
    <code>stdout</code>. 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>
<p>
Example:</p>
<div class="example"><p><code>
SSLPassPhraseDialog exec:/usr/local/apache/sbin/pp-filter
</code></p></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 protocol flavors</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</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. Clients then can only connect
with one of the provided protocols.</p>
<p>
The available (case-insensitive) <em>protocol</em>s are:</p>
<ul>
<li><code>SSLv2</code>
    <p>
    This is the Secure Sockets Layer (SSL) protocol, version 2.0. It is the
    original SSL protocol as designed by Netscape Corporation.</p></li>