This tutorial is for WHM system administrators and designed to address some common issues with AutoSSL's domain validation process.
It was first published by the cPanel team and adapted here as a training guide for our team.
Run AutoSSL Manually
While this will often happen automatically on systems with AutoSSL enabled, visually check to confirm that AutoSSL is enabled on the host machine by going to WHM >>> SSL/TLS>>Manage AutoSSL → Providers.
From there, try to run AutoSSL for the domain and check the log.
An AutoSSL check can also be initialized on the command line with the following:
/usr/local/cpanel/bin/autossl_check ( --user= | --all | --help )
You can also use the WHMAPI1 SSL functions found at WHM API 1 Sections - SSL to make a number of modifications to the AutoSSL configuration.
Check AutoSSL Log
Now that the AutoSSL initialization has occurred, the system will have an up to date log with the error.
You can use the logs UI at WHM >>> SSL/TLS >>> Manage AutoSSL >>> Logs to determine which domains were checked/which passed/etc.
Determine which error you're receiving and check the common causes also listed if a domain is failing validation.
This will be listed in the log error output.
It is important to note that some of the errors formatting may change with each cPanel version.
“example.com” does not resolve to any IPv4 addresses on the internet."
This is probably the most common DNS issues due to authoritative nameservers misconfiguration.
You can troubleshoot this using the dig command with the +trace option information on dig can be found by typing man dig.
You can also use the dig(1): DNS lookup utility Linux man page at dig(1): DNS lookup utility - Linux man page
Online tools you can use will either be:
You should also check whether the domain has expired by either asking the customer to confirm or visiting https://lookup.icann.org/ or https://who.is/.
"The domain “example.com” failed domain control validation: The system failed to fetch the DCV (Domain Control Validation) file at “http://example.com/.well-known/pki-validation/hash.txt” because of an error: Due to an error, the system was unable to send a Hypertext Transfer Protocol (HTTP) request "GET" to "http://example.com/.well-known/pki-validation/hash.txt": Size of response body exceeds the maximum allowed of 16384"
This might be because of:
cPanel case EA-7330 where mod_evasive sometimes add the server's own IP to the blacklist causing issues with AutoSSL as one of the checks done internally originates from the domain's primary IP.
mod_evasive Apache module helps to protect servers against DoS, DDoS, and brute force attacks.
It also acts a detection tool, and can configure be to communicate with iptables, firewalls, and routers, among other things.
This module works well for single-server attacks, distributed attacks, and brute-force attacks.
If integrated with firewall or IP filters, it can withstand even large attacks.
What does the module do?
The mod_evasive Apache module creates an internal, dynamic hash table of IP addresses and URIs, and denies any single IP address that does the following:
- requests the same page more than a few times per second.
- makes more than 50 concurrent requests on the same child per second.
- makes any request while temporarily blacklisted.
The module creates an instance for each listener, ensuring a built-in cleanup mechanism and good scaling.
To avoid the named issue, always white-list, use the DOSWhiteList to set the IP address or range of IP addresses in the directive and ensure that the module does not block IP addresses you do not want blocked.
Your whitelist entry might resemble the following example:
DOSWhitelist 127.0.0.1 DOSWhitelist 127.0.0.*
The cPanel team is working to get this corrected and perhaps might have been by the time you are reading this.
nGINX caching: test if this is the case and switch back to Apache efore attempting provision the certificate again.
varnish caching: test if this is the case and switch back to Apache before attempting to provision the certificate again.
DNS Caching: If the domain has just been pointed to our DNS systems, do wait for its propagation before attempting to provision an AutoSSL certificate.
You might want to flush the DNS to hasten things up by visiting Flush Public DNS Cache | Google Developers
Forced redirection to https: check the .htaccess file and any installed CMS.
mod_cache: The mod_cache Apache module directs Apache to save local or proxied content for later use.
If needed, you may want to add an entry to mod-cache config via Service Configuration >>> Apache Configuration >>> Include Editor to ensure that the DCV bypass cache completely.
CacheDisable /.well-known CacheDisable /.cpaneldcv
"The domain “example.com” resolved to an IP address “1.2.3.4” that does not exist on this server."
This simply means that either the domain doesn't resolve to the host machine or that the domain has expired or awaiting validation from the registrar.
Again, the DNS troubleshooting guide to the rescue.
"The system queried for a temporary file at “http://example.com/.well-known/pki-validation/hash.txt”, but the web server responded with the following error: 403 (Forbidden). A DNS (Domain Name System) or web server misconfiguration may exist."
This isn probably caused by a .htaccess redirect which can be anywhere on the server but often in /home/$user/ or /home/$user/public_html.
You can test whether or not the .htaccess is at fault by renaming it temporarily and running the AutoSSL check once more.
Running a curl request (after renaming the .htaccess file) setting the user agent string to COMDO DCV will also be useful to determine what's going on when checking for the DCV file.
Something like this might help:
curl -k --user-agent "COMODO DCV" http://domain_name.$tld/.well-known/pki-validation/hash.txt
This issue can also be caused by a 'deny from' rule that was added manually to a .htaccess file or automatically by a CMS plugins.
Once the issue has been identified, just re-run the AutoSSL check to fix the issue.
To verify, visit WHM >>> SSL/TLS >>> Manage AutoSSL >>> Pending Queue.
The domain will now be removed from the pending queue if everything checks out.
Courtsey of cPanelLauren
