missing id #412

New Issue

2025-12-29T01:24:39+01:00

adam commented

2025-12-29 01:24:39 +01:00

Originally created by @makuk66 on GitHub (Jun 18, 2019).

When I ran dehydrated -c (as of master today) on a new host, I got:

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Malformed account ID in KeyID header URL: \"https://acme-staging-v02.api.letsencrypt.org/acme/acct/\"",
  "status": 400
}

Note the lack of account ID at the end of that URL there.

This happens because this code does not verify the parsed ACCOUNT_ID value before using it: https://github.com/lukas2511/dehydrated/blob/74a536c16178312845503caa5322c19de34b2dca/dehydrated#L404-L409

and somehow I had a registration_info.json that contained JSON content, but no id field, so ACCOUNT_ID was empty. I'm not entirely sure how I got to that state. I had run dehydrated --register --accept-terms and gotten a Account already registered!. Perhaps this is because I tried to configure Let's Encrypt for this domain from some different machine some time ago.

I got passed this by doing https://github.com/makuk66/dehydrated/commit/8bae8d28b3401c8130e4f0e04fcf3fdf02f0005c ie by treating a missing id field as if the json file was missing, causing it to fetch it from the CA. I then ended up with an id field in my registration_info.json, and certs were successfully created.

Originally created by @makuk66 on GitHub (Jun 18, 2019). When I ran `dehydrated -c` (as of `master` today) on a new host, I got: ``` { "type": "urn:ietf:params:acme:error:malformed", "detail": "Malformed account ID in KeyID header URL: \"https://acme-staging-v02.api.letsencrypt.org/acme/acct/\"", "status": 400 } ``` Note the lack of account ID at the end of that URL there. This happens because this code does not verify the parsed `ACCOUNT_ID` value before using it: https://github.com/lukas2511/dehydrated/blob/74a536c16178312845503caa5322c19de34b2dca/dehydrated#L404-L409 and somehow I had a `registration_info.json` that contained JSON content, but no `id` field, so `ACCOUNT_ID` was empty. I'm not entirely sure how I got to that state. I had run `dehydrated --register --accept-terms` and gotten a `Account already registered!`. Perhaps this is because I tried to configure Let's Encrypt for this domain from some different machine some time ago. I got passed this by doing https://github.com/makuk66/dehydrated/commit/8bae8d28b3401c8130e4f0e04fcf3fdf02f0005c ie by treating a missing `id` field as if the json file was missing, causing it to fetch it from the CA. I then ended up with an `id` field in my `registration_info.json`, and certs were successfully created.

adam closed this issue

2025-12-29 01:24:40 +01:00

adam commented

2025-12-29 01:24:40 +01:00

@elgarfo commented on GitHub (Jun 21, 2019):

i came across the same issue these days and your patch works perfectly. thanks for this quick fix @makuk66!

i only experienced this problem while using the staging v2 api. the production api works just fine. this might have to do with #636.

#650 is another example of this problem (also using the staging environment).

@elgarfo commented on GitHub (Jun 21, 2019): i came across the same issue these days and your patch works perfectly. thanks for this quick fix @makuk66! i only experienced this problem while using the staging v2 api. the production api works just fine. this might have to do with #636. #650 is another example of this problem (also using the staging environment).

adam commented

2025-12-29 01:24:40 +01:00

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

i only experienced this problem while using the staging v2 api. the production api works just fine. this might have to do with #636.

@elgarfo You're correct about this. I filed a separate issue (#652) that explains the root cause and the link to the staging environment. This will become an issue for the production endpoint in the next few weeks.

@cpu commented on GitHub (Jun 21, 2019): > i only experienced this problem while using the staging v2 api. the production api works just fine. this might have to do with #636. @elgarfo You're correct about this. I filed a separate issue (#652) that explains the root cause and the link to the staging environment. This will become an issue for the production endpoint in the next few weeks.

adam referenced this issue

2025-12-29 01:29:31 +01:00

[PR #412] [CLOSED] add host for OCSP request #828

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#412