IMO the present concerns with OCSP Stapling are: * not so clear that it has seen enough real-world testing; commented out sample configs and better documentation will help, as will enabling by default in trunk (just a little?) * related bugs 57121 and 57131
A simple way to help with the broader issue raised in 57131, as well as fix 57121, is to not hold the global mutex while communicating with a responder, with other handshakes completing with the existing response in the cache as long as it is valid, or with the appropriate communication-error response otherwise (some details omitted ;) ). There are a few other bugs currently open for less severe issues. TIA for your comments! Index: docs/conf/extra/httpd-ssl.conf.in =================================================================== --- docs/conf/extra/httpd-ssl.conf.in (revision 1635504) +++ docs/conf/extra/httpd-ssl.conf.in (working copy) @@ -9,7 +9,7 @@ # consult the online docs. You have been warned. # # Required modules: mod_log_config, mod_setenvif, mod_ssl, -# socache_shmcb_module (for default value of SSLSessionCache) +# socache_shmcb_module (default SSLSessionCache and SSLStaplingCache) # # Pseudo Random Number Generator (PRNG): @@ -81,13 +81,13 @@ # How-To for more information. # # Enable stapling for all SSL-enabled servers: -#SSLUseStapling On +SSLUseStapling On # Define a relatively small cache for OCSP Stapling using # the same mechanism that is used for the SSL session cache # above. If stapling is used with more than a few certificates, # the size may need to be increased. (AH01929 will be logged.) -#SSLStaplingCache "shmcb:ssl_stapling(32768)" +SSLStaplingCache "shmcb:ssl_stapling(32768)" # Seconds before valid OCSP responses are expired from the cache #SSLStaplingStandardCacheTimeout 3600 -- Born in Roswell... married an alien... http://emptyhammock.com/
