merge r1635510 from trunk:

more hints for OCSP Stapling:

* when a different cache mechanism is used...
* testing that your server sends an OCSP response

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1635512 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/docs/manual/ssl/ssl_howto.xml b/docs/manual/ssl/ssl_howto.xml
index 7d11ac3bf964a9b8bc3738e05e6435b3355f1174..5c580aa84d31b1b9d51b1b41c96ec952d988e616 100644 (file)
--- a/docs/manual/ssl/ssl_howto.xml
+++ b/docs/manual/ssl/ssl_howto.xml
@@ -150,6 +150,33 @@ for the Ubuntu or Debian-bundled httpd, etc.</p>
 <directive>SSLSessionCache</directive> directive.  This path is relative
 to <directive>ServerRoot</directive>.</p>
 
+<p>This particular <directive>SSLStaplingCache</directive> directive requires
+<module>mod_socache_shmcb</module> (from the <code>shmcb</code> prefix on the
+directive's argument).  This module is usually enabled already for
+<directive>SSLSessionCache</directive> or on behalf of some module other than
+<module>mod_ssl</module>.  If you enabled an SSL session cache using a 
+mechanism other than <module>mod_socache_shmcb</module>, use that alternative
+mechanism for <directive>SSLStaplingCache</directive> as well.  For example:</p>
+
+    <highlight language="config">
+SSLSessionCache "dbm:logs/ssl_scache"
+SSLStaplingCache "dbm:logs/ssl_stapling"
+    </highlight>
+
+<p>You can use the openssl command-line program to verify that an OCSP response
+is sent by your server:</p>
+
+<pre>
+$ openssl s_client -connect www.example.com:443 -status -servername www.example.com
+...
+OCSP response: 
+======================================
+OCSP Response Data:
+    OCSP Response Status: successful (0x0)
+    Response Type: Basic OCSP Response
+...
+</pre>
+
 <p>The following sections highlight the most common situations which require
 further modification to the configuration.  Refer also to the 
 <module>mod_ssl</module> reference manual.</p>