Error: Let's Encrypt finalize bad status 403 Error: Let's Encrypt finalize bad status 403

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: (loopsbyshigo.com)

I ran this command: I requested an ssl certificate from Hestia CP Server

It produced this output: Let's Encrypt finalize bad status 403 (http://loopsbyshigo.com/

My web server is (include version):

The operating system my web server runs on is (include version): Ubuntu 22.04 (aarch64)

My hosting provider, if applicable, is: Self Hosted

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): Hestia CP Server . 1.8.12

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Not sure how to see that

2

Welcome @lebonthite

Do you still get that same error? Because a Let's Debug test passes and I don't see any obvious problem with your nginx config.

Is there more details shown with that error message? There is the summary error (often 403) but also a Detail error which is more helpful.

Are you following these steps?

3 Likes
3

Thank you so much. It worked. My host was not encrypted. I had to update and upgrade my ubuntu OS and followed the link above.

2 Likes
4

Hi Mike. I started getting the same error again. This time around I don't know what it is. Please assist urgently.

5

Hi @lebonthite,

Here is what I am seeing using curl

Making the simulated HTTP-01 challenge

$ curl -Ii http://loopsbyshigo.com/.well-known/acme-challenge/sometestfile
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 29 Nov 2024 20:09:06 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://loopsbyshigo.com/.well-known/acme-challenge/sometestfile

And we see HTTP/1.1 301 Moved Permanently with a redirect to HTTPS https://loopsbyshigo.com/.well-known/acme-challenge/sometestfile

Now the following the redirect we see HTTP/2 200 which is not expected for a nonexistent file (or token).

$ curl -k -Ii https://loopsbyshigo.com/.well-known/acme-challenge/sometestfile
HTTP/2 200
server: nginx
date: Fri, 29 Nov 2024 20:09:19 GMT
content-type: text/plain; charset=utf-8
content-length: 56

Now lets make sure you don't have that file actually and empty.
Using a random file name (token), same response for HTTP as expected.

$ curl -Ii http://loopsbyshigo.com/.well-known/acme-challenge/E0D210785B4673BE717E66403F816C9B8B0436E2               HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 29 Nov 2024 20:15:38 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Location: https://loopsbyshigo.com/.well-known/acme-challenge/E0D210785B4673BE717E66403F816C9B8B0436E2

And now the redirect to HTTPS also get the same incorrect response HTTP/2 200

$ curl -k -Ii https://loopsbyshigo.com/.well-known/acme-challenge/E0D210785B4673BE717E66403F816C9B8B0436E2
HTTP/2 200
server: nginx
date: Fri, 29 Nov 2024 20:16:16 GMT
content-type: text/plain; charset=utf-8
content-length: 84

Thus a nginx configuration issue is a play.
For general nginx information you might find nginx documentation and https://forum.nginx.org/ helpful.

Edit

Even thought Let's Debug give an "OK", using the "Show verbose information." yields more information.
https://letsdebug.net/loopsbyshigo.com/2296394?debug=y
This is consistent with what I showed above

HTTPCheck
Debug
Requests made to the domain
Request to: loopsbyshigo.com/129.151.161.133, Result: [Address=129.151.161.133,Address Type=IPv4,Server=nginx,HTTP Status=301,Number of Redirects=1,Final HTTP Status=200], Issue:
Trace:
@0ms: Making a request to http://loopsbyshigo.com/.well-known/acme-challenge/letsdebug-test (using initial IP 129.151.161.133)
@0ms: Dialing 129.151.161.133
@397ms: Server response: HTTP 301 Moved Permanently
@397ms: Received redirect to https://loopsbyshigo.com/.well-known/acme-challenge/letsdebug-test
@397ms: Dialing 129.151.161.133
@1016ms: Server response: HTTP 200 OK

Now I find this part interesting

LetsEncryptStaging
Debug
Challenge update failures for loopsbyshigo.com in order https://acme-staging-v02.api.letsencrypt.org/acme/order/5751349/20904231164
acme: error code 403 "urn:ietf:params:acme:error:unauthorized": The key authorization file from the server did not match this challenge. Expected "jAptMIp1RCjjoQCbMqPUuGw5zbejqkt1nBrDQ2Rr_pg.49wknCPN_3HICrKF6BR-V-a-E_ipoaGro7D1Fju_2ec" (got "jAptMIp1RCjjoQCbMqPUuGw5zbejqkt1nBrDQ2Rr_pg.DHZ-0-M9W7N_UOio5Z_bFarqMqtY55O_SOPdXY7O2WQ")

Expected
"jAptMIp1RCjjoQCbMqPUuGw5zbejqkt1nBrDQ2Rr_pg.49wknCPN_3HICrKF6BR-V-a-E_ipoaGro7D1Fju_2ec"

got
"jAptMIp1RCjjoQCbMqPUuGw5zbejqkt1nBrDQ2Rr_pg.DHZ-0-M9W7N_UOio5Z_bFarqMqtY55O_SOPdXY7O2WQ"

They match up to a point and then they deviate.

3 Likes