How to secure the Plesk Panel with a Lets Encrypt certificate (and solve port 8443 problem)

Written by Claudio Kuenzler - 0 comments

Published on August 24th 2021 - Listed in Internet TLS Security Cloud SSL

The Plesk (administration) panel usually listens on port tcp/8443, launched by the sw-cp-server process. In the browser the Plesk panel can then be accessed using https://servername.example.com:8443.

Plesk allows the user to define what certificate should be used to handle HTTPS encryption. This can be configured in Tools & Settings -> SSL/TLS certificates.

In the past (a couple of years back) this was used to upload private key and public certificate files. But these days free CA's, such as Let's Encrypt, are available. And Plesk even offers to create a Let's Encrypt certificate to secure the Plesk server itself (by using the Let's Encrypt Extension):

With the click on the "Let's Encrypt" button, a new free certificate can be obtained and installed - supposedly.

Let's Encrypt error: Only ports 80 and 443 are supported, not 8443

With a click on the "Let's Encrypt" button, the "Secure Plesk With a Let's Encrypt Certificate" form shows up.

Secure Plesk Server with Let's Encrypt certificate

A click on the "Install" button and the certificate should be obtained using the Let's Encrypt servers (ACME v2 API). Should.

Note: Screenshot above shows the "Renew" button instead of "Install" as the LE certificate was already installed at the moment of the screenshot.

Instead of the certificate, an error shows up. By looking at the error details, one can find an error similar to this one:

Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443

This can be caused by multiple reasons, such as:

There is a global redirect from the Plesk domain (plesk.example.com) to the port 8443: https://plesk.example.com is in general redirected to https://plesk.example.com:8443.
The Plesk domain is not at all configured under http with port 80 or https with port 443. Let's Encrypt only works with the default ports 80 and 443.
There is yet another redirect somewhere defined in the system.

In this particular setup, a global redirect for the Plesk domain exists in /etc/nginx/conf.d/:

# cat /etc/nginx/conf.d/zzz-plesk-redirect.conf
server {
listen <PleskIP>:80;
server_name plesk.example.com;
access_log off;
error_log off;

rewrite ^.*$ https://plesk.example.com:8443;

}

server {
listen <PleskIP>:443 ssl;
server_name plesk.example.com;
access_log off;
error_log off;
ssl_certificate /etc/nginx/ssl.crt/wildcard.example.com.crt;
ssl_certificate_key /etc/nginx/ssl.key/wildcard.example.com.key;

rewrite ^.*$ https://plesk.example.com:8443;
}

The redirect makes sense, especially for the (mostly not tech-savvy) customers of this Plesk server. But this redirect now causes problems when the Let's Encrypt verification API tries to validate the domain. By enabling the access logs, the requests can be seen:

3.120.130.29 - - [24/Aug/2021:11:03:36 +0200] "GET /.well-known/acme-challenge/tE36pZxx5vCnK_3RuMg5NZRMVWzggaMkyvKjFeuk30Y HTTP/1.1" 302 138 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
52.39.4.59 - - [24/Aug/2021:11:03:37 +0200] "GET /.well-known/acme-challenge/tE36pZxx5vCnK_3RuMg5NZRMVWzggaMkyvKjFeuk30Y HTTP/1.1" 302 138 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

Nginx receives the request but then responds with the redirect (302) to port 8443. This can be verified with curl:

$ curl https://plesk.example.com/.well-known/acme-challenge/tE36pZxx5vCnK_3RuMg5NZRMVWzggaMkyvKjFeuk30Y -v
[...]
< HTTP/1.1 302 Moved Temporarily
< Server: nginx
< Date: Tue, 24 Aug 2021 09:14:53 GMT
< Content-Type: text/html
< Content-Length: 138
< Connection: keep-alive
< Location: https://plesk.example.com:8443
[...]

Handle .well-known path for Plesk Panel's domain

To adjust the Nginx redirect config, we must first know where Plesk stores the temporary domain validation files (acme-challenges). Interestingly a Plesk bug report hints toward this missing piece of information. The acme-challenge files created by Plesk can be found in /var/www/vhosts/default/htdocs/.well-known/acme-challenges !

With this information, the redirect config can be adjusted:

# cat /etc/nginx/conf.d/zzz-plesk-redirect.conf
server {
listen <PleskIP>:80;
server_name plesk.example.com;
access_log off;
error_log off;

location /.well-known/ {
      alias /var/www/vhosts/default/htdocs/.well-known/;
      default_type text/plain;
}

location / {
    rewrite ^.*$ https://plesk.example.com:8443;
}

}

server {
listen <PleskIP>:443 ssl;
server_name plesk.example.com;
access_log off;
error_log off;
ssl_certificate /etc/nginx/ssl.crt/wildcard.example.com.crt;
ssl_certificate_key /etc/nginx/ssl.key/wildcard.example.com.key;

rewrite ^.*$ https://plesk.example.com:8443;
}

Important here is the location /.well-known/ path in the plain http section. This tells Nginx to use the file system path /var/www/vhosts/default/htdocs/.well-known/ as alias for /.well-known in the URI.

With this config update in place and Nginx reloaded, the HTTP challenge from the Let's Encrypt API finally works (response status 200):

18.159.196.172 - - [24/Aug/2021:11:17:30 +0200] "GET /.well-known/acme-challenge/M_BJMgIt3IawUTTYSczKE5nKGwdR_cGG0x_5GEVVT5s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
3.19.56.43 - - [24/Aug/2021:11:17:31 +0200] "GET /.well-known/acme-challenge/M_BJMgIt3IawUTTYSczKE5nKGwdR_cGG0x_5GEVVT5s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
52.39.4.59 - - [24/Aug/2021:11:17:32 +0200] "GET /.well-known/acme-challenge/M_BJMgIt3IawUTTYSczKE5nKGwdR_cGG0x_5GEVVT5s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
64.78.149.164 - - [24/Aug/2021:11:17:33 +0200] "GET /.well-known/acme-challenge/M_BJMgIt3IawUTTYSczKE5nKGwdR_cGG0x_5GEVVT5s HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

And in Plesk the certificate was successfully created!

Professional Plesk and Confixx consulting

Looking for help in installing or hosting Plesk? Or want to migrate a Parallels Confixx server to Plesk? At Infiniroot we've helped our existing customers on exactly these topics. Just contact us to get to know more.

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.

Blog Tags:

AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Database Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Office OpenSearch PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMWare VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder