mod_ssl.html.en

Apache官方在今天放出产品系列2.2的最新版本2.2.11的源码包 最流行的HTTP服务器软件之一

    <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>|/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>'' 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>
<div class="example"><h3>Example</h3><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.  Though it's
    use has been deprecated, because of weaknesses in the security of the protocol.</p></li>

<li><code>SSLv3</code>
    <p>
    This is the Secure Sockets Layer (SSL) protocol, version 3.0, from the Netscape Corportaion. 
    It is the successor to SSLv2 and the predecessor to TLSv1. It's supported by
    almost all popular browsers.</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">RFC2246</a>. 
    Which has been obsoleted by <a href="http://www.ietf.org/rfc/rfc4346.txt">RFC4346</a>.</p></li>

<li><code>All</code>
    <p>
    This is a shortcut for ``<code>+SSLv2 +SSLv3 +TLSv1</code>'' and a
    convinient way for enabling all protocols except one when used in
    combination with the minus sign on a protocol as the example above 
    shows.</p></li>
</ul>
<div class="example"><h3>Example</h3><p><code>
#   enable SSLv3 and TLSv1, but not SSLv2<br />
SSLProtocol all -SSLv2
</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="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="dir