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 path information.
3 Likes
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 a 404, or maybe "unauthorized". When you say "it works fine", does that mean you're able to POST to this URI and retrieve valid OCSP responses?
3 Likes
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.
2 Likes
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 ?
2 Likes
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.
3 Likes
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.
2 Likes
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 URI - I can't reproduce this behavior, and apparently Akamai didn't capture anything for that "Reference" number.
If you have OpenSSL and cURL, perhaps you would be willing to check if this reproduces a 400 error?
$ export OCSP_SERIAL="0x123456789" # replace AFTER "0x" with your correct serial number
$ openssl ocsp -issuer <( curl -sf http://r3.i.lencr.org | openssl x509 -inform der -outform pem ) -serial "0x${OCSP_SERIAL}" -url "http://r3.o.lencr.org" -reqout "${HOME}/ocsp.request"
$ curl -sf --trace-ascii - --data-binary @"${HOME}/ocsp.request" -X POST "http://r3.o.lencr.org"
I'll private message you if you're more comfortable sending the trace output that way.
4 Likes
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 correct. You should only be putting the path into the request line. i.e. /ocsp and /, respectively.
Edit: I wonder if you have your Java HTTP library in some kind of proxy mode? Absolute Request-URIs are valid for proxies ... and there is also a suspicious Proxy-Connection request header ...
3 Likes
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 
4 Likes
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://ocsp.int-x3.letsencrypt.org/, the request succeeds. (and tacking anything on after the final slash works as well, such as in the /ocsp pcap).
If you use -path http://ocsp.int-x3.letsencrypt.org, which I think is identical to the failing pcap, the request hits an HTTP 400 from Akamai.
4 Likes
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 NOT "http://r3.o.lencr.orghttp://r3.o.lencr.org......" ( as your client is currently doing ).
4 Likes
Hi,
there is no POST to " "http://r3.o.lencr.orghttp://r3.o.lencr.org..." the above is an valid form.
And i can confirm that the url with / is also working. And i checked the certificate. There the URI for the OCSP response is without / and the URI for CA-Issuer is with / . Maybe the OCSP-URI in the certificate should include the / ?
2 Likes
I found the relevant part in the RFC 2616
3.2.2 http URL
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2)
So the error is in my implementation.
2 Likes
I don't believe so. The combination of the Host header and Request-URI produces http://r3.o.lencr.orghttp://r3.o.lencr.org on the origin server.
If you look at RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1, it says:
The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send
the lines:GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.orgfollowed by the remainder of the Request. Note that the absolute path
cannot be empty; if none is present in the original URI, it MUST be
given as "/" (the server root).
You are sending the absoluteURI form of the Request-URI rather than the abs_path form, which is not appropriate in this request context.
2 Likes
In the same point there is also mentioned before that absoluteURI's are allowed. And it is not forbidden to be used together with the host header. So my fault was the i take the URI from the certificate as absolute instead of not absolute that require an added /
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.
3 Likes
Huh, that's interesting. I didn't see that part of the document. In my testing, some servers canonicalize the request path and others don't. That could produce some interesting results!
Good job on narrowing it down to the trailing slash anyhow!
2 Likes
Question: Should the certificate contain absoluteURI or not ?
2 Likes
Here's an interesting piece of our history regarding exactly this slash: May 19, 2017: OCSP and Issuance Outage Postmortem
6 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.