> Am 18.01.2018 um 20:10 schrieb Johannes Bauer :
>
> Hi Stefan,
>
> On 18.01.2018 10:00, Stefan Eissing wrote:
>> Yes, this is definitely an area where the server can and should be
>> improved. Marat already provided the link to the article discussing
>> this last year and the situation is un
Hi Stefan,
On 18.01.2018 10:00, Stefan Eissing wrote:
> Yes, this is definitely an area where the server can and should be
> improved. Marat already provided the link to the article discussing
> this last year and the situation is unchanged, unfortunately. Not for
> lack of recognition of the pro
Hi Marat,
On 18.01.2018 08:37, Marat Khalili wrote:
> Did you read
> https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html
> ? Judging by https://bz.apache.org/bugzilla/show_bug.cgi?id=57121 it is
> still unfixed, I
Yes, this is definitely an area where the server can and should be
improved. Marat already provided the link to the article discussing
this last year and the situation is unchanged, unfortunately. Not for
lack of recognition of the problem, but more a lack of time and
effort, I think.
What I do o
Hello,
I.e., the following: Only ever do valid tickets end up in the cache.
After a period that is *shorter* than the ticket lifetime (one day in my
example), Apache tries to refresh the ticket. If a valid ticket is
returned by the responder, that ticket replaces the currently cached one
and is
Hi Apache users,
I've configured OCSP stapling and use certificates that use the
OCSP-must-staple X.509 extension. I *must* use stapling. My CA
LetsEncrypt has fairly long OCSP ticket lifetimes (7 days), but their
OCSP responder can be flaky at times.
This means that I've now had outages a couple
