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 on my servers (beside what you already wrote) is
SSLStaplingCache dbm:ocsp-stapling
use a permanent cache, so a restart of the server does not require
it to refetch all responses.
-Stefan
> Am 17.01.2018 um 20:21 schrieb Johannes Bauer <dfnsonfsduifb@xxxxxx>:
>
> 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 of times where a "retry
> later" response was cached by Apache, forwarded to clients, effectively
> grinding everything to a halt. After RTFMing a bit, I've modified my
> configuration so this cannot happen again:
>
> SSLUseStapling on
> SSLStaplingCache shmcb:/var/run/apache2/ssl_stapling(262144)
>
> SSLStaplingErrorCacheTimeout 30
> SSLStaplingStandardCacheTimeout 8640000
> SSLStaplingReturnResponderErrors off
>
> However, I'm not sure this is what I want. Here's describing the
> algorithm I actually want, in pseudocode:
>
> cached_ticket = get_cache()
> if (cached_ticket.expired()) {
> remove_cache(cached_ticket)
> cached_ticket = null;
> }
>
> try_for_new_ticket = !cached_ticket || (cached_ticket.age() > 86400)
> if (try_for_new_ticket) {
> new_ticket = ask_ocsp_responer()
> if (new_ticket) {
> put_cache(new_ticket);
> cached_ticket = new_ticket;
> }
> }
>
> return cached_ticket
>
>
> 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 returned. If an invalid ticket ("try again" or timeout) is
> returned by the responder, the valid cached ticket is returned.
>
> That way, any outage need to be be longer than 6 days for the outage to
> actually affect my clients.
>
> I do not see how I can configure this in Apaches variables and the only
> other posting I have found regarding this topic is
> https://lists.gt.net/apache/users/437736 which received zero responses.
>
> Can someone please clarify how to set up this properly so that a
> scenario is resulted as I describe it (i.e, try renewal already much
> before the ticket is expired)?
>
> Thank you in advance,
> Johannes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|