> -----Ursprüngliche Nachricht----- > Von: Reindl Harald [mailto:[email protected]] > Gesendet: Donnerstag, 1. Oktober 2015 13:38 > An: [email protected] > Betreff: Re: SSLUseStapling: ssl handshake fails until httpd restart > > > > Am 30.09.2015 um 08:42 schrieb Kaspar Brand: > > On 29.09.2015 18:24, Reindl Harald wrote: > >> i just restarted the servers and disabled stapling since all our > >> servcies where unreachable (before i write the second mail 5 > different > >> hosts with several sites where affected) > >> > >> in fact the error caching does more harm than benefits - IHMO a > better > >> "could not reach OCSP server or received a error from it" caching > would > >> be just temporary disable stapling for 10 minutes instead lead in > >> connections fail even from clients which have disabled OCSP completly > >> > >>>> firefox refused to open our adminpanel with the error below until i > >>>> restarted httpd > > > > The default for SSLStaplingReturnResponderErrors is relatively odd. > > Not sure why it has always defaulted to "on" (r829619), but setting it > > to off should save you further troubles with Firefox clients. > > not really, i had the error message just now again in FF, the difference > was that now a "try again" loaded the page but with > "SSLStaplingReturnResponderErrors" i would expect it invisible to > clients in general - GoDaddy seems to have massive problems with their > responders the last days and the defaults with stapling enabled make > them to a perfect DOS target > > [Thu Oct 01 13:33:01.179365 2015] [ssl:error] [pid 19312] [client > 10.0.0.99:37860] AH01980: bad response from OCSP server: (none) > [Thu Oct 01 13:33:01.179393 2015] [ssl:error] [pid 19312] AH01941: > stapling_renew_response: responder error > > SSLStaplingCache shmcb:/var/cache/mod_ssl/ocsp_cache(1048576) > SSLStaplingStandardCacheTimeout 86400 > SSLStaplingErrorCacheTimeout 300 > SSLStaplingReturnResponderErrors Off
What happens if you set SSLStaplingFakeTryLater off in addition? Regards Rüdiger
