bg-tutorials

How to Install an ACME SSL Certificate on cPanel

cPanel’s built-in AutoSSL issues free domain-validated certificates and nothing else, so a certificate from a commercial certificate authority has to come from somewhere else. With acme.sh you can issue one over ACME with External Account Binding and have it installed into cPanel automatically at every renewal, using the deploy hook acme.sh ships for exactly this purpose.

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. Manual reinstallation through the cPanel interface was tolerable once a year and will not be at 47 days.

What you will need

  • Shell access to the cPanel account, either the built-in Terminal or SSH from outside. Some hosts disable both, and without one this method is not available to you.
  • The account’s document root, normally something like /home/username/public_html.
  • Your CA’s ACME directory URL, EAB Key ID and EAB HMAC Key, from your CA account portal.
  • DNS already pointing at the hosting account, and port 80 reachable, since webroot validation is served by the same web server as the site.

Step 1: Open a shell

In cPanel, look under Advanced for Terminal and accept the first-use prompt. It is the quickest route and it logs you in as the account user, which is what the deploy hook expects.

An external SSH client works equally well and is steadier for long operations. You will need the host name or IP, the port, which some providers move off 22, and your credentials. Either way, stay as the account user rather than root. The deploy hook behaves differently for root, as Step 5 explains.

Step 2: Install acme.sh

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

The installer prints where it put itself, normally /home/username/.acme.sh/, and adds a cron entry that checks daily for certificates due for renewal. If acme.sh is not found afterwards, the shell has not picked up the new path yet; call it directly as ~/.acme.sh/acme.sh or open a fresh session.

Step 3: Register the ACME account

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]"

This runs once per certificate authority. The Key Identifier is the shorter of the two values and the HMAC Key the longer one; paste both exactly as the CA presented them. The HMAC key is already base64url encoded, so re-encoding it or picking up a leading space is the usual reason a registration fails while both values look right. Some CAs also issue EAB credentials that are valid for a single registration, so a second attempt after a failure may need a fresh pair.

Pass --server on every command from here on. acme.sh has defaulted to ZeroSSL since version 3.0, so leaving it out sends the request to an authority you did not intend.

Step 4: Issue the certificate

Webroot validation writes the challenge file into the site’s own document root, so the existing web server serves it and nothing else has to be configured.

acme.sh --issue \
  -d example.com \
  -d www.example.com \
  -w /home/username/public_html \
  --server "https://acme.yourca.example/v2/DV"

Add a -d for each name. If you are unsure of the document root, cPanel shows it on the main dashboard under General Information, and File Manager will copy the path of any folder for you.

Two things commonly break this step. A redirect that forces HTTPS before the challenge file can be read over plain HTTP, which is worth checking in .htaccess, and a commercial order whose names were fixed when it was placed, since a name that is not on the order is refused however well validation works.

On success the files land in ~/.acme.sh/example.com/. You will not copy any of them by hand.

Step 5: Deploy into cPanel

acme.sh --deploy -d example.com --deploy-hook cpanel_uapi

This is the whole installation. The hook calls cPanel’s own uapi command to install the certificate, which is why it works on shared hosting where you have no administrative access: it uses the same interface the control panel does.

Three details are worth knowing, because they explain results that otherwise look surprising.

  • It installs to every matching domain, not just the one you named. By default the hook asks cPanel for the account’s full domain list, main domain, subdomains, addon domains and parked domains, keeps the ones the certificate actually covers, and installs to each. That is what makes a wildcard or multi-name certificate work in one command.
  • It only needs a user name when you run it as root. As the account user it works with no configuration. From a root shell it stops and tells you to set DEPLOY_CPANEL_USER to the target account, which is the same message people mistake for a broken hook.
  • The uapi command has to exist on the server. If the hook reports it cannot find uapi, you are either not on a cPanel server or not in an environment where it is exposed.

Confirm the result in cPanel under SSL/TLS, then Manage SSL sites, where the domain should now list your certificate and its issuer.

acme.sh saves the hook against the domain, so every later renewal runs it again with no further action from you.

Step 6: Understand when it renews

acme.sh’s default is to renew 30 days after issuance. That is worth reading twice, because it is very commonly described as renewing 30 days before expiry, and the two are not the same: on a 200-day certificate the default renews after about a month, not five months in.

Two things adjust it. A negative value for --days switches the meaning to days before expiry, and where the certificate authority publishes ACME Renewal Information, current acme.sh follows the window the CA suggests instead of its own schedule. The default is safe either way; it is the description that is usually wrong.

Test the full path once, issuance through deployment:

acme.sh --renew -d example.com --force

This performs a real renewal rather than simulating one, so it consumes a certificate from your CA and counts against rate limits. Run it once, not in a loop. Then check 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, including whether the intermediate certificate is being served with the leaf.

Common problems

  • acme.sh is not found after installing. The current shell has not picked up the change. Run ~/.acme.sh/acme.sh directly or start a new session.
  • Validation fails with a 404 or a redirect. Confirm the webroot path matches the domain you are issuing for, which is easy to get wrong on an account hosting several sites, and check that .htaccess does not force HTTPS before the challenge path is served.
  • The hook asks for DEPLOY_CPANEL_USER. You are running as root. Either switch to the account user or export that variable with the account name.
  • The certificate installs on fewer domains than expected. The hook only deploys to names the certificate covers. Check the certificate actually includes them, rather than assuming the account list is the target.
  • The certificate is replaced later by a different one. AutoSSL is configured by the server administrator in WHM, not from your account, and depending on how it is set it can take over domains it considers uncovered or expiring. If a certificate you installed is swapped out, that is the question to put to your host.
  • You need more detail. Add --debug to any acme.sh command to see the exchange with both the CA and cPanel.

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

Frequently Asked Questions

What if I do not know my webroot path?

cPanel shows the document root on its main dashboard under General Information. You can also open File Manager, navigate to the site’s folder, usually public_html, and copy the path from there. Use that value with the -w option, written with two hyphens if you use the long form --webroot.

Can I cover subdomains and staging sites?

Yes, by adding a -d for each name on the issue command, again with two hyphens for the long form --domain. The deploy hook then installs the finished certificate to each of those domains on the account automatically, so there is nothing extra to do at deployment time.

Does this work on shared hosting?

Yes, provided your host gives you shell access through Terminal or SSH. Nothing here needs root: the deploy hook uses cPanel’s own user-level API, which is exactly the interface a shared account is meant to use. If shell access is disabled and the host will not enable it, this method is not available and you are back to uploading certificates by hand.

What happens if I lose shell access later?

The cron entry acme.sh installed keeps running as your account, so renewals and deployments continue without you logging in. What you lose is the ability to change anything, so if a renewal starts failing you would have to fall back to installing certificates manually through the cPanel interface until access is restored.

Will AutoSSL interfere with the certificate I installed?

It can, and the decision is not yours to make from inside the account. AutoSSL runs at the server level and its behaviour toward certificates it did not issue is set by the administrator in WHM. On your own server you can check that configuration; on shared hosting you would need to ask the provider. If a certificate you deployed is later replaced by a different one, that is where to look first.

For more on the protocol behind all of this, see what the ACME protocol is and our ACME SSL certificates page. To install a certificate through the interface instead, see our guides to generating a CSR in cPanel and installing an SSL certificate on cPanel.

Save 10% on SSL Certificates when ordering from SSL Dragon today!

Fast issuance, strong encryption, 99.99% browser trust, dedicated support, and 25-day money-back guarantee. Coupon code: SAVE10

A detailed image of a dragon in flight
Written by

I've been writing for SSL Dragon for over 10 years, focusing entirely on SSL certificates and digital security. My job is to take complex cybersecurity topics and strip away the jargon, making sure you get the clear, practical information you need to keep your website safe.