ssl_reference.wml

mod_ssl-2.8.31-1.3.41.tar.gz 好用的ssl工具

<i>hash-value</i><tt>.rN</tt>.  And you should always make sure this directory
contains the appropriate symbolic links. Use the <code>Makefile</code> which
comes with mod_ssl to accomplish this task.

<p>
Example:
<blockquote>
<pre>
SSLCARevocationPath /usr/local/apache/conf/ssl.crl/
</pre>
</blockquote>


<!-- SSLCARevocationFile -------------------------------------------->

<p>
<br>
<a name="SSLCARevocationFile"></a>
<h2>SSLCARevocationFile</h2>

<directive
    name="SSLCARevocationFile"
    description="File of concatenated PEM-encoded CA CRLs for Client Auth."
    syntax="<code>SSLCARevocationFile</code> <em>filename</em>"
    default="<em>None</em>"
    context="server config, virtual host"
    override="<em>Not applicable</em>"
    compat="mod_ssl 2.3"
>

<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>clients</em> you deal with.  These are used for Client 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 <a href="#SSLCARevocationPath">SSLCARevocationPath</a>.

<p>
Example:
<blockquote>
<pre>
SSLCARevocationFile /usr/local/apache/conf/ssl.crl/ca-bundle-client.crl
</pre>
</blockquote>


<!-- SSLVerifyClient ------------------------------------------------->

<p>
<br>
<a name="SSLVerifyClient"></a>
<h2>SSLVerifyClient</h2>

<directive
    name="SSLVerifyClient"
    description="Type of Client Certificate verification"
    syntax="<code>SSLVerifyClient</code> <em>level</em>"
    default="<code>SSLVerifyClient none</code>"
    context="server config, virtual host, directory, .htaccess"
    override="AuthConfig"
    compat="mod_ssl 2.0"
>

<p>
This directive sets the Certificate verification level for the Client
Authentication.  Notice that this directive can be used both in per-server and
per-directory context. In per-server context it applies to the client
authentication process used in the standard SSL handshake when a connection is
established. In per-directory context it forces a SSL renegotation with the
reconfigured client verification level after the HTTP request was read but
before the HTTP response is sent.

<p>
The following levels are available for <em>level</em>:

<ul>
<li><strong>none</strong>:
     no client Certificate is required at all
<li><strong>optional</strong>:
     the client <em>may</em> present a valid Certificate
<li><strong>require</strong>:
     the client <em>has to</em> present a valid Certificate
<li><strong>optional_no_ca</strong>:
     the client may present a valid Certificate<br> 
     but it need not to be (successfully) verifiable.
</ul>

In practice only levels <strong>none</strong> and <strong>require</strong> are
really interesting, because level <strong>optional</strong> doesn't work with
all browsers 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>
Example:
<blockquote>
<pre>
SSLVerifyClient require
</pre>
</blockquote>


<!-- SSLVerifyDepth ------------------------------------------------->

<p>
<br>
<a name="SSLVerifyDepth"></a>
<h2>SSLVerifyDepth</h2>

<directive
    name="SSLVerifyDepth"
    description="Maximum depth of CA Certificates in Client Certificate verification"
    syntax="<code>SSLVerifyDepth</code> <em>number</em>"
    default="<code>SSLVerifyDepth 1</code>"
    context="server config, virtual host, directory, .htaccess"
    override="AuthConfig"
    compat="mod_ssl 2.0"
>

<p> 
This directive sets how deeply mod_ssl should verify before deciding that the
clients don't have a valid certificate.  Notice that this directive can be
used both in per-server and per-directory context. In per-server context it
applies to the client authentication process used in the standard SSL
handshake when a connection is established. In per-directory context it forces
a SSL renegotation with the reconfigured client verification depth after the
HTTP request was read but before the HTTP response is sent.

<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 client certificate. A depth of 0 means that self-signed client
certificates are accepted only, the default depth of 1 means the client
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>SSLCACertificatePath</code>), etc.

<p>
Example:
<blockquote>
<pre>
SSLVerifyDepth 10
</pre>
</blockquote>


<!-- SSLLog --------------------------------------------------------->

<p>
<br>
<a name="SSLLog"></a>
<h2>SSLLog</h2>

<directive
    name="SSLLog"
    description="Where to write the dedicated SSL engine logfile"
    syntax="<code>SSLLog</code> <em>filename</em>"
    default="<em>None</em>"
    context="server config, virtual host"
    override="<em>Not applicable</em>"
    compat="mod_ssl 2.1"
>

<p>
This directive sets the name of the dedicated SSL protocol engine logfile.
Error type messages are additionally duplicated to the general Apache error
log file (directive <code>ErrorLog</code>). Put this somewhere where it cannot
be used for symlink attacks on a real server (i.e. somewhere where only root
can write). If the <em>filename</em> does not begin with a slash
('<code>/</code>') then it is assumed to be relative to the <em>Server
Root</em>.  If <em>filename</em> begins with a bar ('<code>|</code>') then the
following string is assumed to be a path to an executable program to which a
reliable pipe can be established. The directive should occur only once per
virtual server config.  

<p>
Example:
<blockquote>
<pre>
SSLLog /usr/local/apache/logs/ssl_engine_log
</pre>
</blockquote>


<!-- SSLLogLevel ---------------------------------------------------->

<p>
<br>
<a name="SSLLogLevel"></a>
<h2>SSLLogLevel</h2>

<directive
    name="SSLLogLevel"
    description="Logging level for the dedicated SSL engine logfile"
    syntax="<code>SSLLogLevel</code> <em>level</em>"
    default="<code>SSLLogLevel none</code>"
    context="server config, virtual host"
    override="<em>Not applicable</em>"
    compat="mod_ssl 2.1"
>

<p>
This directive sets the verbosity degree of the dedicated SSL protocol engine
logfile. The <em>level</em> is one of the following (in ascending order where
higher levels include lower levels):

<ul>
<li><code>none</code><br>
    no dedicated SSL logging is done, but messages of level
    ``<code>error</code>'' are still written to the general Apache error
    logfile.
<p>
<li><code>error</code><br>
    log messages of error type only, i.e. messages which show fatal situations
    (processing is stopped).  Those messages are also duplicated to the
    general Apache error logfile.
<p>
<li><code>warn</code><br>
    log also warning messages, i.e. messages which show non-fatal problems
    (processing is continued).
<p>
<li><code>info</code><br>
    log also informational messages, i.e.  messages which show major
    processing steps.
<p>
<li><code>trace</code><br>
    log also trace messages, i.e.  messages which show minor processing steps.
<p>
<li><code>debug</code><br>
    log also debugging messages, i.e.  messages which show development and
    low-level I/O information.
</ul>

<p>
Example:
<blockquote>
<pre>
SSLLogLevel warn
</pre>
</blockquote>


<!-- SSLOptions ----------------------------------------------------->

<p>
<br>
<a name="SSLOptions"></a>
<h2>SSLOptions</h2>

<directive
    name="SSLOptions"
    description="Configure various SSL engine run-time options"
    syntax="<code>SSLOptions</code> [+-]<em>option</em> ..."
    default="<em>None</em>"
    context="server config, virtual host, directory, .htaccess"
    override="Options"
    compat="mod_ssl 2.1"
>

<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>
The available <em>option</em>s are:

<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><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_compat.html">Compatibility</a> chapter for details 
    on the particular variables generated.
<p>
<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><i>n</i> (with <i>n</i> = 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><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><code>StrictRequire</code>
    <p>