dehydrated-io / dehydrated

letsencrypt/acme client implemented as a shell-script – just add water
https://dehydrated.io
MIT License
5.96k stars 716 forks source link

account 'id' #636

Closed kuehne-trustable-de closed 4 years ago

kuehne-trustable-de commented 5 years ago

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

lukas2511 commented 5 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.

kuehne-trustable-de commented 5 years ago

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

lukas2511 commented 5 years ago

I think you are correct, this seems to be something dehydrated doesn't do correctly. I'll fix this in the next few days.

cpu commented 5 years ago

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.

lukas2511 commented 4 years ago

This has been fixed by now. Thanks for reporting.