I ran this command:
./dehydrated --register --accept-terms
It produced this output:
Generating account key...
Registering account key with ACME server...
Certificate authority doesn't allow registrations.
I can login to a root shell on my machine (yes or no, or I don't know):yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Dehydrated
I try to connect to the Let's encrypt API, however this fails therefore the dehydrated script I run returns:
Can you please check your dehydrated version and make sure the software is registering on ACMEv2 API? The error message might occur because they are attempting to register on now depreciated ACMEv1 API.
P.S. To learn how, look it up on Dehydrated GitHub repo.
I'm not really familiar with your client, but having written my own client I am familiar with the error.
This is the server refusing to create an account. The registration process should be going to https://acme-v02.api.letsencrypt.org/acme/new-acct. It looks like your client is not following the protocol (or is misinterpreting the response from the server). Can you update your client?
Itâs hard to say whatâs happening really without having access to your environment. What dehydrated thinks is happening is that the ACME directory is not providing a registration endpoint.
What I can suggest is to run dehydrated in tracing mode:
bash -xv dehydrated --register --accept-terms 2>&1 | tee -a dehydrated.log
and then look in dehydrated.log to see whatâs happening. In particular, near this logging:
That first equality is ${API} -eq 2. That checks out, it's using the ACMEv2 API.
The second check is -z "${CA_NEW_ACCOUNT}". For some reason, CA_NEW_ACCOUNT is an empty string. It's not being picked up from the directory for some reason, despite earlier it being seen:
What version of dehydrated do you have?
dehydrated --version
I see that dehydrated recently merged some new JSON parsing via json.sh, something might be wrong there.
mh yea, seems like a problem with freebsd sed compatibility. if somebody could debug this further that would be great, otherwise it has to wait until next week