https://bz.apache.org/bugzilla/show_bug.cgi?id=64306
--- Comment #2 from [email protected] <[email protected]> --- First note that in the apache2 logs, I could see another OCSP error (tough I did not have the chance to see it on the client side): [Sun Mar 29 04:03:05.876938 2020] [ssl:error] [pid 3644:tid 140478943012608] (70007)The timeout specified has expired: [client 66.249.79.246:37979] AH01977: failed reading line from OCSP server [Sun Mar 29 04:03:05.877734 2020] [ssl:error] [pid 3644:tid 140478943012608] [client 66.249.79.246:37979] AH01980: bad response from OCSP server: (none) [Sun Mar 29 04:03:05.877867 2020] [ssl:error] [pid 3644:tid 140478943012608] AH01941: stapling_renew_response: responder error In the ocsp_proxy logs, the cache was refreshed less than 1 hour ago: Mar 29 03:11:49 joooj ocsp_proxy[7642]: [info] refreshing ocspxy_b390a7d8c9af4ecd613c9f7cad5d7f41fd6930ea0x4aa43b32a0f5e7b491c2881d02818ca5 Mar 29 04:02:57 joooj ocsp_proxy[7642]: [info] connection from ::1:57056 and it was not refreshed again until Mar 30 03:12:25, which follows the ocsp_proxy documentation: "OCSP responses are stored in a redis db and are refreshed on daily basis, or hourly if the validity period is at half-time." (In reply to gmoniker from comment #1) > At the face of it, this would be an error on the part of the OCSP proxy. In > all likelihood it didn't respond timely to the OCSP query from Apache. I would have said that the code of the OCSP proxy is simple enough so that it should not have any issue. > Apache reads the OCSP proxy answer in HTTP 1.0 fashion. So, if the OCSP > proxy returns the answer, but doesn't cut the connection immediately at the > end of it, there is a risk of Apache not receiving it before the timeout, > even if it is in fact completely sent. The code of the proxy is of the form: while (my $c = $daemon->accept) { info("connection from %s:%d", $c->peerhost, $c->peerport); REQ: while (my $r = $c->get_request) { [...] $c->send_response($client_res); } debug("disconnecting %s:%d", $c->peerhost, $c->peerport); $c->close; This means that the OCSP proxy disconnects immediately, unless for some reason Apache sends another request. I could enable debug messages to have more information of what really happens. > It may also be that the OCSP proxy > couldn't get a response from the origin OCSP responder itself and didn't > have anything cached. It appears from its source code that ocsp_proxy does not log anything in this case by default (only with debug messages), unless an error occurred. But it is very unlikely that this occurred since on March 29, the request by Apache was done less than 1 hour after the refresh. Moreover, on April 4, I had restarted the apache2 service after the issue in order to clear the error, and I had checked with: $ openssl s_client -connect vinc17.net:443 -status CONNECTED(00000003) depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority verify return:1 depth=1 C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2 verify return:1 depth=0 CN = vinc17.net verify return:1 OCSP response: ====================================== OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: B390A7D8C9AF4ECD613C9F7CAD5D7F41FD6930EA Produced At: Apr 3 00:49:21 2020 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: A5E2344EF5763A9CE2F31E9B9807B0075727A5F9 Issuer Key Hash: B390A7D8C9AF4ECD613C9F7CAD5D7F41FD6930EA Serial Number: 4AA43B32A0F5E7B491C2881D02818CA5 Cert Status: good This Update: Apr 3 00:49:21 2020 GMT Next Update: Apr 10 00:49:21 2020 GMT [...] Since there was a refresh at Apr 03 03:15:08 CEST (i.e. UTC+2), this would also mean that the cache did not need an update. > The second, but unlikely, thing is that a client may be sending unsupported > stapling extensions in its own request. Apache passes through the stapling > request extensions it receives from the client, as is required by OCSP > stapling RFC. It may just so happen that a client that triggers the OCSP > renewal in Apache sent an extension that the proxy you uses gets stuck with. > But again this seems unlikely. This does not seem to be the case with ocsp_proxy. Well, the only thing that matters to send its response is the cache key, which seems to depend only on issuerKeyHash and serialNumber. Anyway, according to the ocsp_proxy logs, only one cache key is refreshed (on a daily basis). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
