Dehydrated - 400 on new-reg - provided subscriber agreement URL does not match current

Help
1

We’re having the same issue with a different client (dehydrated).

https://acme-v01.api.letsencrypt.org/terms redirects to https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf but that url returns 404.

Former agreement url works ok: https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf

So I’d say this is not an acme.sh issue, but a Let’s Encrypt problem.

2

Hi @fjrosmunoz,

Thanks for flagging this 404. I will ask our operations team to investigate.

While the document 404's this shouldn't have any affect on ACME registrations since only the URL is used, not the document contents.

We announced this terms of service URL change ahead of time knowing some ACME clients will break for new registrations if they hardcode the old ToS URL.

If you are using an ACME client that returns this error it is a problem with the ACME client that should be reported to the developers to be fixed. ACME clients should be coded in such a way that they do not hardcode this URL, because it will change. The protocol supports learning the URL at registration time and that is the only approach that will work when the URL changes.

1 Like
3

HI @fjrosmunoz - thanks for reporting this. The 404 has been fixed.

1 Like
4

Hi @cpu,

Thanks for looking into this!

I took a look to the code of dehydrated before reporting the ‘not found’ issue, and I saw they don’t hardcode the agreement’s url:

That’s why I thought the problem was trying to get the agreement’s url from the terms’ url. But I just realized we’re using a previous version of dehydrated that doesn’t include such behavior. I’ll check whether upgrading dehydrated fixes the problem :slight_smile:

1 Like
5

That sounds like a likely explanation! Please report back if the problem is resolved by an update so that other Dehydrated users can find this solution too :slight_smile:

6

But it looks like they use a wrong technique to get the right tos-url by extracting the redirect target from the url https://acme-v01.api.letsencrypt.org/terms.

The right way would be to retrieve the /directory api endpoint and use the value of the field 'terms-of-service' from the meta-element:

$ wget -qO - https://acme-v01.api.letsencrypt.org/directory | grep terms-of-service
"terms-of-service": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf"

Thats clearly a bug in dehydrated.

7

This technique is acceptable if perhaps not optimal. I believe they implemented it before Let's Encrypt was returning the "meta" directory entry you refer to.

I don't think learning the ToS URL this way is a bug.

1 Like
8

I confirm that upgrading to dehydrated v0.4.0+ solves the issue.
However, lua-resty-auto-ssl needs some updates to make it work with such version of dehydrated:

Thanks everyone!

1 Like
9

Thanks @fjrosmunoz - I split this topic off of the previous one that started with a complaint about acme.sh so that we can mark this one solved from the Dehydrated update.

2 Likes
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.