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

Written by - 0 comments

Published on - 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):

Plesk SSL TLS certificates

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.

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.

RSS feed

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   Icingaweb   Icingaweb2   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   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   


Update cookies preferences