In the new Certificate the OCSP URI is defined as http://r3.o.lencr.org but most time this url send an HTTP-400 back. I found that if i use http://r3.o.lencr.org/ocsp it works fine. Is this an intended behavior? Because in the rfc i did not find the hint hat the uri from the certificate is missing …

Those packet captures show that you putting the absolute Request-URI (including scheme, host, path) into the HTTP request line. In effect, you are requesting http://r3.o.lencr.orghttp://r3.o.lencr.org/ocsp (depending on how the Akamai servers chooses the interpret it, I guess?). This is not correc…

:wave: Hi @tlussnig . HTTP 400s ( a.k.a. "Bad Request" ) are NOT intended behavior for our ocsp responder URI's - which makes me wonder, what sort of requests are you sending? The URI " http://r3.o.lencr.org/ocsp " should not actually be a functional URI - as far as I know, that should either return …

I am sending an OCSP Request used for stappling. And witth "works fine" i mean is receive from the path /ocsp with an post the expected OCSP-Response. It can be parsed and have an valid date. I can prepare an simple java Example or event an CURL example.

Hi make an wireshark screenshot of the result with both url's. [image] [image]

Should the Expires and Cache-Control: max-age not around the same time that the response is valid. The response is valid for 4 days but the http response should only be cached for 12 hours ?

Those headers are correct. Even if an OCSP response is valid for 4 days, we are required to have updated responses available before that point.

That is clear, for this reason i wrote aroung the same and not same time. I had expected 4-8 hours as timeout before the response become invalid. Not 12 Hours if the response is valid for 96 hours. I would send max-age 88 or 92 hours.

Each root program has different requirements for when the next response should be available, 12 hours is our current balance/trade-off. It may change, and if it does, it will need to continue to take different timeline requirements into account from the BRs and various root programs. Back to the UR…

Nice observation! Although, I just tried using -url "http://r3.o.lencr.org/http://r3.o.lencr.org/anything-all-garbage" and it still works fine! So, long as the domain is correct, we apparently work very hard to be sure you're going to post to the correct responder :slight_smile:

[image] ezekiel: Although, I just tried using -url "http://r3.o.lencr.org/http://r3.o.lencr.org/anything-all-garbage" and it still works fine! It seems there is a slight subtlety here with the leading slash in the Request-URI path. OP's pcaps don't have a leading /. If you use -path http://…

Ahh, nice! Thank you @_az ! So now I can reproduce with openssl, but it's difficult to get the curl command-line to act incorrectly in that way. @tlussnig , the above definitely looks to be your problem. Ensure your library is POST-ing to " http://r3.o.lencr.org " or even " http://r3.o.lencr.org/ " - but…

OCSP-URI r3.o.lencr.org

Client dev

ezekiel February 23, 2021, 4:47pm 19

Here's an interesting piece of our history regarding exactly this slash: May 19, 2017: OCSP and Issuance Outage Postmortem

Topic		Replies	Views
Issue with OCSP GET request Help	8	1911	July 4, 2021
2019.08.20 Incorrect OCSP responses under certain conditions Incidents	0	1393	August 27, 2019
[Solved] Cannot verify ocsp Server	2	11727	November 8, 2015
Unauthorized trying to fetch OCSP response Help	18	2814	July 6, 2018
OCSP on ocsp.staging-x1.letsencrypt.org broken? Issuance Tech	3	2573	March 12, 2016

OCSP-URI r3.o.lencr.org

Related topics