How to Install an ACME SSL Certificate on Plesk

Plesk can issue and renew certificates from a commercial certificate authority over ACME without any scripting, using its own ACME SSL extension. That extension supports External Account Binding, which is the part commercial CAs require and the reason people assume the panel cannot do it. This guide covers that route first, then the manual acme.sh route for the cases it does not cover.

Quick answer: install the SSL It! and ACME SSL extensions from the Extensions Catalog, then go to Websites & Domains, select the site, open the Dashboard tab and click SSL/TLS Certificates. Supply your CA’s ACME directory URL along with the EAB Key ID and EAB HMAC Key, choose whether to include the wildcard and mail names, and issue. Plesk handles validation, installation, assignment and renewal from then on. Only fall back to running acme.sh over SSH if the extension is unavailable to you.

Under CA/Browser Forum ballot SC-081v3, publicly trusted TLS certificates have been capped at 200 days since March 15, 2026, dropping to 100 days on March 15, 2027 and to 47 days on March 15, 2029. On a panel hosting dozens of sites, that is the difference between an annual task and a continuous one, which is why the automated route is worth setting up properly.

Before you start

• A server running Plesk Obsidian where you can install extensions. On shared hosting you usually cannot, and the manual route needs SSH, which shared plans rarely grant.
• A live domain with an A or AAAA record pointing at the server.
• Your CA’s ACME directory URL, EAB Key ID and EAB HMAC Key, generated in your CA account portal.
• A reachable validation path. HTTP-01 needs port 80 open from the internet. DNS-01 is the alternative and the only route to a wildcard.

Method 1: The ACME SSL extension

This is the route to use unless something specific rules it out. Plesk does the validation, writes the certificate into the panel, assigns it to the site and renews it, so there is no script of yours in the path to break later.

Step 1: Install the extensions

From the Extensions Catalog, install both SSL It! and the ACME SSL extension. SSL It! is the certificate management interface; the ACME SSL extension is what adds support for certificate authorities other than the one Plesk ships with, and it plugs into the same screens.

Step 2: Request the certificate

1. Go to Websites & Domains and select the site.
2. Open the Dashboard tab and click SSL/TLS Certificates.
3. Choose to request a certificate from a custom ACME authority, and fill in the ACME directory URL your CA gave you.
4. Enter the EAB Key ID and EAB HMAC Key. Both are optional fields in the form, because not every authority uses External Account Binding, but a commercial CA will require them.
5. Pick which names to include. Secure the domain name is preselected; you can also request a wildcard and cover mail and webmail with the same certificate.
6. Issue.

Paste the HMAC key exactly as the CA presented it. It is already base64url encoded, so re-encoding it or picking up a trailing space is the usual cause of a registration that fails while both values look correct.

Step 3: Or do the same thing from the command line

The extension ships a CLI, which is the sane way to cover many domains at once:

plesk ext sslit --certificate -issue -domain example.com \
  -directory-url https://acme.yourca.example/v2/DV \
  -kid YOUR_EAB_KEY_ID \
  -hmac YOUR_EAB_HMAC_KEY \
  -secure-domain

Add -wildcard when you need the wildcard name as well. Run the command with no arguments to see the full option list on your own build, since extensions gain options between releases.

The extension handles both HTTP-01 and DNS-01 challenges. Renewal is Plesk’s job from here, and because the certificate lives in the panel as a normal certificate object, the assignment you make once survives every renewal.

Method 2: Running acme.sh yourself

Use this only when the extension is not an option, for example when you cannot install extensions on the server. It is more work and, unlike the platforms acme.sh integrates with directly, there is no Plesk deploy hook in acme.sh, so the step that puts the renewed certificate into the panel is a script you write and maintain. Everything here needs root or sudo, so it does not apply to shared hosting.

Step 1: Find the document root and get a shell

In Plesk, open Websites & Domains, select the domain, open Hosting Settings and copy the Document root. It normally looks like /var/www/vhosts/example.com/httpdocs. If SSH is disabled for the subscription, enable it under Websites & Domains, the domain, then Web Hosting Access, setting shell access to /bin/bash.

ssh [email protected]

Step 2: Install acme.sh and register the account

curl https://get.acme.sh | sh -s [email protected]
source ~/.bashrc
acme.sh --version

acme.sh --register-account \
  --server https://acme.yourca.example/v2/DV \
  --eab-kid "YOUR_EAB_KEY_ID" \
  --eab-hmac-key "YOUR_EAB_HMAC_KEY" \
  --accountemail "[email protected]"

Registration is once per CA. Pass –server on every later command too, because acme.sh has defaulted to ZeroSSL since version 3.0 and will otherwise talk to the wrong authority. Note that the client installs itself under the home directory of whichever account you used, so a root install lives in /root/.acme.sh/ and a non-root install does not.

Step 3: Make the challenge path reachable

Create the directory and prove it is served over plain HTTP before involving the CA:

mkdir -p /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge
echo "ok" > /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge/testfile
curl -I http://example.com/.well-known/acme-challenge/testfile

You want a 200 back. If the site forces HTTPS, the redirect will break validation unless the challenge path is exempted. On Apache, add this at the top of the .htaccess file in the document root:

RewriteEngine On
RewriteRule ^\.well-known/acme-challenge/ - [END]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The backslash escapes the dot so the pattern matches a literal .well-known rather than any character, and [END] stops rewriting outright rather than merely ending the current pass.

If nginx is in front of Apache, which is the common Plesk arrangement, the .htaccess file never sees the request. Add the exemption in Plesk instead, under Websites & Domains, the domain, then Apache & nginx Settings, in the Additional nginx directives field:

location ^~ /.well-known/acme-challenge/ {
    root /var/www/vhosts/example.com/httpdocs;
    allow all;
    try_files $uri =404;
}

Step 4: Issue the certificate

acme.sh --issue \
  -d example.com \
  -d www.example.com \
  -w /var/www/vhosts/example.com/httpdocs \
  --server https://acme.yourca.example/v2/DV

Add a -d for each name. Note that a commercial order usually fixes its names in advance, so a name that is not on the order is refused however correct your validation is.

Step 5: Install the certificate and wire up the reload

acme.sh keeps its working copies in its own directory and its documentation asks you not to use those paths directly, because the layout is internal and can change. Install to a stable location of your own and give acme.sh the command to run after each renewal:

mkdir -p /etc/ssl/acme/example.com

acme.sh --install-cert -d example.com \
  --key-file       /etc/ssl/acme/example.com/privkey.pem \
  --fullchain-file /etc/ssl/acme/example.com/fullchain.pem \
  --reloadcmd      "/usr/local/bin/plesk-acme-deploy.sh"

Pointing the install paths back at acme.sh’s own directory, as some guides do, achieves nothing: acme.sh compares source and destination and skips the copy when they are the same file. The point of this step is to get the files somewhere your own script can rely on.

The deploy script imports the files into Plesk and reconfigures the domain. The exact flags for Plesk’s certificate utility differ between versions, so confirm them on your own server rather than copying them blind:

plesk bin certificate --help
plesk bin domain --help

The script then follows the same three moves: create or update a named certificate in the panel from the two files, attach that certificate to the domain with SSL enabled, and reconfigure the domain so the web server picks it up. If plesk is not on the path when the script runs, call it as /usr/sbin/plesk, since the renewal runs from cron rather than from your shell. Make the script executable with chmod +x before pointing acme.sh at it.

Step 6: Check the renewal schedule

acme.sh’s installer adds a daily cron entry, and its default is to renew 30 days after issuance. That is worth reading carefully, because it is commonly described as renewing 30 days before expiry, which is a different thing entirely: on a 200-day certificate the default renews after about a month, not five months later.

Two mechanisms adjust it. A negative value for –days switches the meaning to days before expiry rather than days after issuance. And where the CA publishes ACME Renewal Information, current acme.sh follows the window the CA suggests in preference to its own schedule, which is what keeps automation correct as certificate lifetimes fall.

Test the whole path once rather than waiting to find out:

acme.sh --renew -d example.com --force
tail -n 60 ~/.acme.sh/acme.sh.log

Certificate authorities apply rate limits, so run this once rather than in a loop. Then confirm what the site actually serves:

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

The SSL Checker reports the same from outside your network, including whether the intermediate certificate is being served alongside the leaf.

Common problems

• Validation returns 404 or times out. Re-check the document root against what Plesk reports for that domain, confirm port 80 is open through the server firewall and the provider’s, and make sure the challenge exemption is in the right layer, nginx rather than .htaccess when nginx fronts Apache.
• Unauthorized or invalid response. The CA reached something but not the token. A CDN or WAF in front of the site is the usual culprit, so pause proxying or exempt the /.well-known/ path while issuing. Check the A or AAAA record actually points at this server.
• The certificate renews but the site still serves the old one. The reload step did not run or did not succeed. Run the deploy script by hand and read its output, confirm it is executable, and remember it runs from cron without your shell’s environment or working directory.
• The Plesk command is not found inside the script. Use the full path, /usr/sbin/plesk.
• Registration fails though the credentials look right. The HMAC key is already base64url, so do not re-encode it, and check that the directory URL matches the endpoint the credentials were issued against.

For error strings that come from the protocol rather than from Plesk or acme.sh, such as badNonce, unauthorized or a CAA record refusing issuance, see our guide to fixing ACME SSL certificate errors.

Frequently Asked Questions

For more on the protocol behind all of this, see what the ACME protocol is and our ACME SSL certificates page. For a certificate you install by hand, see our guides to generating a CSR in Plesk and installing an SSL certificate on Plesk.