Is the "Location" header of an new order the order's url in Boulder/LetsEncrypt?

Client dev
1

In the RFC 7.4. Applying for Certificate Issuance RFC 8555 - Automatic Certificate Management Environment (ACME) a "Location" header related to the order appears several times:

after 'new order' page 46: RFC 8555 - Automatic Certificate Management Environment (ACME)

HTTP/1.1 201 Created
Replay-Nonce: MYAuvOpaoIiywTezizk5vw
Link: https://example.com/acme/directory;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo

After finalize, page 49: RFC 8555 - Automatic Certificate Management Environment (ACME)

HTTP/1.1 200 OK
Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X
Link: https://example.com/acme/directory;rel="index"
Location: https://example.com/acme/order/TOlocE8rfgo

The RFC is very explicit about the Location field when it refers to new accounts. Page 36 highlights:

The server returns
this account object in a 201 (Created) response, with the account URL
in a Location header field.

and:

If the server receives a newAccount request signed with a key for
which it already has an account registered with the provided account
key, then it MUST return a response with status code 200 (OK) and
provide the URL of that account in the Location header field.

This also comes up with pre-authorizations.

The RFC is less explicit about this when it comes to orders.

On page 22 (RFC 8555 - Automatic Certificate Management Environment (ACME)) there is the following text:

The "->" is a mnemonic for a Location
header field pointing to a created resource

and this appears on the table:

| Submit order | POST newOrder | 201 -> order |

However, this table illustrates a "typical sequence of events", and not any sort of requirement.

So, this is more of LetsEncrypt question for me:

  1. is the "Location" header of an new order the order's url in Boulder/LetsEncrypt?
  2. can we rely on this?

It seems to do this, and the RFC suggests this is intended, but there is nothing definitive that I can find.

Thanks!

2 Likes
2

I do not think you have any other choice than relying on that Location header field. At least, I did not found any other way reading the RFC (except the list of orders from the account object, but it is implemented only in the pebble, but not in the boulder). The URL of the order object is needed to poll its status after you fired the finalize URL, from the text: “The client should then send a POST-as-GET request to the order resource to obtain its current state.”

1 Like
3

I haven’t seen anything else either, and all the clients I’ve seen use this… but there isn’t anything in the spec that declares this as the definitive source of the resource url… nor could I find the spec referring to another rfc that states a location header should be the definitive resource url. So this is obvious, but not explicit… and this rfc tends to be explicit.

1 Like
4
  1. yes
  2. yes

There's no other way to learn an Order URL in RFC 8555 AFAIK. You POST newOrder and get back a response with a Location header that communicates the order's URL for subsequent operations.

3 Likes
5

:thinking: I suppose you could ignore the Location header and spelunk the orders list per RFC 8555 - Automatic Certificate Management Environment (ACME), trying to match a order URL to the identifiers you used. It would be obtuse though (and won't work with Boulder)!

3 Likes
6

It seems like an accidental deficiency in the spec, to not have a line like "The Order URL shall appear in the Location header". Every other object URL I searched for was explicitly defined with something like that.

7

I agree it would be clearer if the spec said something like that.

8

After a bit of reflection, I decided to submit an errata report for the RFC.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.