The key authorization file from the server did not match this challenge

Help
1

I have a domain that I was previously using the acme API to generate a new cert. Since GoDaddy DNS disabled that ability, I've been using the --webroot option to renew the cert, and it's been working fine until today.

Now I'm receiving a weird error that looks to be related to the letsencrypt account key?

[Fri Jun 28 03:17:27 PM EDT 2024] Invalid status, webstage.wellingtonpotpies.com:Verify error detail:The key authorization file from the server did not match this challenge. Expected 
[Fri Jun 28 03:17:27 PM EDT 2024] Please check log file for more details: /root/.acme.sh/acme.sh.log

The acme log also shows some kind of wget error. I've added --no-check-certificate because the cert on this server has expired.

[Fri Jun 28 03:17:27 PM EDT 2024] _WGET='wget -q --content-on-error  --no-check-certificate '
[Fri Jun 28 03:17:28 PM EDT 2024] wget returns 8, the server returns a 'Bad request' response, lets process the response later.
[Fri Jun 28 03:17:28 PM EDT 2024] responseHeaders='HTTP/1.1 400 Bad Request

There's also a note about the server being nginx? That's wrong. It's apache-2.4.59
Server: nginx

Then there's some other error messages about "authorization must be pending"

[Fri Jun 28 03:17:28 PM EDT 2024] original='{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Unable to update challenge :: authorization must be pending",
  "status": 400
}'
[Fri Jun 28 03:17:28 PM EDT 2024] response='{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Unable to update challenge :: authorization must be pending",
  "status": 400
}'

but the logs on my server indicate it was a 200 success on port 80:
66.133.109.36 - - [28/Jun/2024:15:09:58 -0400] "GET /.well-known/acme-challenge/xR1HDHmkVCyFnPpgO2-TcyR7yal0ul_zBmukH_46xSI HTTP/1.1" 200 91 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)" 0/38116

I've seen indications in previous posts related to this "key authorization file" error that it's attempting to connect to the ipv6 server? There is no ipv6 version of this server.

My domain is:
webstage.wellingtonpotpies.com

I ran this command:
/acme.sh --dnssleep 300 --force --log --issue --insecure --staging --listen-v4 --webroot /var/www/www.wellingtonpotpies.com-443/html/ -d webstage.wellingtonpotpies.com --fullchain-file /etc/letsencrypt/wellington-fullchain.pem --key-file /etc/letsencrypt/wellington-privkey.pem

It produced this output:
see above

My web server is (include version):
rpm -q httpd
httpd-2.4.59-2.fc38.x86_64

The operating system my web server runs on is (include version):
fedora38

My hosting provider, if applicable, is:
This is our own server, but DNS is managed by GoDaddy

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. ssh and manual config only.

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

# ./acme.sh --version
https://github.com/acmesh-official/acme.sh
v3.0.8
2

Please don't use this option. There usually is no good reason to force a renewal of a perfectly fine existing certificate. It usually only leads to hitting rate limits and increases load on the Let's Encrypt systems. If there is no certificate to forcefully renew to begin with, this option is useless.

Please don't use this option: the Let's Encrypt ACME server should not be marked as insecure, unless your system is terribly broken.

What's the meaning of the -443 there? It suggests a HTTPS virtualhost, maybe you have HTTP separated from HTTPS? Please note that the http-01 challenge uses HTTP in the beginning and only after a redirect (if present), port 443/HTTPS is used.

2 Likes
4

There must be a DocumentRoot for the port 80 VirtualHost when you are using the webroot method. The DocumentRoot must match the webroot path you provided on the acme.sh command line.

The Let's Encrypt API server is nginx. I'm not sure where you saw that but it might from a log entry of the API requests.

1 Like
5

Thank you all for your help. It is working now. I think I had a mismatch between the document root specified in the virtual host and the document root specified in my acme command.

It really shouldn't have mattered, though, because my acme command processes multiple hosts with different document roots, so I'm really not sure.

2 Likes