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
