Solutions to common problems may be listed here.


By default, the daemon will output logging to the file at: /var/log/letsencrypt-cpanel.log. On CentOS 7+ logging is managed by systemd and can be accessed via

journalctl -u letsencrypt-cpanel -l

If you are experiencing any issues with the daemon, we recommend checking here first.

Any errors generated by the cPanel CGI plugin will be logged to: /usr/local/cpanel/logs/error_log
If you are experiencing any issues accessing or using the plugin from cPanel, check here first.

Licence error when visiting the plugin page or using the CLI

Please check that your licence is active and that you are not on an expired trial licence:

/usr/local/bin/le-cp self-test

If the self-test doesn’t explain the issue, please send us your server’s support data and contact us with the support ID reported:

/usr/local/bin/le-cp send-logs

Failed to issue certificate: The Let’s Encrypt™ HTTP challenge failed - is .well-known/acme-challenge accessible in your webroot?

First, you need to check that you can actually access files within the directory. If you cannot, then the issue is likely an .htaccess rule blocking access. Try including the following lines at the top of your .htaccess file:

RewriteEngine On
RewriteRule ^\.well-known - [L]

You can also check your domains on to see if there are any issues with your domain or webserver that may cause issues.

Rate limit error - too many certificates for this domain

Most likely, you have issued and deleted certificates of the same root domain too many times.

You can check what certificates have been issued recently using, lectl or

In most cases, you will need to wait for the rate limit to subside. We have no control over rate limits and cannot reset them.

Rate limit error - too many registrations

The server may have hit a rate limit for too many new account registrations for a single IP address. In this case, you should be able to proceed within 24 hours.

Icon not visible in cPanel

If the Let’s Encrypt™ icon is not visible in the cPanel list even though the link is present, this is most likely a caching issue. If forcing a refresh in your browser (Control+R) does not fix this, the plugin may need to be re-installed to refresh the cPanel icon cache for the plugin.

This feature requires the “sslinstall” option and is not enabled on your account.

The plugin relies on each cPanel account having access to the SSL/TLS feature in order to install certificates via the user interface and at renewal time.

Visit WHM->Feature Manager and ensure that the SSL/TLS features are enabled in the feature lists used by your users’ packages.

Self-Test - Can talk to WHM API ………… FAILED: 403 Forbidden Access denied.

If you get this error, then the plugin is unable to talk to the WHM API.

From cPanel 64 onwards, the plugin uses the API Token feature in cPanel to do this. The API Token used is automatically generated by the plugin and stored in /etc/.letsencrypt-cpanel-api-token.

You can test whether this token works with the following request:

curl -vvv -H "Authorization: whm root:$(cat /etc/.letsencrypt-cpanel-api-token)" \
-i -k https://$(hostname):2087/json-api/version

How to fix:

  1. Try the above request to determine if:
  • The request is being sent to the correct server (it should go back to the local server)
  • The request succeeds (does not get a Forbidden or Access Denied error)
  1. If the request fails, try to re-generate the token:
  • rm -f /etc/.letsencrypt-cpanel-api-token
  • service letsencrypt-cpanel restart
  • le-cp self-test
  1. If that fails, then please check that WHM Host Access Control is allowing access to whostmgrd.
  • In a new cPanel installation, this is usually not the issue.
  • The IP address that needs to be permitted will be the one shown by the above curl command.

Self-Test - Can talk to RPC plugin … Failed to dial host:5960 … desc: = “transport: x509: …”

Experiencing this error indicates that the service certificate on your server has become invalid and the plugin command line interface can no longer communicate with the plugin securely.

Try the following solutions, in this order, testing if the problem is solved in between:

  1. Restart the service: service letsencrypt-cpanel restart.
  2. Try having the plugin replace the server’s service certificate, and wait 3-4 minutes:
  • FLEETSSL_INSECURE_RPC=y /usr/local/bin/le-cp hostcert enable
  1. Update /etc/letsencrypt-cpanel.conf with the following options, restart the service, and wait 3-4 minutes:
  • "insecure": true
  • "hostcert": true
  1. If all of the above fails, please send us your logs (le-cp send-logs) and send us the support ID along with a description of your problem.

Engintron: Renewed certificates aren’t being installed

Engintron, a third party nginx integration for WHM/cPanel, is not officially supported by FleetSSL cPanel. While there are many users successfully combining the two, we cannot guarantee compatibility.

As of 2018-06-06, Engintron has an outstanding issue where Engintron does not properly regenerate the nginx configuration and reload the nginx webserver when an SSL certificate is updated within a cPanel virtualhost.

Our stance is that it is Engintron’s responsibility to properly handle the regeneration of the nginx virtual hosts. Other third party cPanel webserver replacements (such as Litespeed) do this properly. In our view, this is a major defect in Engintron. For now, you will need to use the community-provided workarounds to ensure that Engintron periodically regenerates its nginx virtualhosts.

You can find these workarounds and more information about the issue: and

Error: “Could not add TXT record” when trying to use DNS validation

Make sure that the Zone Editor (AAAA, CAA, SRV, TXT) feature is enabled WHM Feature Manager for each package that you want to be able to use DNS validation.

Error: “No response from subprocess” when trying to access the user interface

This may mean that your Apache webserver is not permitting its worker processes to allocate a sufficiently large amount of virtual memory.

The FleetSSL cPanel plugin is written in Go, which requires a certain amount of virtual memory to function properly.

Note: this is virtual memory only, not resident memory. The plugin has a low memory footprint in practice - the daemon runs under 20 megabytes usually. However, the virtual memory allocation required can somewhere between 600-1000MB.

This limit is set using the RLimitMEM directive in your Apache configurations. There are two places you can look for it:

  • In WHM → Apache Configuration → Memory Usage Restrictions.
  • Or, in WHM → Apache Configuration → Include Editor.

You may also check your Apache configuration this way:

grep -Ri RLimitMEM /etc/apache2/

What should I set my memory limit to?

We recommend not setting any virtual memory allocation limits at all. This is not an effective way to control memory usage of your tenants.

CloudLinux and other software packages provide ways to control resident (actual) memory usage, and we would suggest that any commercial hosting enterprise takes advantage of those.

Failing that, please try setting the limit to 1GB and seeing whether that eliminates the error.