On 03.10.2015 12:07, Reindl Harald wrote: > Am 03.10.2015 um 11:16 schrieb Kaspar Brand: >> What do you have security.OCSP.require set to? If it's "true" (a setting >> no longer configurable through the UI, BTW, see >> https://bugzilla.mozilla.org/show_bug.cgi?id=1034360), then Firefox >> shows a fairly peculiar behavior: even when OCSP checking is disabled >> (by setting security.OCSP.enabled to "0", through the "Query OCSP >> responder servers to confirm the current validity of certificates" >> preference in the UI under Advanced -> Certificates), it still includes >> a status_request extension in the TLS handshake, and will subsequently >> fail when it receives a stapled tryLater OCSP response, as long as >> security.OCSP.require=true > > security.OCSP.require=false is the default
Oh, looks like Firefox does sort of a "hard fail" when receiving a stapled tryLater response - not what I would expect when security.OCSP.require=false (and also security.OCSP.enabled=0), but apparently, the security.ssl.enable_ocsp_stapling pref has precedence over those. As far as the mod_ssl side is related, it seems to me that for the "SSLStaplingReturnResponderErrors off" case, we should make sure that we only staple responses with status "good" (i.e. OCSP_RESPONSE_STATUS_SUCCESSFUL and V_OCSP_CERTSTATUS_GOOD for the cert). > but it's not only my client with random failed connections This is really due to a very weird effect with ocsp.godaddy.com, as further examination shows. GoDaddy is making use of Akamai's Global Traffic Management service for "load balancing", i.e., depending on where the client is located, you're getting one of the following addresses back when querying for ocsp.godaddy.com.akadns.net (the CNAME for ocsp.godaddy.com): 72.167.18.239 50.63.243.230 72.167.239.239 188.121.36.239 (the list might be incomplete, but it illustrates Akamai's GTM mechanism) For Central Europe, you get back 188.121.36.239 (from GoDaddy's Amsterdam data center), and from what I can tell, this site has a pretty quirky behavior when handling new connections on port 80: the first connection is instantaneously torn down with a TCP reset... but if you immediately try again, the OCSP request is properly handled (for your *.thelounge.net cert e.g., try [1]). Then, after some idle timeout, the same effect kicks in again. I haven't been able to determine how long the timeout is exactly, but judging from your log extracts, it seems to be less than 30 minutes). Strangely enough, the other (US-based) sites don't seem to exhibit this effect. Kaspar [1] http://188.121.36.239/MEgwRjBEMEIwQDAJBgUrDgMCGgUABBS2CA1fbGt26xPkOKX4ZguoUjM0TgQUQMK9J47MNIMwojPX+2yz8LQsgM4CByr+BC4coss=
