starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-01-11 22:30:44 +01:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

RFC 8555 incompatible account ID handling #417

New Issue
Closed
opened 2025-12-29 01:24:41 +01:00 by adam · 5 comments
adam commented 2025-12-29 01:24:41 +01:00
Owner
Copy Link

Originally created by @cpu on GitHub (Jun 21, 2019).

Hi @lukas2511,

Recently in the Let's Encrypt staging environment we stopped sending the id field in account objects returned from the newAccount endpoint. The reason is that this field is not specified in RFC 8555. Instead Section 7.3 says:

The server returns this account object in a 201 (Created) response, with the account URL in a Location header field. The account URL is used as the "kid" value in the JWS authenticating subsequent requests by this account (see Section 6.2).

It looks like Dehydrated depended on that unspecified id field in some circumstances, and does not process the Location header. E.g. here:
74a536c161/dehydrated (L402-L404)

There was more discussion about this in https://github.com/lukas2511/dehydrated/issues/636

This has started causing issues for users with the staging environment:

As mentioned in our API Announcement this change is moving to production the week of July 3rd and will likely begin to cause more significant issues for dehydrated users.

Originally created by @cpu on GitHub (Jun 21, 2019). Hi @lukas2511, Recently in the Let's Encrypt staging environment we [stopped sending the `id` field in account objects returned from the `newAccount` endpoint](https://community.letsencrypt.org/t/acme-v2-scheduled-removal-of-id-from-account-objects/94744). The reason is that this field is **not** specified in [RFC 8555](https://tools.ietf.org/html/rfc8555). Instead [Section 7.3](https://tools.ietf.org/html/rfc8555#section-7.3) says: > The server returns this account object in a 201 (Created) response, with the account URL in a Location header field. The account URL is used as the "kid" value in the JWS authenticating subsequent requests by this account (see Section 6.2). It looks like Dehydrated depended on that unspecified `id` field in some circumstances, and does not process the `Location` header. E.g. here: https://github.com/lukas2511/dehydrated/blob/74a536c16178312845503caa5322c19de34b2dca/dehydrated#L402-L404 There was more discussion about this in https://github.com/lukas2511/dehydrated/issues/636 This has started causing issues for users with the staging environment: * https://github.com/lukas2511/dehydrated/issues/647 * https://github.com/lukas2511/dehydrated/issues/650 As mentioned in our API Announcement this change is moving to production the week of July 3rd and will likely begin to cause more significant issues for `dehydrated` users.
adam closed this issue 2025-12-29 01:24:41 +01:00
adam commented 2025-12-29 01:24:43 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Jun 25, 2019):

@cpu just to clarify: the id field will remain in the account information that can be retrieved afterwards, it's just removed from the initial registration, correct?

@lukas2511 commented on GitHub (Jun 25, 2019): @cpu just to clarify: the id field will remain in the account information that can be retrieved afterwards, it's just removed from the initial registration, correct?
adam commented 2025-12-29 01:24:43 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Jun 25, 2019):

Thanks for fixing this 👍

@cpu just to clarify: the id field will remain in the account information that can be retrieved afterwards, it's just removed from the initial registration, correct?

That's the way it's implemented presently but I think that was an oversight. It should have been removed throughout. The id field isn't specified anywhere in RFC 8555 and it shouldn't be relied on. If you're retrieving an account's information in the standard way you're POSTing its URL and so already know the ID, there isn't any value in having that non-standard field in the response since its already known.

@cpu commented on GitHub (Jun 25, 2019): Thanks for fixing this :+1: > @cpu just to clarify: the id field will remain in the account information that can be retrieved afterwards, it's just removed from the initial registration, correct? That's the way it's implemented presently but I think that was an oversight. It should have been removed throughout. The `id` field isn't specified anywhere in RFC 8555 and it shouldn't be relied on. If you're retrieving an account's information in the standard way you're POSTing its URL and so already know the ID, there isn't any value in having that non-standard field in the response since its already known.
adam commented 2025-12-29 01:24:44 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Jun 25, 2019):

@cpu mh well okay, i guess then it needs a second "fix" to actually store the information from the location header. kinda dislike to do that, but well, if it's in the rfc it's in the rfc.

@lukas2511 commented on GitHub (Jun 25, 2019): @cpu mh well okay, i guess then it needs a second "fix" to actually store the information from the location header. kinda dislike to do that, but well, if it's in the rfc it's in the rfc.
adam commented 2025-12-29 01:24:44 +01:00
Author
Owner
Copy Link

@cpu commented on GitHub (Jun 25, 2019):

That's the way it's implemented presently but I think that was an oversight. It should have been removed throughout.

Fixed in 7f01d1274e

kinda dislike to do that, but well, if it's in the rfc it's in the rfc.

@lukas2511 I have my own gripes with parts of the RFC but that's the cost of inter-operability :-) This change will definitely help dehydrated be usable with more CAs. Thanks for making the additional fix.

@cpu commented on GitHub (Jun 25, 2019): > That's the way it's implemented presently but I think that was an oversight. It should have been removed throughout. Fixed in https://github.com/letsencrypt/boulder/commit/7f01d1274ec0f1ff71310e0960c351b506f1bd3f > kinda dislike to do that, but well, if it's in the rfc it's in the rfc. @lukas2511 I have my own gripes with parts of the RFC but that's the cost of inter-operability :-) This change will definitely help dehydrated be usable with more CAs. Thanks for making the additional fix.
adam commented 2025-12-29 01:24:45 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Jun 26, 2019):

Dehydrated now uses the Location header for v2 API endpoints :)

@lukas2511 commented on GitHub (Jun 26, 2019): Dehydrated now uses the Location header for v2 API endpoints :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#417
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?