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

We’re having the same issue with a different client (dehydrated). redirects to but that url returns 404.

Former agreement url works ok:

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

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

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

1 Like

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

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:

But it looks like they use a wrong technique to get the right tos-url by extracting the redirect target from the url

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 - | grep terms-of-service
"terms-of-service": ""

Thats clearly a bug in dehydrated.

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

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

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


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