Ah yes; on closer inspection I see that the problem site has stapled an OCSP trylater response. Ugh.
--Jered ----- On Jan 23, 2017, at 1:53 PM, Reindl Harald [email protected] wrote: > Am 23.01.2017 um 19:47 schrieb Jered Floyd: >> This is exactly why I'm asking if Stapling should be enabled/default; to >> protect >> against third-party infrastructure leading to downtime. >> >> Today I encountered a site where the OCSP Responder for their CA was >> providing >> sec_error_ocsp_try_server_later and Firefox now defaults to not loading the >> site! Were they OCSP Stapling, they may had still had a valid cached >> response. > > the opposite > > that is mostly caused by stapling while firefox as all major browsers > would have just ignored OCSP when it is down without stapling but the > stapling cached the try-later > > hence the two params in my httpd config and as long nobody confirms that > behavior for ATS i would not enable stapling at all > >> ----- On Jan 23, 2017, at 1:12 PM, Reindl Harald [email protected] >> wrote: >> >>> Am 23.01.2017 um 18:40 schrieb Jered Floyd: >>>> OCSP Stapling is off by default in ATS. >>>> >>>> What risks, if any, are there to enabling it? Given that my issuer >>>> supports OCSP and many browsers support OCSP and OCSP Stapling, it seems >>>> like enabling it is the "safest" option. Is there a reason it is not on >>>> by default? >>> >>> not sure how ATS is handling this, with httpd i had a lot of fun in >>> timeframes where the godaddy responsers where unstable up to not be able >>> to connect to internal admin backends until set the following values in >>> the global configuration >>> >>> SSLStaplingReturnResponderErrors Off > >> SSLStaplingFakeTryLater Off
