Closed kuehne-trustable-de closed 4 years ago
I'm not entirely sure what you mean... Dehydrated behaves (at least mostly) RFC8555-conform, so if you want to write a new server-software you should implement it following RFC8555, there are no assumptions in implementation on client- or server-side.
Hi Lukas,
I'm not entirely sure what you mean... Dehydrated behaves (at least mostly) RFC8555-conform, so if you want to write a new server-software you should implement it following RFC8555, there are no assumptions in implementation on client- or server-side.
if I understand your software correctly it takes advantage of an element 'id' in the account data structure
line 404:
ACCOUNT_ID="$(cat "${ACCOUNT_KEY_JSON}" | get_json_int_value id)"
But as far as I can see there is NO element 'id' defined in the spec (Snippet from RFC8555):
{ "status": "valid", "contact": [ "mailto:cert-admin@example.org", "mailto:admin@example.org" ], "termsOfServiceAgreed": true, "orders": "https://example.com/acme/orders/rzGoeA" }
Moreover I would consider it at least dangerous to make assumption about the server's URL structure:
line 408:
ACCOUNT_URL="${CA_ACCOUNT}/${ACCOUNT_ID}"
This will be a valid in many implementations but it is NOT backed by the spec!
BTW::
I'm testing my stuff with your client because colleagues recommended it as 'great stuff' and want to be sure everything's woks out fine, not to spot some minor spec deviations ;-)
Greetings,
Andreas
-- Andreas Kühne
Chair of OASIS DSS-X
phone: +49 177 293 24 97 mailto: kuehne@trustable.de
Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
Director Andreas Kühne
Company UK Company No: 5218868 Registered in England and Wales
I think you are correct, this seems to be something dehydrated doesn't do correctly. I'll fix this in the next few days.
Thanks for opening this issue @kuehne-trustable-de.
I realized Pebble carried over this "Boulder-ism". I have a PR up to remove it: https://github.com/letsencrypt/pebble/pull/225 @lukas2511 Perhaps it will help you test your fix.
I'd like to remove the ID
field from Boulder's "ACME v2" Account resource responses but it will be a little trickier to implement and will need to follow a full API announcement with enough fore-warning for developers/users. I'm tracking that in https://github.com/letsencrypt/boulder/issues/4136 but it will probably be some time before it can be prioritized.
This has been fixed by now. Thanks for reporting.
While testing my OS Java ACME server impl I came across the topic of expected 'id' element in the account response. As far as I can see there is nothing like this included in the spec. My proposal would be to the URL from the location header. This avoids any assumptions regarding the implementation ...
Nevertheless: You did a great Job!
Greetings,
Andreas