Didn't see a reply to this. Can somebody review and commit? Thanks
Daniel ----- Forwarded message from Daniel Lopez <[EMAIL PROTECTED]> ----- Date: Wed, 24 Jul 2002 16:37:05 -0700 From: Daniel Lopez <[EMAIL PROTECTED]> To: docs@httpd.apache.org Subject: [PATCH] SSLPRoroxy* directives User-Agent: Mutt/1.3.28i Hi, I attach a patch that covers SSLProxy* directives that exist in mod_ssl for Apache 2 but that are not documented anywhere. It would be nice to add some more docs to ProxyPass, etc. to indicate that you can do ProxyPasss / https://secure.host.com/ but I do not have the energy right now :) Best regards Daniel -- Teach Yourself Apache 2 -- http://apacheworld.org/ty24/ ? patch Index: mod_proxy.xml =================================================================== RCS file: /home/cvspublic/httpd-2.0/docs/manual/mod/mod_proxy.xml,v retrieving revision 1.7 diff -u -r1.7 mod_proxy.xml --- mod_proxy.xml 7 Jun 2002 02:20:53 -0000 1.7 +++ mod_proxy.xml 24 Jul 2002 23:40:13 -0000 @@ -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 Index: mod_ssl.xml =================================================================== RCS file: /home/cvspublic/httpd-2.0/docs/manual/mod/mod_ssl.xml,v retrieving revision 1.4 diff -u -r1.4 mod_ssl.xml --- mod_ssl.xml 23 May 2002 14:50:11 -0000 1.4 +++ mod_ssl.xml 24 Jul 2002 23:40:19 -0000 @@ -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> ----- End forwarded message ----- -- Teach Yourself Apache 2 -- http://apacheworld.org/ty24/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
