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

jndawson

• June 11, 2019 18:36

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: 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

  • June 12, 2019 17:20

  More info. Here's the log from last night for the affected account: 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: 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: 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: [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: 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 /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.

  0
• 

  cPanelLauren

  • June 12, 2019 17:55

  Hi @jndawson Also what's the date on that machine when you run the following: date
  

  0
• 

  jndawson

  • June 12, 2019 17:58

  Hi @jndawson Also what's the date on that machine when you run the following: date
  

  
  [ root@cp1 cpanel># date Wed Jun 12 10:58:01 PDT 2019
  

  0
• 

  cPanelLauren

  • June 12, 2019 18:31

  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!

  0
• 

  jndawson

  • June 12, 2019 20:27

  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.

  
  That's what is so weird about this - that is the only account displaying that date.

  0
• 

  jndawson

  • June 13, 2019 16:40

  Still an issue. Last night's autossl run resulted in: 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.

  0
• 

  cPanelLauren

  • June 13, 2019 16:54

  Hi @jndawson Let me know the ticket ID as soon as you have one, I can check a couple of items as well and follow up here.

  0
• 

  jndawson

  • June 13, 2019 18:01

  Prior to opening a ticket, we added a CAA record to the zone and re-ran AutoSSL: 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: [ root@cp1 ~># /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.

  0
• 

  jndawson

  • June 13, 2019 19:44

  Cert still hasn't issued. Ticket# 12582373

  0
• 

  cPanelLauren

  • June 13, 2019 20:43

  I believe the CAA record should now reference sectigo.com not comodoca Standard BIND Zone File youdomain.tld. IN CAA 0 issue "sectigo.com"
  Though they do indicate that they recognize the following:
  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)

  0
• 

  jndawson

  • June 14, 2019 18:40

  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.

  0
• 

  cPanelLauren

  • November 25, 2019 18:56

  Hello, This issue has been resolved as of v84 of cPanel/WHM - if you're continuing to experience issues with this please let us know! Thanks!

  0

Please sign in to leave a comment.