• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue LetsEncrypt "extend" command is no longer working: nginx configuration causes 404

ronv

Basic Pleskian
Hi, I'm running into a 404 error while expanding an existing LetsEncrypt certificate, via the "plesk bin extension --exec letsencrypt cli.php". Previously, this command used to work; has anything changed in the recent update to LetsEnctrypt-2.8.1?

Setup: Plesk Onyx 17.0.17 (Update #63) on Ubuntu, nginx as reverse proxy for Apache.

TL;DR: LetsEncrypt is creating an acme challenge token file at the correct location, but LetsEncrypt nginx configuration settings point URL requests for this token file to the wrong location. This didn't happen before, and I am looking for a way to fix/work around this.

I have successfully created a LetsEncrypt certificate for a domain dev.extra.kantl.be. Now I want to expand this and add the domain dev.apps.kantl.be to that certificate. The extra domain dev.apps.kantl.be is listed as alias for the main domain (and as noted earlier, this used to work before the certificate got renewed yesterday).

When trying to extend the certificate with following command:

Code:
plesk bin extension --exec letsencrypt cli.php -d dev.extra.kantl.be -d dev.apps.kantl.be --email [my@email] --expand --webroot-path /var/www/vhosts/kantl.be/sites/dev.extra.kantl.be

I'm receiving following error:

Code:
[2019-07-14 23:28:01] ERR [extension/letsencrypt] Execution of /opt/psa/admin/plib/modules/letsencrypt/scripts/cli.php failed with exit code 1 and the output:
[2019-07-14 23:27:57] ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/filemng' 'administrator' 'cp2perm' 'filemngEBh6he' '/var/www/vhosts/kantl.be/sites/dev.extra.kantl.be/.well-known/acme-challenge/CPVe5qUth888L9d-6Nxu3w6FET5bIUkTNCjYuqAuJls' '0644'] with exit code [1]
[2019-07-14 23:28:01] ERR [extension/letsencrypt] Domain validation failed for dev.apps.kantl.be: Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz/WrW1bGe3Do7GKvzOgJNSXVcXIJaatIPfy43XO0-vq04.
Details:
Type: urn:ietf:params:acme:error:unauthorized
Status: 403
Detail: Invalid response from http://dev.apps.kantl.be/.well-known/acme-challenge/6HoGd3lU-QHuB_3GmmmXCDWjA53tVlKPxrHnNHGb4LM [2a01:488:67:1000:5bfa:519d:0:1]: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"
[2019-07-14 23:28:01] ERR [extension/letsencrypt] Domain validation failed: Invalid response from https://acme-v02.api.letsencrypt.org/acme/authz/WrW1bGe3Do7GKvzOgJNSXVcXIJaatIPfy43XO0-vq04.

Some observations:
  1. This command does successfully create the acme-challenge token in the specified website root folder. After the command, I find said file at /var/www/vhosts/kantl.be/sites/dev.extra.kantl.be/.well-known/acme-challenge/6HoGd3lU-QHuB_3GmmmXCDWjA53tVlKPxrHnNHGb4LM
  2. Yet, this token indeed is not accessible at http://dev.apps.kantl.be/.well-known/acme-challenge/6HoGd3lU-QHuB_3GmmmXCDWjA53tVlKPxrHnNHGb4LM, returning a 404 "not found" by nginx.
  3. I've noticed following configuration in /etc/nginx/plesk.conf.d/vhosts/dev.extra.kantl.be.conf:
    Code:
    #extension letsencrypt begin
    
    location ^~ /.well-known/acme-challenge/ {
        root /var/www/vhosts/default/htdocs;
    
        types { }
        default_type text/plain;
    
        satisfy any;
        auth_basic off;
        allow all;
    
        location ~ ^/.well-known/acme-challenge.*/. {
            deny all;
        }
    }
    #extension letsencrypt end

If I'm interpreting this configuration snippet correctly, this seems to specify /var/www/vhosts/default/htdocs as root for acme-challenge requests, meaning that the server will not go looking for the 6HoGd3lU-QHuB_3GmmmXCDWjA53tVlKPxrHnNHGb4LM file at the place where it's located (/var/www/vhosts/kantl.be/sites/dev.extra.kantl.be/.well-known/acme-challenge/6HoGd3lU-QHuB_3GmmmXCDWjA53tVlKPxrHnNHGb4LM), but instead in that root folder location at /var/www/vhosts/default/htdocs/.well-known/acme-challenge/QHuB_3GmmmXCDWjA53tVlKPxrHnNHGb4LM, causing a 404. (Indeed, if I move that QHuB_3GmmmXCDWjA53tVlKPxrHnNHGb4LM file to /var/www/vhosts/default/htdocs/.well-known/acme-challenge, the request does succeed.)

So, this definitely is an issue with the root location configuration in nginx. Two questions:
  1. Has anything changed in this respect, since version 2.8.1 of the LetsEncrypt extension? The previous time I had issued this problematic extension command, it used to work; must definitely have been before the 2.8.1 release date of July 5. If so, how should certificate extensions be issued after this update?
  2. Is there a way to override this root location in a custom vhost_nginx.conf file for this domain, so that it points to /var/www/vhosts/kantl.be/sites/dev.extra.kantl.be? My vhost_nginx.conf file did already contain this location block:
    Code:
    location ~ /.well-known {
       allow all;
    }
    But adding a root directive pointing to the relevant location of that challenge token file, this does not seem to have any effect.

I've tried to be as detailed as possible; any help will be greatly appreciated!

Best,

Ron
 
Last edited:
Back
Top