Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ACMEv2: "orders" field missing in account info #3335

Open
joernheissler opened this issue Jan 7, 2018 · 9 comments
Open

ACMEv2: "orders" field missing in account info #3335

joernheissler opened this issue Jan 7, 2018 · 9 comments

Comments

@joernheissler
Copy link

@joernheissler joernheissler commented Jan 7, 2018

When I POST an empty update to my account URL I get this:

{
    "id": 5337306,
    "key": {
        "kty": "RSA",
        "n": "<redacted>",
        "e": "AQAB"
    },
    "contact": [
        "mailto:<redacted>"
    ],
    "agreement": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "initialIp": "<redacted>",
    "createdAt": "2018-01-05T01:29:21Z",
    "status": "valid"
}

There is no orders field as required by https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.1.2

@cpu
Copy link
Contributor

@cpu cpu commented Jan 8, 2018

We should implement this field - @jsha @rolandshoemaker I remember the question of pagination/truncation of the "orders" field came up before w.r.t this spec feature. What are your thoughts about that here? Should we expect to return all orders? all unexpired orders? The first n unexpired orders?
I was remembering a point in the spec where the orders field was itself an array of URLs instead of a URL from which one can retrieve URLs.

@buschtoens
Copy link

@buschtoens buschtoens commented Jan 29, 2018

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2

orders (required, string): A URL from which a list of orders
submitted by this account can be fetched via a GET request, as
described in Section 7.1.2.1.

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2.1

Each account object includes an "orders" URL from which a list of
orders created by the account can be fetched via GET request. The
result of the GET request MUST be a JSON object whose "orders" field
is an array of URLs, each identifying an order belonging to the
account. The server SHOULD include pending orders, and SHOULD NOT
include orders that are invalid in the array of URLs. The server MAY
return an incomplete list, along with a Link header with a "next"
link relation indicating where further entries can be acquired.

  HTTP/1.1 200 OK
  Content-Type: application/json
  Link: <https://example.com/acme/acct/1/orders?cursor=2>, rel="next"

  {
    "orders": [
      "https://example.com/acme/acct/1/order/1",
      "https://example.com/acme/acct/1/order/2",
      /* 47 more URLs not shown for example brevity */
      "https://example.com/acme/acct/1/order/50"
    ]
  }
@buschtoens
Copy link

@buschtoens buschtoens commented Feb 28, 2018

Considering that ACME v2 was scheduled to go live yesterday, is there currently a way to retrieve a list of pending orders?

I'm sure you're busy with getting boulder ready, in order to ship ACME v2 for Let's Encrypt, so please don't feel pressured. I just happened to trip over this again.

@cpu
Copy link
Contributor

@cpu cpu commented Feb 28, 2018

@buschtoens We still have not implemented the "orders" field on account objects and we're not considering this a required feature for the V2 launch. I expect it will be a little bit after the launch before we implement it. I recommend that your client maintain the IDs of orders it creates with the newOrder endpoint in the meantime.

The best way to watch for progress is to keep an eye on this issue, particularly when it gets assigned to a milestone for a sprint. Thanks for your patience!

@cpu cpu added this to Backlog in v2 API Mar 2, 2018
@bkromhout
Copy link

@bkromhout bkromhout commented Aug 13, 2018

@cpu, can we expect to see any movement on this anytime soon? The ACME spec draft appears to be quite close to its final form, pending the whole process of making it an actual RFC. While I agree the "orders" field is a convenience, it is still a required part of the spec, yet this has been sitting idle for months now.

@cpu
Copy link
Contributor

@cpu cpu commented Aug 20, 2018

@cpu, can we expect to see any movement on this anytime soon?

Unlikely. It's a non-trivial amount of work for a convenience and there is still substantial higher priority work to be done in other areas.

this has been sitting idle for months now.

@bkromhout PRs are welcome.

@mschristiansen
Copy link

@mschristiansen mschristiansen commented Dec 25, 2018

Is there no alternative to tracking the order ids client side currently?

@jsha
Copy link
Contributor

@jsha jsha commented Jan 2, 2019

That's correct.

breard-r added a commit to breard-r/acmed that referenced this issue Sep 26, 2020
RFC 8555 states that:
 - when an account is successfully created, the server "returns this
   account object" (section 7.3);
 - the `orders` field in account objects is mandatory (section 7.1.2).

Despite that, Boulder does not returns the `orders` field when an
account is created. This non-standard behavior prevented ACMEd from
creating account and testing them for existence.

In order to allow ACMEd to retrieve certificates from CAs using Boulder,
the `orders` field is no longer mandatory and the account existence is
tested when the order is requested.
letsencrypt/boulder#3335
@colintoal
Copy link

@colintoal colintoal commented Mar 24, 2021

It'd be swell if Boulder supported this. Pebble does. I've implemented a client to spec, and this is the last step I need to work around. I'm happy to help if I can.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
v2 API
Backlog
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants