AutoSSL not attempting to auto renew

jnyr5478

October 08, 2019 11:01

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

Comments

10 comments

cPanelLauren

October 08, 2019 20:06
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
0
jnyr5478

October 09, 2019 17:52
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?
0
cPanelLauren

October 09, 2019 18:37
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?
0
jnyr5478

October 09, 2019 21:22
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?
0
cPanelLauren

October 09, 2019 21:34
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.
0
jnyr5478

October 10, 2019 18:26
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:
- Is this likely the cause of failing auto-renewals?
- 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")?
- Is it possible to tell AutoSSL where to look? I can add conditions to our rewrite rules if not.
- The /.well-known/pki-validation directory is currently empty. When are txt files created and deleted?
0
jnyr5478

October 10, 2019 18:55
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
0
cPanelLauren

October 10, 2019 21:18
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.
0
jnyr5478

October 11, 2019 12:45
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!
0
jnyr5478

March 04, 2020 15:51
@cPanelLauren sorry for the very late reply. Enabling Global DCV Passthrough did resolve this problem.
0

Please sign in to leave a comment.

Comments

Didn't find what you were looking for?