In Progress [CPANEL-26814] AutoSSL last ran on December 31, 1969

jndawson

Well-Known Member
Aug 27, 2014
231
23
18
Western US
cPanel Access Level
DataCenter Provider
We had a customer complain that his SSL cert had expired on the 9th (today's the 11th). All accounts are on autoSSL, so that was puzzling.

We checked and the certs had expired, but not renewed.

We ran whm > ssl/tls > manage autossl and the certs are still pending after 45 minutes - usually takes about 15 minutes at the most.

Went into account's cPanel portal and checked cpanel > security > ssl/tls status and this is what's posted under each domain & subdomain:

Code:
AutoSSL last ran on December 31, 1969.
Expired on June 8, 2019. The certificate will renew via AutoSSL.
Clearly something is screwy; the certs expired on the 9th, not the 8th, and clearly 12/31/69 is not the last time we ran autossl. Spot checking other accounts indicate this is a one-off issue.

Any ideas why it might be screwed up and why the date is the day before epoch?
 

jndawson

Well-Known Member
Aug 27, 2014
231
23
18
Western US
cPanel Access Level
DataCenter Provider
More info. Here's the log from last night for the affected account:

Code:
Checking websites for “user” …
1:29:16 AM Analyzing “customer.tld” …
1:29:16 AM ERROR TLS Status: Defective
ERROR Certificate expiry: 6/9/19, 12:00 AM UTC (3.35 days ago)
ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL’s verification (0:10:CERT_HAS_EXPIRED).
1:29:16 AM Performing DCV (Domain Control Validation) …
1:29:16 AM Local HTTP DCV OK: customer.tld
Local HTTP DCV OK: www.customer.tld (via customer.tld)
Local HTTP DCV OK: mail.customer.tld (via customer.tld)
Local HTTP DCV OK: cpanel.customer.tld (via customer.tld)
Local HTTP DCV OK: joomla2.customer.tld (via customer.tld)
Local HTTP DCV OK: webdisk.customer.tld (via customer.tld)
Local HTTP DCV OK: webmail.customer.tld (via customer.tld)
Local HTTP DCV OK: www.joomla2.customer.tld (via customer.tld)
Local HTTP DCV OK: autodiscover.customer.tld (via customer.tld)
Local HTTP DCV OK: mail.joomla2.customer.tld (via customer.tld)
1:29:16 AM Analyzing “customer.tld”’s DCV results …
1:29:16 AM AutoSSL will request a new certificate.
1:29:16 AM The system will attempt to renew the SSL certificate for the website (customer.tld:customer.tld www.customer.tld mail.customer.tld webmail.customer.tld cpanel.customer.tld autodiscover.customer.tld webdisk.customer.tld joomla2.customer.tld www.joomla2.customer.tld mail.joomla2.customer.tld).
1:29:17 AM No CAA record added because there is no CAA record from another provider in the DNS for customer.tld.
The provider “cPanel (powered by Sectigo)”’s AutoSSL queue already contains a certificate request for “user”’s website “customer.tld”. The request’s start time is Jun 11, 2019, 10:40:32 PM UTC.
1:29:17 AM The system has completed the AutoSSL check for “user”.
Note the errors setting up a renewal:
Code:
1:29:16 AM ERROR TLS Status: Defective
ERROR Certificate expiry: 6/9/19, 12:00 AM UTC (3.35 days ago)
ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL’s verification (0:10:CERT_HAS_EXPIRED).
And the result:
Code:
1:29:17 AM No CAA record added because there is no CAA record from another provider in the DNS for customer.tld.
The provider “cPanel (powered by Sectigo)”’s AutoSSL queue already contains a certificate request for “user”’s website “customer.tld”. The request’s start time is Jun 11, 2019, 10:40:32 PM UTC.
Apparently, the now-expired cert was issued prior to using DCV records. We removed the certs, removed the autoSSL setting, then reset autossl, then re-ordered the certs.
Here are the relevant log entries:
Code:
[snip]
9:56:25 AM Analyzing “customer.tld” …
9:56:25 AM ERROR TLS Status: Defective
ERROR Defect: NO_SSL: No SSL certificate is installed.
[snip]
9:56:26 AM No CAA record added because there is no CAA record from another provider in the DNS for customer.tld. The provider “cPanel (powered by Sectigo)”’s AutoSSL queue already contains a certificate request for “users”’s website “customer.tld”.
So we can't add new certs via AutoSSL because there is not an existing CAA record, which makes no sense, so there is an issue with the way AutoSSL/cPanel/Sectigo is now issuing certs.

We renamed /var/cpanel/autossl_queue_cpanel.sqlite to /var/cpanel/autossl_queue_cpanel.sqlite.old and ran autoSSL:

Code:
10:15:40 AM No CAA record added because there is no CAA record from another provider in the DNS for customer.tld.
10:15:41 AM The cPanel Store received “customer.tld”’s certificate order. (Order Item ID: 649476823) The system will periodically poll the cPanel Store for the issued certificate and then install it after a successful retrieval.
We ran
Code:
/usr/local/cpanel/bin/autossl_check_cpstore_queue --force
Polling for user customer.tld 649476823
                                          The certificate is not available. (processing)
Setting up for Sectigoâs DCV (Domain Control Validation) for this certificate request
The new cert request is now displaying. We may have fixed it; I'll report back the results.
 
Last edited:

cPanelLauren

Forums Analyst II
Staff member
Nov 14, 2017
8,126
667
263
Houston
cPanel Access Level
DataCenter Provider
Ok, I just wanted to make sure that the date was set on the machine correctly since the only time I've ever seen the error you're referencing was when it was incorrect.

The new cert request is now displaying. We may have fixed it; I'll report back the results.
Please do let us know the results!
 

jndawson

Well-Known Member
Aug 27, 2014
231
23
18
Western US
cPanel Access Level
DataCenter Provider
Still an issue. Last night's autossl run resulted in:
Code:
No CAA record added because there is no CAA record from another provider in the DNS for customer.tld. The provider “cPanel (powered by Sectigo)”’s AutoSSL queue already contains a certificate request for “user”’s website “customer.tld”.
We're opening a ticket.
 

jndawson

Well-Known Member
Aug 27, 2014
231
23
18
Western US
cPanel Access Level
DataCenter Provider
Prior to opening a ticket, we added a CAA record to the zone and re-ran AutoSSL:
Code:
A CAA record for this provider is already in the DNS for customer.tld. The provider “cPanel (powered by Sectigo)”’s AutoSSL queue already contains a certificate request for “user”’s website “customer.tld”.
Then checked:
Code:
[ [email protected] ~># /usr/local/cpanel/bin/autossl_check_cpstore_queue --force
Polling for âcustomer.tldâ649476823â
                                          The certificate is not available. (processing)
Setting up for Sectigoâs DCV (Domain Control Validation) for this certificate request â¦
So, that changed; we'll wait awhile to see if the cert is issued.
 

cPanelLauren

Forums Analyst II
Staff member
Nov 14, 2017
8,126
667
263
Houston
cPanel Access Level
DataCenter Provider
I believe the CAA record should now reference sectigo.com not comodoca

Code:
Standard BIND Zone File
youdomain.tld.    IN    CAA    0 issue "sectigo.com"
Though they do indicate that they recognize the following:
https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000zFMO
We recognize the following domain names in "issue" and "issuewild" property tags as permitting us to issue:
comodoca.com usertrust.com trust-provider.com sectigo.com

I did check that ticket and it looks like the PreSign for the certificate failed so it passed the DCV but they weren't able to get signing criteria for the certificate (which may be the CAA record)
 
Last edited:

jndawson

Well-Known Member
Aug 27, 2014
231
23
18
Western US
cPanel Access Level
DataCenter Provider
Follow up.

Apparently, the way AutoSSL certs are issued has changed. For the time being, any hostnames/subdomains hosted elsewhere will prevent the issuance/renewal of a cert using AutoSSL. In this case, customer uses Google for email, so mail.customer.tld and webmail.customer.tld are CNAMEd to the related google hostnames. We removed those from AutoSSL using the customer's cpanel account (can't seem to do it from WHM).

Internal case number is CPANEL-26814. The work-around suggestions included are:

1.) Don't use a CNAME to a domain that has a CAA record which would conflict with Comodo. Try pointing it to the IP address directly via A record instead.
2.) Switch AutoSSL to Lets Encrypt for this specific instance.
3.) Manually exclude the domain from AutoSSL.

We chose option 3, which is the easiest.