Can't renew after failed switch to ZeroSSL; LE server can't get token file

Help
1

domain: cosd.com
server: Apache 2.4.52 (Ubuntu)
full shell & root access (no control panel)
client: acme.sh 3.07 & 3.0.8

I can't determine from our acme.sh log file (here) what's going wrong with my certificate renewal this time around. I've been using a LetsEncrypt cert for about 2 years with no problems... originally set up through certbot & then migrated to acme.sh soon afterward, and switching web host with no problems.

Just under 3 months ago I attempted to switch to ZeroSSL but then restored everything (?) back to LE when I couldn't get ZeroSSL to work. Our cron renewal failed at the next 60 day interval... whatever I do now, the logfile indicates it can't get the URL containing the created token:

[Sun Mar 31 18:24:20 UTC 2024] Invalid status, cosd.com:Verify error detail:129.213.164.46: Invalid response from https://cosd.com/.well-known/acme-challenge/hEG4yGOF2EZP4WiSsUUParYHiN2qwcl3RHHyc6Aigoo: 404

I've been using the usual syntax for Webroot mode (my site is in a /web subdirectory; though it's a CMS, files & directories are also accessible from there):

acme.sh --log --issue --server letsencrypt -d cosd.com -d www.cosd.com -w /var/www/html/cosd.com/web

The "Third Party Tool" letsdebug.net for cosd.com confirms under HTTPCheck that my .well-known/acme-challenge/ directory is accessible through Apache. (I think the HTTP 404 Not Found response for the dummy filename is normal in this context)?

From what I can understand in the logfile, it's getting a "token" with a long random name from the LE server and then creating a file named by that token in /web/.well-known/acme-challenge/ ... but by the time the LE server attempts to verify the presence of that file it isn't there (or not served by Apache; which works normally for files everywhere else).

Here's what I can't understand: our server directory .well-known/acme-challenge/ is modified when the acme.sh script is run, but it doesn't leave the filename there. The logfile indicates that the token-named file is created, but not that it's deleted. If you follow the server response URLs you'll see that the file is indeed no longer there.

I don't know whether it's normal for that file to be deleted after use in the authentication (and I don't know how to prevent its deletion), but without the file persisting I don't know whether our own acme.sh is deleting that file prematurely... or if we're failing another requirement of the LE server is expecting... without help. :pray:

Since our acme.sh functioned fine with renewals for nearly 2 years, I also feel this is related to our attempt to get a cert 3 months ago from ZeroSSL, as also originally suggested here (Invalid Response from well-known/acme-challenge with .acme.sh/acme.sh).

2

Yes. That test site cannot place files on your server so expects a Not Found. It is mostly checking connectivity and various other common problems (faulty DNS, CAA, ...).

Before digging into logs and token files let's just check Apache. Please show output of this

sudo apache2ctl -t -D DUMP_VHOSTS
4 Likes
3

thanks: this helped me find the problem... it showed a normal list of vhosts but began with a warning:

[Mon Apr 01 05:15:51.136021 2024] [alias:warn] [pid 857] AH00671: The Alias directive in /etc/apache2/apache2.conf at line 236 will probably never match because it overlaps an earlier Alias.

This alias that I didn't even know about was the one defined twice:

Alias /.well-known/acme-challenge  /home/.acme

<Directory /home/.acme >
Require all granted
</Directory>

There is likely some custom Apache directive I added that makes this directory inaccessible to my web server, although that's apparently where it was expecting the token files to be found. I've removed that alias and now the cert is issued properly.

Another change is that the cert is now placed in a directory with an _ecc suffix but I guess that's because EC key pairs have become the default in the latest version of acme.sh :thinking: ... so our Apache config also needed to be edited to find the new cert pathname.

I assume the default installation (which I ran twice: probably why I ended up with 2 aliases) moves the challenge directory outside the webroot for security reasons. This seems a minor reservation because the token files are immediately deleted... but if you could please post any information about such a security issue it would help me decide whether to get this Alias directive working properly. :pray:

4

What did you "install" twice?
[I'm unfamiliar with any software that makes such an alias change]

2 Likes
5

I did run acme.sh --install exactly twice: but if that doesn't write this alias to /etc/apache2/apache2.conf then I can't be sure what else would.

Maybe some crappy cloud.cfg on our Oracle Always Free hosting platform: this often tweaks config files without providing a rationale, e.g. perhaps related to the bug fixed here long ago:

In any case if I definitively find out the culprit before this topic closes I'll post it here.

2 Likes
6

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