mod_ssl.html

这个是我在web培训时老师提供的手册

</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="SSLHonorCipherOrder" id="SSLHonorCipherOrder">SSLHonorCipherOrder</a> <a name="sslhonorcipherorder" id="sslhonorcipherorder">指令</a></h2>
<table border="1" cellpadding="0" cellspacing="0" bordercolor="#AAAAAA" class="directive">
<tr><th><a href="directive-dict.html#Description">说明</a></th><td>Option to prefer the server's cipher preference order</td></tr>
<tr><th><a href="directive-dict.html#Syntax">语法</a></th><td><code>SSLHonorCiperOrder <em>flag</em></code></td></tr>
<tr><th><a href="directive-dict.html#Context">作用域</a></th><td>server config, virtual host</td></tr>
<tr><th><a href="directive-dict.html#Status">状态</a></th><td>扩展(E)</td></tr>
<tr><th><a href="directive-dict.html#Module">模块</a></th><td>mod_ssl</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">兼容性</a></th><td>仅在 Apache 2.1 and later, if using OpenSSL 0.9.7 or later</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>示例</h3><p><code>
SSLHonorCipherOrder on
</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="SSLMutex" id="SSLMutex">SSLMutex</a> <a name="sslmutex" id="sslmutex">指令</a></h2>
<table border="1" cellpadding="0" cellspacing="0" bordercolor="#AAAAAA" class="directive">
<tr><th><a href="directive-dict.html#Description">说明</a></th><td>Semaphore for internal mutual exclusion of 
operations</td></tr>
<tr><th><a href="directive-dict.html#Syntax">语法</a></th><td><code>SSLMutex <em>type</em></code></td></tr>
<tr><th><a href="directive-dict.html#Default">默认值</a></th><td><code>SSLMutex none</code></td></tr>
<tr><th><a href="directive-dict.html#Context">作用域</a></th><td>server config</td></tr>
<tr><th><a href="directive-dict.html#Status">状态</a></th><td>扩展(E)</td></tr>
<tr><th><a href="directive-dict.html#Module">模块</a></th><td>mod_ssl</td></tr>
</table>
<p>
This configures the SSL engine's semaphore (aka. lock) which is used for mutual
exclusion of operations which have to be done in a synchronized way between the
pre-forked Apache server processes. This directive can only be used in the
global server context because it's only useful to have one global mutex.
This directive is designed to closely match the
<code class="directive"><a href="../mod/mpm_common.html#acceptmutex">AcceptMutex</a></code> directive.</p>
<p>
The following Mutex <em>types</em> are available:</p>
<ul>
<li><code>none | no</code>
    <p>
    This is the default where no Mutex is used at all. Use it at your own
    risk. But because currently the Mutex is mainly used for synchronizing
    write access to the SSL Session Cache you can live without it as long
    as you accept a sometimes garbled Session Cache. So it's not recommended
    to leave this the default. Instead configure a real Mutex.</p></li>
<li><code>posixsem</code>
    <p>
    This is an elegant Mutex variant where a Posix Semaphore is used when possible.
    It is only available when the underlying platform
    and <a class="glossarylink" href="../glossary.html#apr" title="see glossary">APR</a> supports it.</p></li>
<li><code>sysvsem</code>
    <p>
    This is a somewhat elegant Mutex variant where a SystemV IPC Semaphore is used when
    possible. It is possible to "leak" SysV semaphores if processes crash before
    the semaphore is removed. It is only available when the underlying platform
    and <a class="glossarylink" href="../glossary.html#apr" title="see glossary">APR</a> supports it.</p></li>
<li><code>sem</code>
    <p>
    This directive tells the SSL Module to pick the "best" semaphore implementation
    available to it, choosing between Posix and SystemV IPC, in that order. It is only
    available when the underlying platform and <a class="glossarylink" href="../glossary.html#apr" title="see glossary">APR</a> supports at least one of the 2.</p></li>
<li><code>pthread</code>
    <p>
    This directive tells the SSL Module to use Posix thread mutexes. It is only available
    if the underlying platform and <a class="glossarylink" href="../glossary.html#apr" title="see glossary">APR</a> supports it.</p></li>
<li><code>fcntl:/path/to/mutex</code>
    <p>
    This is a portable Mutex variant where a physical (lock-)file and the <code>fcntl()</code>
    fucntion are used as the Mutex.
    Always use a local disk filesystem for <code>/path/to/mutex</code> and never a file
    residing on a NFS- or AFS-filesystem. It is only available when the underlying platform
    and <a class="glossarylink" href="../glossary.html#apr" title="see glossary">APR</a> supports it. Note: Internally, the Process ID (PID) of the
    Apache parent process is automatically appended to
    <code>/path/to/mutex</code> to make it unique, so you don't have to worry
    about conflicts yourself. Notice that this type of mutex is not available
    under the Win32 environment. There you <em>have</em> to use the semaphore
    mutex.</p></li>
<li><code>flock:/path/to/mutex</code>
    <p>
    This is similar to the <code>fcntl:/path/to/mutex</code> method with the
    exception that the <code>flock()</code> function is used to provide file
    locking. It is only available when the underlying platform
    and <a class="glossarylink" href="../glossary.html#apr" title="see glossary">APR</a> supports it.</p></li>
<li><code>file:/path/to/mutex</code>
    <p>
    This directive tells the SSL Module to pick the "best" file locking implementation
    available to it, choosing between <code>fcntl</code>和<code>flock</code>,
    in that order. It is only available when the underlying platform and <a class="glossarylink" href="../glossary.html#apr" title="see glossary">APR</a> supports
    at least one of the 2.</p></li>
<li><code>default | yes</code>
    <p>
    This directive tells the SSL Module to pick the default locking implementation
    as determined by the platform and <a class="glossarylink" href="../glossary.html#apr" title="see glossary">APR</a>.</p></li>
</ul>
<div class="example"><h3>示例</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">指令</a></h2>
<table border="1" cellpadding="0" cellspacing="0" bordercolor="#AAAAAA" class="directive">
<tr><th><a href="directive-dict.html#Description">说明</a></th><td>Configure various SSL engine run-time options</td></tr>
<tr><th><a href="directive-dict.html#Syntax">语法</a></th><td><code>SSLOptions [+|-]<em>option</em> ...</code></td></tr>
<tr><th><a href="directive-dict.html#Context">作用域</a></th><td>server config, virtual host, directory, .htaccess</td></tr>
<tr><th><a href="directive-dict.html#Override">覆盖项</a></th><td>Options</td></tr>
<tr><th><a href="directive-dict.html#Status">状态</a></th><td>扩展(E)</td></tr>
<tr><th><a href="directive-dict.html#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>和<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>或<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>或<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>示例</h3><p><code>