Shared Wordpress Hosting returning 404 for challenge

I have a nonprofit (church) website hosted on dreamhost. It’s had a LetsEncrypt certificate for years now, but renewal just stopped working. No changes to rewrite rules or plugins or anything from us (although who knows what dreamhost changed), but now, trying to fetch any file (without a file extension) from .well-known/acme-challenge directory returns a 404 error.

I made a copy of the challenge file in the .well-known/acme-challenge directory and put .txt on the end, and that works (so it’s not the directory permissions), I put copies of the challenge file in a new directory called well-known/acme-challenge (without the leading .) and a new directory called .foo (to see if a leading dot was breaking it), and both those worked. I’ve turned off Cloudflare caching for the moment, just to see if that was it.

So it kinda looks like dreamhost is explicitly blocking the .well-known/acme-challenge directory.

I have shell access to the webserver, but not root.

Any idea where I should look to figure out what’s going on? Anyone seen this before?

-Carl

My domain is: trinitychurchofaustin.org

I ran this command: curl -i -L https://www.trinitychurchofaustin.org/.well-known/acme-challenge/j20C855CKpuPNUrt05sLxGWiQJ-bMKYkvwUzi9pHi-I

It produced this output: HTTP/1.1 404 Not Found

I also ran these commands:
curl -i -L https://www.trinitychurchofaustin.org/.well-known/acme-challenge/j20C855CKpuPNUrt05sLxGWiQJ-bMKYkvwUzi9pHi-I.txt
curl -i -L https://www.trinitychurchofaustin.org/well-known/acme-challenge/j20C855CKpuPNUrt05sLxGWiQJ-bMKYkvwUzi9pHi-I
curl -i -L https://www.trinitychurchofaustin.org/.foo/j20C855CKpuPNUrt05sLxGWiQJ-bMKYkvwUzi9pHi-I

They all produce this output: HTTP/1.1 200 OK

The files are there:

ls -ln .well-known/acme-challenge/j*
-rw-r--r-- 1 1094560 72110 88 Aug  4 18:59 .well-known/acme-challenge/j20C855CKpuPNUrt05sLxGWiQJ-bMKYkvwUzi9pHi-I
-rw-r--r-- 1 1094560 72110 88 Aug  4 19:51 .well-known/acme-challenge/j20C855CKpuPNUrt05sLxGWiQJ-bMKYkvwUzi9pHi-I.txt

My web server is (include version): Apache (not sure about version)

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

My hosting provider, if applicable, is: Dreamhost

I can login to a root shell on my machine (yes or no, or I don’t know): no

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 1.6.0

2 Likes

Hi,

I think dreamhost have their own implementation to obtain Let’s Encrypt certificate, can you try to use their version? https://help.dreamhost.com/hc/en-us/articles/216539548-Adding-a-free-Let-s-Encrypt-certificate

Thank you

1 Like

That seems to work. Maybe they’re doing a bulk redirect of all the .well-known/acme-challenge directories on all their sites now to handle their new LetsEncrypt integration (at least I assume it’s new - that article is dated July 2nd, and the behavior has definitely changed since the May).

Thanks.

-Carl

1 Like

I got in touch with DreamHost support after running into the issue using pfsense to generate a valid TLS cert for my intranet which is using split DNS. I’m using the webroot FTP acme plugin integration to place the HTTP-01 challenge correctly, and as @carlbrwn found DreamHost’s LetsEncrypt integration automatically intercepts incoming ACME requests.

Anyways, DreamHost support was thankfully able to offer a resolution: upload your ACME challenge to /dev/shm/acme_<domain>/ instead of the usual /home/<user>/<domain>/.well-known/acme-challenge/ and DreamHost will serve it up as expected.

DreamHost said:

We moved the authorization locations due to .htaccess files causing failures resulting in more processes to run. Moving it out makes the authorization more reliable and seamless. Please note, since you are using a manual setup of Let’s Encrypt, this is solely unsupported, however we will do what we can to help.

:+1:

1 Like

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