HestiaCP: enable Let's Encrypt for web and mail

HestiaCP can request Let's Encrypt certificates for your websites and for the mail hostname directly from the panel or the command line, so visitors and mail clients stop seeing certificate warnings. This guide walks through both, then shows how to confirm the certificate is valid and renewing.

The web certificate covers example.com and www.example.com; the mail certificate covers mail.example.com, which is the hostname your mail clients connect to for IMAP, POP3 and SMTP.

Before you start

You need:

• A Linux VPS with HestiaCP already installed. If not, follow how to install HestiaCP on a Linux VPS.
• A domain added in HestiaCP under a user account, with a DNS zone. See HestiaCP: add a domain, DNS zone and mail domain.
• DNS records pointing at your server: an A record for example.com and www.example.com, and an A record for mail.example.com, all to 203.0.113.10.
• Ports 80 and 443 open. Let's Encrypt validates over HTTP-01, so port 80 must be reachable from the internet during issuance.
• SSH access as root, or a sudo-capable account, and the HestiaCP admin login for the web UI at https://203.0.113.10:8083.

Enable Let's Encrypt SSL for a website in HestiaCP

Option 1: the web UI

1. Log in to HestiaCP as admin.
2. Open WEB and click the domain example.com.
3. Tick SSL Support, then tick Lets Encrypt.
4. Optionally tick Enable automatic HTTPS redirect so plain HTTP visitors are sent to HTTPS.
5. Click Save. HestiaCP requests the certificate in the background. Give it about 30 seconds, then reload the page.

Option 2: the CLI

Run this as root. The first argument is the HestiaCP user that owns the domain, the second is the domain, and the third is a single comma-separated list of aliases to include in the same certificate.

/usr/local/hestia/bin/v-add-letsencrypt-domain deploy example.com www.example.com

A successful run prints OK. Anything else is an error you need to read — the message usually names the failing domain.

Confirm the certificate is present and valid:

/usr/local/hestia/bin/v-check-letsencrypt-domain deploy example.com

The files land in the user's web config directory:

ls -l /home/deploy/conf/web/example.com/ssl/

You should see example.com.crt, example.com.key and example.com.ca. HestiaCP writes the web server configuration to use them, so no manual Nginx or Apache edit is needed.

Issue a Let's Encrypt certificate for the mail hostname

Mail clients connect to mail.example.com, not to example.com. Without a certificate for that hostname, every client shows a mismatch warning.

Option 1: the web UI

1. Open MAIL and click the mail domain example.com.
2. Tick SSL Support and Lets Encrypt.
3. Click Save.

Option 2: the CLI

The fourth argument is the mail flag. Pass an empty string for aliases if you do not need any, then yes to also cover the mail hostname.

/usr/local/hestia/bin/v-add-letsencrypt-domain deploy example.com '' yes

After the certificate is issued, reload the mail services so they pick up the new files:

systemctl restart dovecot
systemctl restart exim4

Your mail client settings then become: server mail.example.com, IMAP on port 993 with SSL/TLS, SMTP on port 587 with STARTTLS, and your full email address as the username.

Keep certificates renewing

HestiaCP renews certificates automatically through a scheduled job. You do not need to add your own cron entry.

Check that the job exists:

cat /etc/cron.d/hestia

To force a renewal check right now, run:

/usr/local/hestia/bin/v-update-letsencrypt-ssl

This walks every domain with Let's Encrypt enabled and renews the ones close to expiry. It is safe to run manually.

Check it works

Load https://example.com in a browser and confirm the padlock. Open the certificate details and check the subject matches your domain and the issuer is Let's Encrypt.

From the server, inspect the served certificate:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Do the same for the mail hostname on the IMAPS port:

openssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Both commands should print a subject containing your hostname and a notAfter date roughly 90 days out. If the subject shows mail.example.com for the first command, you issued the mail certificate but not the web one.

Troubleshooting

• "Let's Encrypt validation status 400" or "Invalid response... 404" — the HTTP-01 challenge could not be fetched. Check that dig +short example.com returns 203.0.113.10, that port 80 is open in your firewall, and that no other service is answering on that port.
• "too many certificates already issued for exact set of domains" — you hit a Let's Encrypt rate limit. Stop retrying, wait for the window to pass, and fix the underlying validation problem first.
• Certificate issued but the browser still shows the old one — the web server has not reloaded. Run systemctl reload nginx and, if you use Apache behind it, systemctl reload apache2 (or httpd on RHEL-family systems).
• Mail client warns about a hostname mismatch — the certificate covers example.com but the client connects to mail.example.com. Reissue with the mail flag as shown above.
• Renewal never happens — check /var/log/hestia/ for the renewal run and confirm the cron entry is intact. If the job is missing, reinstall or update the panel rather than recreating it manually.

Next steps

• HestiaCP: add a domain, DNS zone and mail domain if you still need to create the records the certificate depends on.
• How to install HestiaCP on a Linux VPS for a clean starting point.
• Postfix and Dovecot mail server setup on a Linux VPS to understand what sits behind the panel's mail stack.
• Secure Nginx with a free Let's Encrypt SSL certificate if you later run a web server outside the panel.