422 in .well-known/acme-challenge when attempting to renew a cert

Hey folks! Looking to renew a cert for a vaultwarden instance I'm running and am encountering an issue with .well-known/acme-challenge - attempting to navigate to the file placed there results in a "422 Unprocessable Entity" error. This is also true of a test file placed there manually, though throwing a test file elsewhere in the webroot and its subdirectories allows it to be seen as expected.

For a bit of context, I'm using lighttpd to redirect vault.ryburlingtons.net to the local port that vaultwarden runs on - it shouldn't be doing much else but it's possible there's a configuration I should be looking at that I'm not.

Let me know if any additional context would help - thank you in advance!

My domain is:

vault.ryburlingtons.net

I ran this command:

sudo certbot certonly --cert-name ryburlingtons.net -d cloud.ryburlingtons.net -d vault.ryburlingtons.net -d ryburlingtons.net

(I have another subdomain and a root domain I'm trying to re-cert as well)

It produced this output:

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: vault.ryburlingtons.net
Type: unauthorized
Detail: 173.56.200.212: Invalid response from https://vault.ryburlingtons.net/.well-known/acme-challenge/q-5WMlM1ObC1bZbQ8oPo9UoNwi3ANwSO44XOGnoA04A: 422

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

My web server is (include version):

lighttpd/1.4.69 (ssl)

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

DietPi v8.25.1

My hosting provider, if applicable, is:

myself

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):

certbot 2.1.0

You may find better advice at a forum for Rocket server or even lighttpd. If you get a 422 trying to get a test file on your server that's just a server config issue. Not really anything specific to Let's Encrypt

That said, I see the below which looks like your Rocket(?) server is not allowing URI with a period in them.

The reason I am using HTTPS instead of HTTP is that HTTP requests are properly redirected to HTTPS by lighttpd. The 422 is only seen with HTTPS and Rocket.

# This gets an expected 404 Not Found
curl -i https://vault.ryburlingtons.net/we
HTTP/2 404
server: Rocket

# This gets the odd 422
curl -i https://vault.ryburlingtons.net/.we
HTTP/2 422
server: Rocket

# Any longer path also gets 422
curl -i https://vault.ryburlingtons.net/.well-known/acme-challenge/Test404
HTTP/2 422
server: Rocket
2 Likes

I also get a redirection:

curl -Ii http://vault.ryburlingtons.net/.well-known/acme-challenge/Test_File-1234
HTTP/1.1 301 Moved Permanently
Location: https://vault.ryburlingtons.net/.well-known/acme-challenge/Test_File-1234
Date: Thu, 04 Jan 2024 03:37:33 GMT
Server: lighttpd/1.4.69

I'd suggest handling the ACME challenge requests in HTTP [and not redirecting them].

3 Likes

Got it, makes sense - dummy files placed in a ".test" folder also give me a 422 but load up fine when placed in a "test" (no period) folder, so that tracks with what I'm seeing. Doesn't seem to be lighttpd's fault, switching off https redirection completely did not do the trick and there are no applicable configs that should be causing problems with URIs that have a period in them. Guessing that means it's something Rocket is doing.

I'll take it to the vaultwarden folks and see if they know what's up - thank you!

2 Likes

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