Let's Encrypt token not available

FreePBX Security
1

I am trying to finish deployment of new FreePBX 16 and I’m stuck on Certificate manager. There were already so many topics on this but issues were random.
After a bit of digging:

[root@pbx16 integration]# fwconsole certificates --generate --hostname=mydomain.com [email protected] --type=le --country-code=pl --state=Mazovian
Processing: mydomain.com, Local IP: <private_ip>, Public IP: <public_ip>
Self test: trying http://mydomain.com/.freepbx-known/8f6f9a1407d39acb30ce8eae50b377c5
Self test: received 8f6f9a1407d39acb30ce8eae50b377c5
lechecker: Pest_Curl_Exec - Operation timed out after 30001 milliseconds with 0 out of -1 bytes received
Getting list of URLs for API
Requesting new nonce for client communication
Account already registered. Continuing.
Sending registration to letsencrypt server
Sending signed request to https://acme-v02.api.letsencrypt.org/acme/new-acct
Account: https://acme-v02.api.letsencrypt.org/acme/acct/1550441067
Starting certificate generation process for domains
Requesting challenge for mydomain.com
Sending signed request to https://acme-v02.api.letsencrypt.org/acme/new-order
Sending signed request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/310880213677
Got challenge token for mydomain.com
Token for mydomain.com saved at /var/www/html/.well-known/acme-challenge/L-L4UOi5KR5dde77aMUvFEZFld2Cx_SnXapleKIDHZY and should be available at http://mydomain.com/.well-known/acme-challenge/L-L4UOi5KR5dde77aMUvFEZFld2Cx_SnXapleKIDHZY

   ** lechecker: Pest_Curl_Exec - Operation timed out after 30001 milliseconds with 0 out of -1 bytes received

LetsEncrypt Update Failure:
Please check http://mydomain.com/.well-known/acme-challenge/L-L4UOi5KR5dde77aMUvFEZFld2Cx_SnXapleKIDHZY - token not available

The token is placed in a said location:

[root@pbx16 integration]# ls -la /var/www/html/.well-known/acme-challenge/
total 4
drwxrwxr-x 2 asterisk asterisk 57 Feb  2 21:01 .
drwxrwxr-x 3 asterisk asterisk 28 Feb  2 19:14 ..
-rw-r--r-- 1 root     root     87 Feb  2 21:01 L-L4UOi5KR5dde77aMUvFEZFld2Cx_SnXapleKIDHZY
[root@pbx16 integration]# ls -la /var/www/html/.well-known/acme-challenge/
total 4
drwxrwxr-x 2 asterisk asterisk 57 Feb  2 21:01 .
drwxrwxr-x 3 asterisk asterisk 28 Feb  2 19:14 ..
-rw-r--r-- 1 root     root     87 Feb  2 21:01 L-L4UOi5KR5dde77aMUvFEZFld2Cx_SnXapleKIDHZY
[root@pbx16 integration]# ls -la /var/www/html/.well-known/acme-challenge/
total 0
drwxrwxr-x 2 asterisk asterisk  6 Feb  2 21:01 .
drwxrwxr-x 3 asterisk asterisk 28 Feb  2 19:14 ..
[root@pbx16 integration]# ls -la /var/www/html/.well-known/acme-challenge/

But is removed when error happens.
After checking the traffic on the my machine’s network interface, I can see that the HTTP request from the my machine is sent to: 104.22.48.127 (mirror1.freepbx.org @ cloudflare):
[GET /lechecker.php?host=mydomain.com&path=%2F.freepbx-known%2Fc08c1f9cee1b721ff1743493560ca9e0&token=c08c1f9cee1b721ff1743493560ca9e0&type=http HTTP/1.1\r\n]

Then the 167.99.224.159 is trying to acquire this token:
[GET /.freepbx-known/c08c1f9cee1b721ff1743493560ca9e0 HTTP/1.1\r\n]

but even if the path exists (the random name is temporarily created), it apparently is not accessible since my machine just does not answer to repeated retransmissions.

Certman version is:

| certman             | 16.0.22    | Enabled | AGPLv3+    | Sangoma   |

Is it a bug or there’s something that can be done in order to verify it further?

2

After playing with firewall and LetsEncrypt rules I’ve got:

GET /.freepbx-known/d80379c66a929048a904064c0a94bed9 HTTP/1.1
Host: mydomain.com
Accept: */*

HTTP/1.1 301 Moved Permanently
Date: Sat, 03 Feb 2024 20:15:42 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/7.4.16
Location: https://mydomain.com/.freepbx-known/d80379c66a929048a904064c0a94bed9
Content-Length: 280
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://mydomain.com/.freepbx-known/d80379c66a929048a904064c0a94bed9">here</a>.</p>
</body></html>

Shouldn’t the target link be within .well-known path?

3

So, it seems the issue with generating new Let’s Encrypt certificates on a freshly installed FreePBX 16 is two-fold:

  1. “token is not available” - the built-in firewall, even if it has LE functions turned on - does not necessarily allow all required traffic to go in on port 80. Disabling firewall temporarily helped.
  2. “token did not match” - LetsEncrypt 'Token did not match' - #6 by thimo - it’s weird that on freshly installed system this has to be manually changed if it influences one of the “almost” core functions (Let’s encrypt agent). I checked my old FreePBX15 box and it seems I had to do that as well (even if I don’t remember that). Would be nice to have it done out-of-the-box.

Actually I think that the default https-redirect rules should be more like below, as I have a bunch of other subdirs with helper forms and listing it all in the configuration is troublesome:

[root@pbx ~]# cat /etc/httpd/conf.d/https-redirect.conf
<VirtualHost *:80>
 RewriteEngine on
 RewriteCond %{HTTPS} !=on [NC]
 RewriteCond %{REQUEST_URI} !^/\.well-known
 RewriteCond %{REQUEST_URI} !^/\.freepbx-known
 RewriteRule ^/(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# RewriteRule ^/(admin|ucp|fop2|call-form)/(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
[root@pbx ~]#
4

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