Thanks, Erwan for the details, that will help us a lot to fix this issue. We put hands on!
El jueves, 10 de octubre de 2013 17:31:03 UTC+2, Erwann Abalea escribió: > Bonjour, > > > > Le mardi 1 octobre 2013 11:20:10 UTC+2, Chema Lopez a écrit : > > > El jueves, 26 de septiembre de 2013 17:10:36 UTC+2, Erwann Abalea escribió: > > > > Bonjour, > > > > > > > > Le mercredi 25 septembre 2013 10:37:10 UTC+2, Chema Lopez a écrit : > > > > > > > > > Dear all, we are proud to announce that we have solved the issues > > > > detected by Erwann Abalea. > > > > > > > > > > Is it possible to continue with the process, now? Remember, test URL is: > > > > > https://publifirma.firmaprofesional.com/ > > > > > > > > The OCSP responder certificate has the "OCSPNoCheck" extension. > > > > > > > > But the OCSP service is still unavailable for GET requests. There's no > > > more recursive 302 redirections, but the service isn't available. > > > > > > > > Therefore, your OCSP service isn't BR compliant. > > > > > > Dear all, > > > > > > We have fixed the issues kindly reported by Erwann Abalea. > > > > Still no. > > > > Look at RFC2560/6960 section A.1, describing the format of a request sent > over HTTP: > > > > An OCSP request using the GET method is constructed as follows: > > > > GET {url}/{url-encoding of base-64 encoding of the DER encoding of > > the OCSPRequest} > > > > That is, some characters from the base64 representation of the request are > transformed: > > / is transformed into %2F > > + is transformed into %2B > > = is transformed into %3D > > and your OCSP responder is supposed to reverse that transformation (only > once), then base-64 decode the string, and continue with the process (OCSP > request parsing, etc). > > > > Your OCSP service don't show any problem when + and = are URL-encoded, but > when a / is URL-encoded, an HTTP 404 error is returned. > > > > If you want to see it in practice under a different browser (IE, for > example), clear the OCSP+CRL cache, capture network trafic going from your > desktop to {ocsp,crl,crl2}.firmaprofesional.com and tcp port 80, and try to > connect to the test site (publifirma). The browser/OS will first request an > OCSP token with a GET request (URL-encoded), receive a 404 error, and > fallback to CRL download, thus hiding the malfunction of the OCSP responder. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
