How to Secure the ISPConfig Control Panel with an SSL Certificate

This guide shows you how to secure the ISPConfig control panel with a valid SSL certificate, so that the panel loads over an encrypted https connection with no browser warning. It is written for clients who run their own self-managed ISPConfig server, meaning a virtual or dedicated server on which you hold root and SSH access. The control panel, also called the ISPConfig web interface or admin interface, listens on port 8080. When no trusted certificate is in place, ISPConfig falls back to a self-signed one, which encrypts the traffic but makes your browser show a "not secure" or "your connection is not private" warning because nothing external vouches for it. Replacing that with a free certificate from Let's Encrypt, a trusted public certificate authority, removes the warning and proves the panel genuinely belongs to your server. SSL certificates are also called TLS certificates; the two terms mean the same thing here.

If Noiz manages your server for you, the panel certificate is already handled and you do not need to follow this guide. It applies only when you administer the ISPConfig server yourself.

Last reviewed: 27 July 2026, against ISPConfig 3.3.1p1. This guide is written for Noiz hosting and is kept current against ISPConfig. It complements, and does not replace, the official ISPConfig documentation linked below.

Official Documentation Reference

• ISPConfig 3 User Manual: the official manual; enabling SSL for the ISPConfig web interface is covered in section 6.2, and the control panel port is described in section 4.2.
• Securing ISPConfig With a Free Let's Encrypt SSL Certificate (ISPConfig blog): the official article on using Let's Encrypt for the panel, noting that ISPConfig 3.2 and newer do this automatically through the built-in acme.sh client.
• HowtoForge: Securing ISPConfig With a Free Let's Encrypt SSL Certificate: community walkthrough that states clearly that from ISPConfig 3.2 onward Let's Encrypt is built in and the panel certificate is configured for you at install time.
• Let's Encrypt: Getting Started: background on the free certificate authority ISPConfig uses, including how domain validation works over ports 80 and 443.
• acme.sh project page: the ACME client that ISPConfig 3.2 and newer use behind the scenes to request and renew the certificate.

Prerequisites

• You know how to log in to the ISPConfig control panel as the admin user, which you need for the second method below and to confirm the result.
• Root or sudo access to the server over SSH, because the recommended method runs a command-line script.
• The server has a fully qualified hostname (FQDN), for example server1.yourdomain.com (an example value), set as its system hostname. Confirm it with hostname -f.
• That hostname resolves in public DNS to the server's public IP address, through an A record (and an AAAA record if you use IPv6).
• Ports 80 and 443 are open to the internet. Let's Encrypt validates ownership over those ports, not over 8080.
• The server runs ISPConfig 3.2 or newer, so Let's Encrypt is built in. Noiz servers run 3.3.1p1, which meets this.
• A short maintenance window, because issuing the certificate briefly restarts the web, mail and FTP services.

How Panel SSL Works in ISPConfig 3.3

Since version 3.2, ISPConfig manages Let's Encrypt for every service itself, using the acme.sh client rather than the older Certbot scripts. On a fresh install, if the server hostname already resolves publicly and ports 80 and 443 are reachable, ISPConfig requests a Let's Encrypt certificate for the hostname and points the control panel at it automatically. In that case there is nothing more to do.

You need this guide when that did not happen: the hostname was not yet pointed at the server during installation, the firewall was closed at the time, or the server was installed before DNS was ready. In those cases the panel keeps its self-signed certificate until you ask ISPConfig to issue a proper one.

The panel certificate always lives in one place, whichever web server you run:

/usr/local/ispconfig/interface/ssl/ispserver.crt      the certificate and chain
/usr/local/ispconfig/interface/ssl/ispserver.key      the private key
/usr/local/ispconfig/interface/ssl/ispserver.pem      key and certificate combined
/usr/local/ispconfig/interface/ssl/ispserver.bundle   the certificate authority chain, used only if present

The panel virtual host (/etc/apache2/sites-available/ispconfig.vhost on Apache, or /etc/nginx/sites-available/ispconfig.vhost on nginx) references ispserver.crt and ispserver.key by these fixed paths, so nothing has to be re-pointed when the certificate changes. When ISPConfig obtains a Let's Encrypt certificate for the hostname, acme.sh writes the new certificate and key straight into those two files, and ISPConfig rebuilds ispserver.pem from them. Mail and FTP are then attached by symbolic link: Postfix's smtpd.cert and smtpd.key point at ispserver.crt and ispserver.key, Dovecot reads the Postfix pair, and Pure-FTPd's /etc/ssl/private/pure-ftpd.pem points at ispserver.pem. That is why one certificate covers the panel, mail and FTP at once.

Method 1: Issue the Certificate With the ISPConfig Updater

This is the recommended way on ISPConfig 3.3. The updater has a built-in step that requests a fresh Let's Encrypt certificate for the hostname and wires the panel, mail and FTP services to it in one pass. It does not require you to create a website first.

Step 1: Confirm the Hostname Resolves and the Ports Are Open

Log in to the server over SSH and check that the hostname points at this server in public DNS:

hostname -f
dig +short A server1.yourdomain.com

The dig result must return the server's own public IP address. If it returns nothing or the wrong address, fix the DNS A record first and wait for it to propagate, otherwise the certificate request will fail. Confirm that inbound ports 80 and 443 are open in any firewall in front of the server. The validation request arrives on those ports, so a block there is the most common cause of failure.

Step 2: Run the ISPConfig Updater

As root, start the updater:

ispconfig_update.sh

At Select update method (stable,git-stable,git-master) [stable]: choose stable, which is the method ISPConfig documents for production systems. Allow the updater to create a backup when prompted, and at Reconfigure Services? (yes,no,selected) [yes]: accept yes. Reconfiguring services is what lets the updater refresh the certificate.

Step 3: Answer the SSL Certificate Prompt

During the reconfigure stage the updater reaches this question:

Create new ISPConfig SSL certificate (yes,no) [no]:

Type yes and press Enter. ISPConfig first checks that the hostname's A or AAAA record already resolves to one of the server's own public addresses. If it does not, the updater asks Ignore DNS check and continue to request certificate?. Treat that question as a warning that the DNS is wrong: answer n, correct the record, and start again, because forcing past it almost always ends in a failed validation.

With the check passed, ISPConfig asks acme.sh to request a Let's Encrypt certificate for the hostname, writes it into ispserver.crt and ispserver.key, and rebuilds ispserver.pem. Two follow-up questions, Symlink ISPConfig SSL certs to Postfix? and Symlink ISPConfig SSL certs to Pure-FTPd?, both default to y; accept both so that mail and FTP present the same certificate as the panel. If Let's Encrypt cannot validate the hostname for any reason, ISPConfig falls back to a self-signed certificate so the panel still works; in that case see the Troubleshooting section.

Let the updater finish. It restarts the affected services at the end.

Step 4: Verify the New Certificate

Check who issued the certificate that is now in place:

openssl x509 -in /usr/local/ispconfig/interface/ssl/ispserver.crt -noout -issuer -subject -dates

The issuer should name Let's Encrypt and the subject should match your hostname. acme.sh also keeps its own copy under /root/.acme.sh/, in a directory named after the hostname with an _ecc suffix, so ls /root/.acme.sh/ is a quick second confirmation that a certificate was really issued. Now check the certificate the panel actually presents:

echo | openssl s_client -connect server1.yourdomain.com:8080 -servername server1.yourdomain.com 2>/dev/null | openssl x509 -noout -issuer -subject -dates

This should report the same issuer and subject, which proves the panel is serving the new certificate and not a cached one. Finally, open https://server1.yourdomain.com:8080 in a browser. The address bar should show a padlock with no warning. Use the exact hostname, not the IP address, because a public certificate authority cannot certify a bare IP.

Method 2: Issue the Certificate Through a Hostname Website

Use this alternative when the updater step reports success but the certificate still comes back self-signed, or when you prefer to manage the hostname the same way as any other site. You create a website in ISPConfig whose domain is the server hostname, let Let's Encrypt issue against it, then adopt that certificate for the panel.

Step 1: Add the Server Hostname as a Website

1. Log in to the control panel as admin.
2. Go to Sites > Websites > Website, then click Add new website.
3. In Domain, enter the server hostname, for example server1.yourdomain.com (an example value).
4. Set Auto-Subdomain to none. It defaults to www., which pulls www.server1.yourdomain.com into the certificate request, and that name rarely exists for a server hostname.
5. Tick Let's Encrypt SSL, which ticks SSL for you. Leave the remaining defaults alone.
6. Click Save.

Step 2: Wait for Let's Encrypt to Issue

ISPConfig creates the site first and only then turns Let's Encrypt on, so the request runs a moment after the save rather than during it. It normally completes within a minute or two, provided the hostname resolves and ports 80 and 443 are open. You can confirm issuance from the server:

ls -l /root/.acme.sh/server1.yourdomain.com_ecc/

A certificate file appearing in that directory means the request succeeded. If instead the Let's Encrypt SSL and SSL boxes have quietly cleared themselves when you reopen the site, the request failed and ISPConfig turned them back off; work through the Troubleshooting section before continuing.

Step 3: Point the Panel Certificate at It

With a valid Let's Encrypt certificate now present for the hostname, run the updater again and answer yes to the SSL prompt exactly as in Method 1, Steps 2 and 3. This time ISPConfig finds the certificate that already exists for the hostname and installs it into the ispserver files rather than requesting a new one. Verify the result with Step 4 of Method 1.

Keeping the Certificate Valid

Let's Encrypt certificates last 90 days. ISPConfig, through acme.sh, installs a scheduled task that renews the certificate automatically around the 60-day mark, well before it expires. At each renewal acme.sh writes the new certificate back into the same ispserver files and runs an ISPConfig hook that rebuilds ispserver.pem and restarts the web, mail, FTP and database services, so every one of them picks up the fresh certificate with no action from you. You do not need to repeat this procedure at each renewal; you would only repeat it if you rebuild the server, change its hostname, or move it to a new IP address.

To confirm the renewal schedule is in place, check the root crontab for the acme.sh entry:

crontab -l | grep acme

Troubleshooting

• The certificate came back self-signed. Let's Encrypt could not validate the hostname. Confirm dig +short A server1.yourdomain.com returns this server's public IP, and that ports 80 and 443 are open from the internet. Review the client log at /var/log/ispconfig/acme.log for the exact reason, then rerun Method 1.
• The browser still warns after issuing. The old certificate may be cached in the browser or the web server was not reloaded. Restart the panel's web server, either systemctl restart apache2 or systemctl restart nginx depending on your install, then close and reopen the browser or do a hard refresh.
• Validation times out on port 80. A firewall rule or an automatic security block can silently drop the incoming validation request. Make sure inbound port 80 is permitted from any address during issuance, as Let's Encrypt does not announce which of its servers will connect.
• "Too many certificates already issued." Let's Encrypt limits how many identical certificates you can request in a rolling week. If you have retried many times, wait an hour or a day and try once more rather than repeating immediately.
• The certificate names the wrong host. A public certificate is tied to the exact hostname. Always open the panel at https://server1.yourdomain.com:8080, using the certified hostname, not at https://<ip-address>:8080. IP addresses cannot receive a Let's Encrypt certificate.
• A CAA record is blocking issuance. If the domain has a CAA DNS record that names a different authority, Let's Encrypt refuses to issue. Either remove it or add letsencrypt.org to the allowed authorities.
• You run more than one ISPConfig server. Each server certifies its own hostname. Repeat the procedure on every server whose panel you want secured.

If the certificate will not issue after these checks, or you are unsure whether a firewall or DNS change is safe to make, open a support ticket with the Noiz support team. Include your server hostname, the output of dig +short A server1.yourdomain.com, and the last few lines of /var/log/ispconfig/acme.log, and the Noiz team will help you get the panel secured.