trafficserver-users mailing list archives

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

Ah yes; on closer inspection I see that the problem site has stapled an OCSP trylater response.


----- On Jan 23, 2017, at 1:53 PM, Reindl Harald 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 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