ACME Verify error: 404

[Decidable3195]

Hello everyone,

I am new in this area and have been thrown in at the deep end. I am now trying to describe my problem here as best I can. The Google search did not produce a successful solution to the problem at the moment.

We are running a Netgate 3100 with version 22.05.
Behind it are 2 networks, one for Office and a DMZ which is responsible for our cloud, homepage etc. The whole thing is realised on a small server.

The whole thing is realised on a small server on which Virtualbox is installed, on which the cloud solution, homepage, 3CX telephone system are located.

What is also important: Multi domain='DNS:www.xxx.com,DNS:service.xxx.com'.
In other words, www.xxx.com is for the homepage; service.xxx.com is for the cloud.

This is secured by letsencrypt.
However, since letsencrypt only issues a certificate for 3 months, I now have to renew it. This is quite easy with pfsense.

Unfortunately, I get the following error message and hope you can help me here:

Webserver
Renewing certificate
account: Productive
server: letsencrypt-production-2

/usr/local/pkg/acme/acme.sh --issue --domain 'www.xxx.com' --standalone --listen-v4 --httpport '80' --domain 'www.xxx.com' --standalone --listen-v4 --httpport '80' --home '/tmp/acme/Webserver/' --accountconf '/tmp/acme/Webserver/accountconf.conf' --force --reloadCmd '/tmp/acme/Webserver/reloadcmd.sh' --log-level 3 --log '/tmp/acme/Webserver/acme_issuecert.log'
Array
(
[path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
[PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
[port] => 80
[ipv6] =>
)
[Mon Feb 13 12:07:24 CET 2023] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Mon Feb 13 12:07:24 CET 2023] Standalone mode.
[Mon Feb 13 12:07:24 CET 2023] Standalone mode.
[Mon Feb 13 12:07:25 CET 2023] Multi domain='DNS:www.xxx.com,DNS:service.xxx.com'
[Mon Feb 13 12:07:25 CET 2023] Getting domain auth token for each domain
[Mon Feb 13 12:07:31 CET 2023] Getting webroot for domain='www.xxx.com'
[Mon Feb 13 12:07:31 CET 2023] Getting webroot for domain='service.xxx.com'
[Mon Feb 13 12:07:31 CET 2023] Verifying: www.xxx.com
[Mon Feb 13 12:07:31 CET 2023] Standalone mode server
[Mon Feb 13 12:07:34 CET 2023] Pending, The CA is processing your order, please just wait. (1/30)
[Mon Feb 13 12:07:37 CET 2023] www.xxx.com:Verify error:62.240.128.72: Invalid response from http://www.xxx.com/.well-known/acme-challenge/wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M: 404
[Mon Feb 13 12:07:37 CET 2023] Please check log file for more details: /tmp/acme/Webserver/acme_issuecert.log

[Gertjan]

@decidable3195 said in ACME Verify error: 404:

Please check log file for more details: /tmp/acme/Webserver/acme_issuecert.log

The last line shows you where more info can be found :
/tmp/acme/Webserver/acme_issuecert.log
although, even if you don't spot the error, at least you will know now how deep the pool is ;)

Important info is also :

http://www.xxx.com/.well-known/acme-challenge/wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M: 404

This means that if Letsencrypt, or me, or you, or who ever, visits this file :
http://www.xxx.com/.well-known/acme-challenge/wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M
you ( and I, and everybody, and also LE) should see the secret temporary 'key' (some random asci codes, you can see it in the acme log) that acme.sh put there.

So, http://www.xxx.com/.well-known/acme-challenge/ must be publicly accessible.

So, the question is : is the file there ?
And if so, is the content ok ? Often, if the file was created, the content is also fine.

You already run your own web server on a server, so you know where the web server root folder is.
In that root folder, there must be a sub folder with the name ".well-known/" that contains a subsequent folder called "acme-challenge/".
Is that so ?
Now, create a file called 'hello' and put something in it like "hello again".

Now : test, like me and LE : from the outside ( !! ), use your phone with the wifi de activated , and visit http://www.xxx.com/.well-known/acme-challenge/hello
Does it show "hello again" ?
It should.
If you can't, LE can't do it neither => fail !
Remember : LE told the acme.sh script the file name : in your case, it was "wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M" and it also gave a content like "hjgjhghjgqgqjhdqsgqsgd".
That was the "Getting domain auth token for each domain" part.

Then, all acme.sh has to do, using a helper DNS-script like 'webroot' is accessing your web root, create the sub folders and the file with the content.
This must work.
This is the :
Getting webroot for domain='www.xxx.com'
Getting webroot for domain='service.xxx.com'
part.

Btw : if all works well, and the LE check passes, the acme.sh helper script will also remove the wCSyAsP9hDHGn7CPmLyEXZd7uuAUlnBgpBrcKZux39M file.

You use the standalone mode. That's a no-automation-mode.

Read the manual : https://github.com/acmesh-official/acme.sh/wiki/How-to-issue-a-cert

That's strange because you have (you should) access to your web server's root folder.
There is the webrootftp helper mode. You have FTP access, right ?? (ok, 'FTP' was abandoned and shot in the forest last century, but you can still use it locally)

Or far better, as you have a domain name (that you rent annually) : most (the ones that don't are all broke by now) registrars have an API access : use the API access credentials, pick the right helper access, and use one of the DNS helper modes

General comments :
Opening port 80 and or 443 (the webgui) on WAN ?
Your pool is 1 mm deep, and you dive head first in it. We all know what will happen.

You are using floating rules.
Take this advise : don't do that. Live is already hard enough without that "floating" thing.