Hi Ben, I think the SERPRO OCSP responder has two issues at play:
1. When I send a GET request containing a valid OCSP request whose base64-encoding consists solely of alphanumeric characters (“http://ocsp.serpro.gov.br/acserprosslv1/MEwwSjBEMEIwPDAJBgUrDgMCGgUABBRCALQ8KegpMz1OADFGgCAaOp1VVAQUQgC0PCnoKTM9TgAxRoAgGjqdVVQCAwCAAqACMACiAjAA”), I get a HTTP 500 with the response body containing an “internalError” OCSP response. Given the different status code (500 vs. 404) for different GET requests, the server possibly isn’t handling the percent-encoded slash in your request correctly. 2. Even when a request is sent in a manner that doesn’t return an HTTP 404 (using HTTP POST or GET with all alphanumeric characters), the server still returns an HTTP 500 and “internalError” OCSP response. Thanks, Corey From: Ben Wilson <[email protected]> Sent: Friday, October 8, 2021 5:38 PM To: Jacob Hoffman-Andrews <[email protected]> Cc: Corey Bonnell <[email protected]>; [email protected] Subject: Re: OCSP responder behavior for HTTP GET requests Could this possibly be the same as the problem I'm encountering with OCSP response for the SERPRO test site (OCSP response not found) when I run this command? curl --verbose --url http://ocsp.serpro.gov.br/acserprosslv1/ME4wTDBKMEgwRjAJBgUrDgMCGgUABBTBQ28pKtiXfAbGW%2BhUsNmqSdcYRQQUrRZPS%2FEMvsKKooUY1w1GJZMi480CDQDzmwGvO97JMnso57k%3D (Using instructions from https://unmitigatedrisk.com/?p=42) See also https://certificate.revocationcheck.com/active-repositorio.serpro.gov.br Thanks, Ben On Thu, Oct 7, 2021 at 6:42 PM 'Jacob Hoffman-Andrews' via [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > wrote: Good advice, thanks for sharing! People interested in this may also be interested in reading Let's Encrypt's 2017 postmortem related to the same issue: https://community.letsencrypt.org/t/may-19-2017-ocsp-and-issuance-outage-postmortem/34922. Another interesting thing: concatenation happens without regard to whether the OCSP URL in a certificate has a trailing slash. If you issue certificates where the OCSP URL ends in a trailing slash (rare, I think), you'll find that all of your OCSP GET requests start with a doubled slash (//). Also, it's worth being cautious about deploying changes that will cause large numbers of cache entries to be invalidated. -- You received this message because you are subscribed to the Google Groups "[email protected] <mailto:[email protected]> " group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAN3x4QmJ4_ZEOOq%3DPgLv45NLD1afcqWeKd0M8PR%2B%3D%3DdShh%2BbZA%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAN3x4QmJ4_ZEOOq%3DPgLv45NLD1afcqWeKd0M8PR%2B%3D%3DdShh%2BbZA%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186888BB2DBAE58A051191192B59%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
