Skip to main content

Alterante DNS validation path for Let's Encrypt

Network Operations

We have used Sectigo for internal web hosting for our customers for some time, which has been quite convenient as our third-party mail provider uses Let's Encrypt to provide for mail delivery and webmail coverage with a simple CNAME to their central certbot host.

Problem is that Sectigo is out, and the standard TXT based verification seems to just crash out on an attempted renewal:
 3:14:47 PM WARN Died at /usr/local/cpanel/Cpanel/DnsUtils/Batch.pm line 243. ...propagated at /usr/local/cpanel/Cpanel/SSL/Auto/Run/HandleVhost.pm line 258. ...caught at /usr/local/cpanel/Cpanel/SSL/Auto/Run/User.pm line 314.

about 150 of our hosted customers use this external mail provider for their custom domains.

Any ideas for workarounds for this? We are somewhat comfortable using the api to make DNS changes.

Comments

5 comments

Date Votes
  • cPRex Jurassic Moderator

    Hey there!  That error snippet isn't telling me much - can you get me more details on the full error you're experiencing?

    0
  • Network Operations
    • Edited

    I can post the full log for the session renewal attempt if that helps, but as far as I can tell that's the only thing that goes wrong during autossl. I'm guessing that it is related to the existing CNAME at _acme-challenge.example.com preventing the installation of the more conventional TXT record that is typically used for verification.

    Sanitized log:

    3:14:44 PM AutoSSL’s configured provider is “Let’s Encrypt™”.
    Analyzing “example-user”’s domains …
    3:14:44 PM Analyzing “example.com” (website) …
    3:14:44 PM ERROR TLS Status: Defective
    ERROR Certificate expiry: 4/14/24, 12:00 AM UTC (2.93 days ago)
    ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL’s verification (0:10:CERT_HAS_EXPIRED).
    3:14:44 PM Attempting to ensure the existence of necessary CAA records …
    3:14:45 PM No CAA records were created.
    3:14:45 PM Verifying 9 domains’ management status …
    Verifying “Let’s Encrypt™”’s authorization on 9 domains via DNS CAA records …
    3:14:45 PM “webdisk.example.com” is managed.
    “cpanel.example.com” is managed.
    “mail.example.com” is managed.
    “www.example.com” is managed.
    “example.com” is managed.
    “webmail.example.com” is managed.
    “cpcontacts.example.com” is managed.
    “cpcalendars.example.com” is managed.
    “*.example.com” is managed.
    All of this user’s 9 domains are managed.
    CA authorized: “example.com”
    CA authorized: “*.example.com”
    CA authorized: “www.example.com”
    CA authorized: “mail.example.com”
    CA authorized: “cpanel.example.com”
    CA authorized: “webdisk.example.com”
    CA authorized: “webmail.example.com”
    CA authorized: “cpcontacts.example.com”
    CA authorized: “cpcalendars.example.com”
    “Let’s Encrypt™” is authorized to issue certificates for 9 of this user’s 9 domains.
    3:14:45 PM Performing HTTP DCV (Domain Control Validation) on 8 domains …
    3:14:45 PM Local HTTP DCV OK: example.com
    Local HTTP DCV OK: www.example.com
    Local HTTP DCV OK: mail.example.com
    Local HTTP DCV OK: cpanel.example.com
    Local HTTP DCV OK: webdisk.example.com
    Local HTTP DCV OK: webmail.example.com
    Local HTTP DCV OK: cpcontacts.example.com
    Local HTTP DCV OK: cpcalendars.example.com
    3:14:45 PM Verifying local authority for 1 domain …
    3:14:45 PM Local authority confirmed: “*.example.com”
    3:14:45 PM Enqueueing 1 domain (1 zone) for local DNS DCV …
    3:14:45 PM Publishing DNS changes for local DNS DCV (1 zone) …
    3:14:46 PM Querying DNS to confirm DCV changes …
    Processing “example-user”’s local DCV results …
    3:14:46 PM Local DNS DCV OK: *.example.com (via example.com)
    Analyzing “example.com”’s DCV results …
    3:14:46 PM Trying 1 wildcard domain (*.example.com) to maximize coverage …
    SUCCESS Let’s Encrypt DCV for “example.com” is valid until 4/18/24, 7:38 AM UTC.
    SUCCESS “Let’s Encrypt™” DCV OK: example.com
    3:14:47 PM WARN Died at /usr/local/cpanel/Cpanel/DnsUtils/Batch.pm line 243. ...propagated at /usr/local/cpanel/Cpanel/SSL/Auto/Run/HandleVhost.pm line 258. ...caught at /usr/local/cpanel/Cpanel/SSL/Auto/Run/User.pm line 314.
    3:14:47 PM The system has completed “example-user”’s AutoSSL check.

    Thank you,
    Riley

    0
  • cPRex Jurassic Moderator

    Well that's interesting - the script itself just seems to fail.  Is there anything interesting in the cPanel log at /usr/local/cpanel/logs/error_log when this happens?

    0
  • Network Operations

    I did not see anything of note in the error_log you specified with regard around the time that the AutoSSL process ran, the silent failing seems a little wild to me.

    After some interrogation of our mail provider, we don't need those _acme-challenge records anymore due to how our mail domains are configured. I did a test delete of the acme-challenge CNAME record in one of the domains that has been having the issue (though unaffected due to the nature of the site) and AutoSSL was able to provision a new certificate under Lets Encrypt without issue.

    The other option we were going to explore was building up some sort of Rube-Goldberg contraption that would swap out the records whenever the website's autossl needed renewing, and reinstalling the original CNAME as soon as that was completed.

    0
  • cPRex Jurassic Moderator

    You're always welcome to submit a ticket so we can take a look directly!

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post