Why doesnt account response have orders url

Issuance Tech
#1

rfc8555 states orders url is required in account object. i did not see it in the response from
my new-acct request. am i missing something.

1 Like
#2

Where does it state that? I can't find it in the section about accounts (7.3).

2 Likes
#3

This is one of the documented divergences from the spec:

Boulder does not supply the orders field on account objects. We intend to support this non-essential feature in the future. Please follow Boulder Issue #3335.

6 Likes
#4

It is stated in section 7.1.2:

 orders (required, string):  A URL from which a list of orders
      submitted by this account can be fetched [...]

Going by spec it really is a requirement, but LE has never bothered enough to implement it. Maybe some day.

3 Likes
#5

Just adding to this comment: LetsEncrypt does not fully implement the ACME RFC. The divergences are a mix of slightly intentional changes, and developing essential features first while roadmapping the rest. There is also an Implementation Details page, that shows the decisions LetsEncrypt made when the RFC gave some flexibility.

Support for AcmeOrders is been roadmapped since 2018 in ACMEv2: "orders" field missing in account info · Issue #3335 · letsencrypt/boulder · GitHub , but I doubt it will be happening until there is a new RFC or it's implementation will be divergent from the spec. Why? Implementing the endpoint itself isn't a lot of work - IIRC a few people have offered patches. As a community member and not speaking on behalf of the LE Staff, which I have no optics into, but having been involved in similar projects before the big issue I foresee would be implementing this endpoint in a performant manner over the massive (and sharded) dataset that LetsEncrypt has. The database queries would need to be made in a manner that is not only somewhat responsive to users accessing this endpoint, but also not bring down the performance of the entire service when in use. LetsEncrypt has at least 3 main datasets by usage: Account Info, Live Data (current certs, auths, challenges), and Archives (expired data). To my knowledge, no public endpoints query the old data yet.

4 Likes
#6

To be fair, no other free ACME CA currently implements it either. There are some who provide a URL in that orders field. But none of them actually return a usable result if you query it.

4 Likes
#7

The best-laid schemes of mice and men
Go oft awry...

1 Like
#8

thanks all for the responses - i had guessed it might be a performance hit consideration. the documents you all have linked are a great help. i am new to acme so i assume i will stumble often and probably bug you all again in the near future :smiley:

1 Like
#9

interesting to know, thanks for that tidbit. i have just started trying to write acme clients so now i will not be as confused when i run into 'divergences' :slight_smile: i always assume i am doing something wrong first :stuck_out_tongue:

#10

Yeah, writing a client against a specification is always full of pitfalls in terms of how various server implementations interpret the spec. You will inevitably run into things like this where you have to decide how strict you want to be versus retaining compatibility with popular implementations.

I should also note that if you do want to test against a server implementation that implements the orders field, Pebble is one such implementation that you can run locally without much effort. Not only does it implement the orders field, you can configure how many orders per page it will return so you can more easily test your clients ability to properly get paged results.

6 Likes
#11

oh another good to know :slight_smile: thanks.

2 Likes