AutoSSL not attempting to auto renew

[jnyr5478]

Each of our clients has a separate server with WHM, each of which uses AutoSSL by cPanel (Sectigo). On one of those servers, it appears that AutoSSL has not been attempting to auto renew installed certificates. On two recent occasions, we've needed to run Check User in order to get the certificate renewed. Here's the log from one of those manual instances:

Log for the AutoSSL run for “{{user account}}”: Thursday, September 26, 2019 8:58:23 AM GMT-0400 (cPanel (powered by Sectigo))
8:58:23 AM AutoSSL’s configured provider is “cPanel (powered by Sectigo)”.
This AutoSSL provider does not poll for certificate availability immediately after a certificate request submission. Instead, it submits certificate requests then periodically polls the cPanel Store for each requested certificate and installs it after a successful retrieval. The system will record all requests, retrievals, and installations for the current AutoSSL run in this log.
Checking websites for “{{user account}}” …
  8:58:23 AM Analyzing “domain.tld” …
    8:58:23 AM ERROR TLS Status: Defective
    ERROR Certificate expiry: 9/26/19, 12:00 AM UTC (0.54 days ago)
    ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL’s verification (0:10:CERT_HAS_EXPIRED).
  8:58:23 AM Performing DCV (Domain Control Validation) …
    8:58:23 AM Local HTTP DCV OK: domain.tld
    Local HTTP DCV OK: parked-domain.tld
    Local HTTP DCV OK: www.domain.tld (via domain.tld)
    Local HTTP DCV OK: mail.domain.tld (via domain.tld)
    Local HTTP DCV OK: www.parked-domain.tld (via parked-domain.tld)
    Local HTTP DCV OK: mail.parked-domain.tld (via parked-domain.tld)
    Local HTTP DCV OK: parked-subdomain.domain.tld (via domain.tld)
    Local HTTP DCV OK: www.parked-subdomain.domain.tld (via domain.tld)
    Local HTTP DCV OK: mail.parked-subdomain.domain.tld (via domain.tld)
  8:58:23 AM Analyzing “domain.tld”’s DCV results …
    8:58:23 AM AutoSSL will request a new certificate.
  8:58:23 AM The system will attempt to renew the SSL certificate for the website (domain.tld: domain.tld www.domain.tld mail.domain.tld parked-domain.tld www.parked-domain.tld mail.parked-domain.tld parked-subdomain.domain.tld www.parked-subdomain.domain.tld mail.parked-subdomain.domain.tld).
  No CAA record added because there is no CAA record from another provider in the DNS for parked-domain.tld.
  No CAA record added because there is no CAA record from another provider in the DNS for domain.tld.
  8:58:24 AM The cPanel Store received “domain.tld”’s certificate order. (Order Item ID: 727724213) The system will periodically poll the cPanel Store for the issued certificate and then install it after a successful retrieval.
8:58:25 AM The system has completed the AutoSSL check for “{{user account}}”.
8:59:01 AM Polling for “{{user account}}”’s new certificate for “domain.tld” (order item ID “727724213”) …
8:59:02 AM The certificate is available. The system will now attempt to install it.
SUCCESS The certificate is now installed!

So the certificate was renewed manually, but I'm wondering why this needed to happen in the first place. You can see that the certificate expired 0.54 days ago.

While working with the hosting provider, additional Check User requests were made. Unfortunately, this may have deleted past logs related to this this account that may have shown renewal failures. The hosting provider's solution was to manually create a cron job that would make AutoSSL check for upcoming expirations every 12 hours. That's fine, but I was under the impression that AutoSSL already begins this check 15 days in advance:

"Certificate renewal attempts for cPanel-signed certificates begin within 15 days of expiry." (via this post).

I have since enabled the "Notify the user for AutoSSL certificate request failures, warnings, and deferrals" option to bring more visibility.

 

[cPanelLauren]

That's fine, but I was under the impression that AutoSSL already begins this check 15 days in advance:

"Certificate renewal attempts for cPanel-signed certificates begin within 15 days of expiry." (via this post).

The AutoSSL service does indeed begin checking the domains 15 days in advance in an attempt to rule out any issues prior to renewal. What would be most helpful in this instance would be log files related to the automated checks that should have happened.

While working with the hosting provider, additional Check User requests were made. Unfortunately, this may have deleted past logs related to this this account that may have shown renewal failures.

AutoSSL logs in WHM>>SSL/TLS>>Manage AutoSSL -> Logs should go back pretty far, do you see anything present prior to when you ran the manual checks?

 

[jnyr5478]

Hi Lauren. There are now many more logs available than there were yesterday, mainly because the cron that the hosting provider created is running every 1 minute instead of every 12 hours as intended . Supposedly it's just been fixed.

Unfortunately, there are no older logs for the account in question. I'm guessing that log retention is based on the age of the log file and not the number of files?

 

[cPanelLauren]

I'm curious about something. If you run the following API Function for one of the users who was previously experiencing an issue (i.e., didn't get their cert auto-renewed) does anything come back?

WHM API 1 Functions - get_autossl_problems_for_user - Developer Documentation - cPanel Documentation

documentation.cpanel.net

I find it easiest in instances like this to just use the CLI version so you'd run this:

whmapi1 get_autossl_problems_for_user username=$user

AutoSSL should run daily, if you comment out or remove that cron your provider added, do you see a log file generated for the AutoSSL run? You'd have to wait until cPanel's daily maintenance was run which is usually in the middle of the night.

 

[jnyr5478]

I'm curious about something. If you run the following API Function for one of the users who was previously experiencing an issue (i.e., didn't get their cert auto-renewed) does anything come back?

WHM API 1 Functions - get_autossl_problems_for_user - Developer Documentation - cPanel Documentation

documentation.cpanel.net

I find it easiest in instances like this to just use the CLI version so you'd run this:

whmapi1 get_autossl_problems_for_user username=$user

Here's the response:

data:
  problems_by_domain: []

metadata:
  command: get_autossl_problems_for_user
  reason: OK
  result: 1
  version: 1

Guessing this means no problems.

AutoSSL should run daily, if you comment out or remove that cron your provider added, do you see a log file generated for the AutoSSL run? You'd have to wait until cPanel's daily maintenance was run which is usually in the middle of the night.

When the cron was running every minute, it was generating a log file for each run. Each of those logs checks each account and reports "SUCCESS TLS Status: OK" and then lists the certificate expiry date, all of which are in the 40-80 day range.

 

[cPanelLauren]

Guessing this means no problems.

Yea there aren't any current issues logged

When the cron was running every minute, it was generating a log file for each run. Each of those logs checks each account and reports "SUCCESS TLS Status: OK" and then lists the certificate expiry date, all of which are in the 40-80 day range.

Right, so that would mean when the cron is present the check is being completed. Because this check should be completed nightly what I wanted to gather was information on what is happening when the custom cron to check for this isn't present. Is there logs present indicating that it did run or any data in the cPanel error log potentially indicating why the check didn't run, etc.

 

[jnyr5478]

Is there logs present indicating that it did run or any data in the cPanel error log potentially indicating why the check didn't run, etc.

^^ Eureka (I think)!

In /usr/local/cpanel/logs/error_log, I found a warning line from 9/26 saying that autossl_check expected to find the pki-validation file at

https://domain.tld/.well-known/pki-validation/{long string}.txt​

but that the server response is a 301 saying that the file has moved to:

https://www.domain.tld/.well-known/pki-validation/{long string}.txt​

​

So I have four questions:

1. Is this likely the cause of failing auto-renewals?
2. Is AutoSSL looking for a non-www URL because the cPanel user doesn't include www (the cPanel user is "domain.tld", not "www.domain.tld")?
3. Is it possible to tell AutoSSL where to look? I can add conditions to our rewrite rules if not.
4. The /.well-known/pki-validation directory is currently empty. When are txt files created and deleted?

 

[jnyr5478]

Ah, I think I understand now. We've seen the following lines injected into .htaccess on other servers:

RewriteCond %{REQUEST_URI} !^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/(?:\ Ballot169)?
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Sectigo\ DCV)?$

These lines are missing from the .htaccess file for this site. Maybe they were inadvertently removed when someone pushed a change to that file.

I've also just read about the Global DCV Passthrough option in Server Configuration > Tweak Settings. For some reason, that setting is Off for this server. Guess I'll turn that on.

 

[cPanelLauren]

Hi @John Manning


That should be automatically entered into the .htaccess when there's a redirect present on the domain that prevents the DCV check from being completed. Try the Global DCV Passthrough and let me know if you continue to see the same behavior.

 

[jnyr5478]

Hi @John Manning
That should be automatically entered into the .htaccess when there's a redirect present on the domain that prevents the DCV check from being completed. Try the Global DCV Passthrough and let me know if you continue to see the same behavior.

The next upcoming renewal should happen on or before 11/26/19. I'll update this thread with results. Thanks for your help!

 

[jnyr5478]

@cPanelLauren sorry for the very late reply. Enabling Global DCV Passthrough did resolve this problem.