<p>When a client certificate is requested by mod_ssl, a list of
<em>acceptable Certificate Authority names</em> is sent to the client
in the SSL handshake. These CA names can be used by the client to
select an appropriate client certificate out of those it has
available.</p>
<p>If neither of the directives <code class="directive"><a href="#sslcadnrequestpath">SSLCADNRequestPath</a></code> or <code class="directive"><a href="#sslcadnrequestfile">SSLCADNRequestFile</a></code> are given, then the
set of acceptable CA names sent to the client is the names of all the
CA certificates given by the <code class="directive"><a href="#sslcacertificatefile">SSLCACertificateFile</a></code> and <code class="directive"><a href="#sslcacertificatepath">SSLCACertificatePath</a></code> directives; in other
words, the names of the CAs which will actually be used to verify the
client certificate.</p>
<p>In some circumstances, it is useful to be able to send a set of
acceptable CA names which differs from the actual CAs used to verify
the client certificate - for example, if the client certificates are
signed by intermediate CAs. In such cases, <code class="directive"><a href="#sslcadnrequestpath">SSLCADNRequestPath</a></code> and/or <code class="directive"><a href="#sslcadnrequestfile">SSLCADNRequestFile</a></code> can be used; the
acceptable CA names are then taken from the complete set of
certificates in the directory and/or file specified by this pair of
directives.</p>
<p><code class="directive"><a href="#sslcadnrequestfile">SSLCADNRequestFile</a></code> must
specify an <em>all-in-one</em> file containing a concatenation of
This directive sets the optional <em>all-in-one</em> file where you can
assemble the certificates of Certification Authorities (CA) which form the
certificate chain of the server certificate. This starts with the issuing CA
certificate of of the server certificate and can range up to the root CA
certificate. Such a file is simply the concatenation of the various
PEM-encoded CA Certificate files, usually in certificate chain order.</p>
<p>
This should be used alternatively and/or additionally to <code class="directive"><a href="#sslcacertificatepath">SSLCACertificatePath</a></code> for explicitly
constructing the server certificate chain which is sent to the browser
in addition to the server certificate. It is especially useful to
avoid conflicts with CA certificates when using client
authentication. Because although placing a CA certificate of the
server certificate chain into <code class="directive"><a href="#sslcacertificatepath">SSLCACertificatePath</a></code> has the same effect
for the certificate chain construction, it has the side-effect that
client certificates issued by this same CA certificate are also
accepted on client authentication. That's usually not one expect.</p>
<p>
But be careful: Providing the certificate chain works only if you are using a
<em>single</em> (either RSA <em>or</em> DSA) based server certificate. If you are
using a coupled RSA+DSA certificate pair, this will work only if actually both
certificates use the <em>same</em> certificate chain. Else the browsers will be
<tr><th><a href="directive-dict.html#Compatibility">Compatibility:</a></th><td>Available in 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
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> and <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>
<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#Description">Description:</a></th><td>Directory of PEM-encoded client certificates and keys to be used by the proxy</td></tr>
<p><span>Available Languages: </span><a href="../en/mod/mod_ssl.html" title="English"> en </a></p>
</div><div id="footer">
<p class="apache">Copyright 2007 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
