You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2002/07/25 02:16:26 UTC
cvs commit: httpd-2.0/docs/manual/mod mod_proxy.xml mod_ssl.xml
rbowen 2002/07/24 17:16:26
Modified: docs/manual/mod mod_proxy.xml mod_ssl.xml
Log:
SSLProxy* directives that exist in mod_ssl for Apache 2 but are not
documented anywhere.
Submitted by: Daniel Lopez
Reviewed by: Rich Bowen
Revision Changes Path
1.8 +3 -0 httpd-2.0/docs/manual/mod/mod_proxy.xml
Index: mod_proxy.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_proxy.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- mod_proxy.xml 7 Jun 2002 02:20:53 -0000 1.7
+++ mod_proxy.xml 25 Jul 2002 00:16:26 -0000 1.8
@@ -36,6 +36,9 @@
mod_proxy up to Apache v1.3.x has been <strong>removed</strong> from
mod_proxy and will be incorporated into a new module, mod_cache.</p>
+<p>If you need to use SSL when contacting remote servers, have a look at the
+<code>SSLProxy*</code> directives in mod_ssl.</p>
+
<note type="warning"><p>Do not enable proxying with <directive
module="mod_proxy">ProxyRequests</directive> until you have
<a href="#access">secured your server</a>. Open proxy servers are
1.5 +297 -0 httpd-2.0/docs/manual/mod/mod_ssl.xml
Index: mod_ssl.xml
===================================================================
RCS file: /home/cvs/httpd-2.0/docs/manual/mod/mod_ssl.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- mod_ssl.xml 23 May 2002 14:50:11 -0000 1.4
+++ mod_ssl.xml 25 Jul 2002 00:16:26 -0000 1.5
@@ -1169,4 +1169,301 @@
</usage>
</directivesynopsis>
+<directivesynopsis>
+<name>SSLProxyMachineCertificatePath</name>
+<description>Directory of PEM-encoded CA certificates for proxy server client certificates</description>
+<syntax>SSLProxyMachineCertificatePath <em>directory</em></syntax>
+<default>None</default>
+<contextlist><context>server config</context></contextlist>
+<override>Not applicable</override>
+
+<usage>
+<p>
+This directive sets the directory where you keep the certificates of
+Certification Authorities (CAs) whose proxy client certificates are used for
+authentication of the proxy server to remote servers.
+</p>
+<p>The files in this directory must be PEM-encoded and are accessed through
+hash filenames. Additionally, you must create symbolic links named
+<code><em>hash-value</em>.N</code>. And you should always make sure this
+directory contains the appropriate symbolic links. Use the Makefile which
+comes with mod_ssl to accomplish this task.
+</p>
+<p>
+Example:</p>
+<example>
+SSLProxyMachineCertificatePath /usr/local/apache/conf/ssl.crt/
+</example>
+</usage>
+</directivesynopsis>
+
+
+<directivesynopsis>
+<name>SSLProxyMachineCertificateFile</name>
+<description>File of concatenated PEM-encoded CA certificates for proxy server client certificates</description>
+<syntax>SSLProxyMachineCertificateFile <em>filename</em></syntax>
+<default>None</default>
+<contextlist><context>server config</context></contextlist>
+<override>Not applicable</override>
+
+<usage>
+<p>
+This directive sets the directory where you keep the certificates of
+Certification Authorities (CAs) whose proxy client certificates are used for
+authentication of the proxy server to remote servers.
+</p>
+<p>
+This referenced file is simply the concatenation of the various PEM-encoded
+certificate files, in order of preference. Use this directive alternatively
+or additionally to <code>SSLProxyMachineCertificatePath</code>.
+</p>
+<p>
+Example:</p>
+<example>
+SSLProxyMachineCertificatePath /usr/local/apache/conf/ssl.crt/
+</example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSLProxyVerify</name>
+<description>Type of remote server Certificate verification</description>
+<syntax>SSLProxyVerify <em>level</em></syntax>
+<default>SSLProxyVerify none</default>
+<contextlist><context>server config</context>
+<context>virtual host</context>
+<context>directory</context>
+<context>.htaccess</context></contextlist>
+<override>AuthConfig</override>
+
+<usage>
+<p>
+This directive sets the Certificate verification level for the remote server
+Authentication. Notice that this directive can be used both in per-server and
+per-directory context. In per-server context it applies to the remote server
+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 remote server verification level after the HTTP request was read but
+before the HTTP response is sent.</p>
+<p>
+The following levels are available for <em>level</em>:</p>
+<ul>
+<li><strong>none</strong>:
+ no remote server Certificate is required at all</li>
+<li><strong>optional</strong>:
+ the remote server <em>may</em> present a valid Certificate</li>
+<li><strong>require</strong>:
+ the remote server <em>has to</em> present a valid Certificate</li>
+<li><strong>optional_no_ca</strong>:
+ the remote server may present a valid Certificate<br />
+ but it need not to be (successfully) verifiable.</li>
+</ul>
+<p>In practice only levels <strong>none</strong> and
+<strong>require</strong> are really interesting, because level
+<strong>optional</strong> doesn't work with all servers 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><title>Example</title>
+SSLProxyVerify require
+</example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSLProxyVerifyDepth</name>
+<description>Maximum depth of CA Certificates in Remote Server
+Certificate verification</description>
+<syntax>SSLVerifyDepth <em>number</em></syntax>
+<default>SSLVerifyDepth 1</default>
+<contextlist><context>server config</context>
+<context>virtual host</context>
+<context>directory</context>
+<context>.htaccess</context></contextlist>
+<override>AuthConfig</override>
+
+<usage>
+<p>
+This directive sets how deeply mod_ssl should verify before deciding that the
+remote server does not 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 remote server verification depth after the
+HTTP request was read but before the HTTP response is sent.</p>
+<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 remote server certificate. A depth of 0 means that self-signed
+remote server certificates are accepted only, the default depth of 1 means
+the remote server 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
+<directive module="mod_ssl">SSLProxyCACertificatePath</directive>), etc.</p>
+<example><title>Example</title>
+SSLProxyVerifyDepth 10
+</example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSLProxyEngine</name>
+<description>SSL Proxy Engine Operation Switch</description>
+<syntax>SSLProxyEngine on|off</syntax>
+<default>SSLProxyEngine off</default>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+
+<usage>
+<p>
+This directive toggles the usage of the SSL/TLS Protocol Engine for proxy. This
+is usually used inside a <directive module="core"
+type="section">VirtualHost</directive> section to enable SSL/TLS for proxy
+usage in a particular virtual host. By default the SSL/TLS Protocol Engine is
+disabled for proxy image both for the main server and all configured virtual hosts.</p>
+<example><title>Example</title>
+<VirtualHost _default_:443><br />
+SSLProxyEngine on<br />
+...<br />
+</VirtualHost>
+</example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSLProxyProtocol</name>
+<description>Configure usable SSL protocol flavors for proxy usage</description>
+<syntax>SSLProxyProtocol [+|-]<em>protocol</em> ...</syntax>
+<default>SSLProxyProtocol all</default>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+<override>Options</override>
+
+<usage>
+<!-- XXX Why does this have an override and not .htaccess context? -->
+<p>
+This directive can be used to control the SSL protocol flavors mod_ssl should
+use when establishing its server environment for proxy . It will only connect
+to servers using one of the provided protocols.</p>
+<p>Please refer to <directive module="mod_ssl">SSLProtocol</directive>
+for additional information.
+</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSLProxyCipherSuite</name>
+<description>Cipher Suite available for negotiation in SSL
+proxy handshake</description>
+<syntax>SSLProxyCipherSuite <em>cipher-spec</em></syntax>
+<default>SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</default>
+<contextlist><context>server config</context>
+<context>virtual host</context>
+<context>directory</context>
+<context>.htaccess</context></contextlist>
+<override>AuthConfig</override>
+<usage>
+<p>Equivalent to <code>SSLCipherSuite</code>, but for the proxy connection.
+Please refer to <directive module="mod_ssl">SSLCipherSuite</directive>
+for additional information.
+</usage>
+
+</directivesynopsys>
+<directivesynopsis>
+<name>SSLProxyCACertificatePath</name>
+<description>Directory of PEM-encoded CA Certificates for
+Remote Server Auth</description>
+<syntax>SSLProxyCACertificatePath <em>directory-path</em></syntax>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+
+<usage>
+<p>
+This directive sets the directory where you keep the Certificates of
+Certification Authorities (CAs) whose remote servers you deal with. These are used to
+verify the remote server certificate on Remote Server Authentication.</p>
+<p>
+The files in this directory have to be PEM-encoded and are accessed through
+hash filenames. So usually you can't just place the Certificate files
+there: you also have to create symbolic links named
+<em>hash-value</em><code>.N</code>. 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><title>Example</title>
+SSLProxyCACertificatePath /usr/local/apache/conf/ssl.crt/
+</example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSLProxyCACertificateFile</name>
+<description>File of concatenated PEM-encoded CA Certificates
+for Remote Server Auth</description>
+<syntax>SSLProxyCACertificateFile <em>file-path</em></syntax>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+
+<usage>
+<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
+<directive module="mod_ssl">SSLProxyCACertificatePath</directive>.</p>
+<example><title>Example</title>
+SSLProxyCACertificateFile /usr/local/apache/conf/ssl.crt/ca-bundle-remote-server.crt
+</example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSLProxyCARevocationPath</name>
+<description>Directory of PEM-encoded CA CRLs for
+Remote Server Auth</description>
+<syntax>SSLProxyCARevocationPath <em>directory-path</em></syntax>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+
+<usage>
+<p>
+This directive sets the directory where you keep the Certificate Revocation
+Lists (CRL) of Certification Authorities (CAs) whose remote servers you deal with.
+These are used to revoke the remote server certificate on Remote Server Authentication.</p>
+<p>
+The files in this directory have to be PEM-encoded and are accessed through
+hash filenames. So usually you have not only to place the CRL files there.
+Additionally you have to create symbolic links named
+<em>hash-value</em><code>.rN</code>. And you should always make sure this directory
+contains the appropriate symbolic links. Use the <code>Makefile</code> which
+comes with <module>mod_ssl</module> to accomplish this task.</p>
+<example><title>Example</title>
+SSLProxyCARevocationPath /usr/local/apache/conf/ssl.crl/
+</example>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>SSLProxyCARevocationFile</name>
+<description>File of concatenated PEM-encoded CA CRLs for
+Remote Server Auth</description>
+<syntax>SSLProxyCARevocationFile <em>file-path</em></syntax>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+
+<usage>
+<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>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 CRL files, in order of preference. This can be
+used alternatively and/or additionally to <directive
+module="mod_ssl">SSLProxyCARevocationPath</directive>.</p>
+<example><title>Example</title>
+SSLProxyCARevocationFile /usr/local/apache/conf/ssl.crl/ca-bundle-remote-server.crl
+</example>
+</usage>
+</directivesynopsis>
+
+
+
</modulesynopsis>