trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reindl Harald <>
Subject Re: What dangers (if any) to enabling OCSP Stapling?
Date Mon, 23 Jan 2017 18:53:36 GMT

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 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

View raw message