AutoSSL Error DCV with Remote Mail Exchanger

[thowden]

Hi All

I have had this annoying me for a while now, but this afternoon it all got too much.

This is trying to renew AutoSSL - edited to protect the innocent::

4:10:19 PM 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.
Analyzing “testing”’s domains …
4:10:19 PM Analyzing “testing.com.au” (website) …
4:10:19 PM ERROR TLS Status: Defective
ERROR Certificate expiry: 1/2/22, 12:00 AM UTC (15.22 days ago)
ERROR Defect: OPENSSL_VERIFY: The certificate chain failed OpenSSL’s verification (0:10:CERT_HAS_EXPIRED).
4:10:19 PM Attempting to ensure the existence of necessary CAA records …
4:10:19 PM No CAA records were created.
4:10:19 PM Verifying 3 domains’ management status …
Verifying “cPanel (powered by Sectigo)”’s authorization on 3 domains via DNS CAA records …
4:10:20 PM “www.testing.com.au” is managed.
“mail.testing.com.au” is managed.
“testing.com.au” is managed.
All of this user’s 3 domains are managed.
CA authorized: “testing.com.au”
CA authorized: “www.testing.com.au”
CA authorized: “mail.testing.com.au”
“cPanel (powered by Sectigo)” is authorized to issue certificates for 3 of this user’s 3 domains.
4:10:20 PM Performing HTTP DCV (Domain Control Validation) on 3 domains …
4:10:20 PM Local HTTP DCV OK: testing.com.au
Local HTTP DCV OK: www.testing.com.au
WARN Local HTTP DCV error (mail.testing.com.au): The content “” of the DCV (Domain Control Validation) file, as accessed at “http://mail.testing.com.au/.well-known/pki-validation/long-string.txt”, did not match the expected value. The domain “mail.testing.com.au” resolved to an IP address “Remote IP” that does not exist on this server.
4:10:20 PM Verifying local authority for 1 domain …
4:10:20 PM Local authority confirmed: “mail.testing.com.au”
4:10:20 PM Enqueueing 1 domain (1 zone) for local DNS DCV …
4:10:20 PM Publishing DNS changes for local DNS DCV (1 zone) …
4:10:23 PM Querying DNS to confirm DCV changes …
4:10:24 PM Processing “testing”’s local DCV results …
4:10:24 PM Local DNS DCV OK: mail.testing.com.au (via testing.com.au)
Analyzing “testing.com.au”’s DCV results …
4:10:24 PM AutoSSL will request a new certificate.
4:10:24 PM The system will attempt to renew the SSL certificate for (testing.com.au: testing.com.au www.testing.com.au mail.testing.com.au).

My issue is with:
"“mail.testing.com.au” is managed."
AND
"WARN Local HTTP DCV error (mail.testing.com.au): The content “” of the DCV (Domain Control Validation) file, as accessed at //mail.testing.com.au/.well-known/pki-validation/long-string.txt, did not match the expected value. The domain “mail.testing.com.au” resolved to an IP address “Remote IP Address” that does not exist on this server."

And I have read https://forums.cpanel.net/resources/autossl-troubleshooting-steps.431/ which helps if there is an Error, but this is not an Error, it is Intentional.

The Domain is configured with a Remote Mail Exchanger. Why is the AutoSSL trying to check a domain that it acknowledges does not resolve to this server ?

Surely it should look at that and say 'Not here, leave it out'. We cannot (should not?) install //mail.testing.com.au/.well-known/pki-validation/long-string.txt this file on remote servers.

It just seems really odd that we are wasting resources generating calls and errors to something that will not work.

Thoughts please.

 

[thowden]

Hi All

Just an additional issue I noted, if a subdomain is removed from the DNS, the AutoSSL still trys to test for it:

www.subdomain.testing.com.au is generally not needed, so I remove those entries from the DNS, leaving subdomain.testing.com.au as the 'hostname'.

In a similar vein, why is AutoSSL insisting on testing non-existent subdomains, and giving an error. It should simply go 'Not here, ignore!, at least that is my understanding of how it should be.

 

[kodeslogic]

The domains which are not resolving to the server IP address exclude them for AutoSSL from the cPanel interface and it should be fine.

 

[thowden]

Hi

Thanks, but unless I am looking in the wrong place means I am disabling the whole domain and not just the specific hosts.

 

[cPanelAnthony]

Hello! You should be able to exclude specific subdomains from AutoSSL. Please see the following article.

 

[thowden]

Hi

Thanks. Yes that will work, but with lots of accounts and a significant number of these with 3rd party mail providers, Office365 etc, using the Cpanel interface per account is labour intensive.

Is there a command line option, a file I can edit, or a WHM bulk update option ?

Regardless, I still think the process is called AutoSSL and should automatically recognise that specific hostnames / subdomains either do not exist in the DNS or are directed somewhere else and should exclude those automatically. Manually setting selected / deselected domains / subdomains seems very not automated.

 

[cPanelAnthony]

I'm not aware of such a feature at this time. Would you be able to submit a feature request using the link in my signature?

 

[thowden]

HI All

Assuming the feature request is not moderated out of existence it should be at
---feature declined---

 

[thowden]

Hi All

And one more follow up. While I have yet to execute on this plan, the solution appears to be:

Install Lets Encrypt plugin
Swap from Sectigo which is file-based authentication and hence ALL hostnames/subdomains must be authenticated to create the certificate
Swap to LetsEncrypt which is using DNS-based authentication and issues a wildcard certificate to cover the domain, should be quicker and less pain.

More details in this thread https://forums.cpanel.net/threads/c...-certificate-when-some-hosts-fail-dcv.696801/ and in particular the comments dated from 3rd or 4th Feb 2022.

 

[cPRex]

I actually did decline that feature request as that isn't how the SSL system is designed to work, and changing it to work as outlined in your request would actually decrease the security of the system.

AutoSSL, no matter which provider you choose, looks through the domains that are configured on the machine and tries to verify them. The whole point of the verification is to prove the domain is hosted where the DNS records say they are - it's not AutoSSLs job to scan the DNS records and try and see what is live and what is not as that part is up to the server admin. AutoSSL ensures that all portions of the DNS lookup - from the root nameservers on down to the final DNS records - are configured properly.

 

[thowden]

Hi cPRex

Ok. I will need to ask for clarification as your statement confuses me.

AutoSSL, no matter which provider you choose, looks through the domains that are configured on the machine and tries to verify them. The whole point of the verification is to prove the domain is hosted where the DNS records say they are - it's not AutoSSLs job to scan the DNS records and try and see what is live and what is not as that part is up to the server admin. AutoSSL ensures that all portions of the DNS lookup - from the root nameservers on down to the final DNS records - are configured properly.

Can we clarify the term "domains". I will use the term Fully Qualified Domain Name (FQDN) which is what we are trying to get certificates issued for.

Further, I will assume that by AutoSSL you are referring to a script or set of scripts that Cpanel has written in order to interface with the Comodo/Sectigo or LetsEncrypt API's.

Breaking down your response:
1.

AutoSSL, no matter which provider you choose, looks through the domains that are configured on the machine and tries to verify them.

If AutoSSL is doing this "looking through" then what is it looking at ? The FQDN configuration is determined by the server manager, with both deletion and redirection of some DNS records. Yet AutoSSL is looking for those deleted records AND also checking records that are directed to remote hosts.
Where is AutoSSL getting its list of FQDN's?
Why are our servers wasting CPU cycles looking at domain records that do not exist?
Why are the FQDN's being sent to the Certificate Authority for testing?
- at which point we get an Error message that then requires the server admin to do more work to figure out why their explicit instructions are being ignored.

2.

The whole point of the verification is to prove the domain is hosted where the DNS records say they are

On this much we can agree. The verification by the CA is to prove ownership and the hosting location of each individual FQDN, "where the DNS records say they are". Which raises the question, if the DNS records say that a FQDN record does not exist, then where is that record being called from and why is it being tested?

3.

it's not AutoSSLs job to scan the DNS records and try and see what is live and what is not as that part is up to the server admin

This I cannot agree with for the reasons already stated, and it appears to contradict your own statement as per point 2 above. If AutoSSL has the role "to prove the domain is hosted where the DNS records say they are" then AutoSSL's role must include the job of scanning the DNS records for each FQDN as configured by the server admin.

4.

AutoSSL ensures that all portions of the DNS lookup - from the root nameservers on down to the final DNS records - are configured properly

If AutoSSL is, in fact, ensuring that all DNS lookups "down to the final DNS records" then it should be checking the 'live' DNS and not anything else. I think this hinges on the last word "properly" and that word is subjective. My view is that my DNS record configuration is "proper" for my localhost domains. However, Cpanels view is that I should have additional "FQDNs" that I have explicitly deleted, and should not host any FQDN record that points to an external service in order to be configured "properly".

An external perspective on this is from Comodo / Sectigo within their explanation of why they do not provide a wildcard certificate and will test every individual DNS record provided to them for a domain:

The CA Browser (CA/B) Forum, an affiliation of industry members that manages certificate rules and procedures, has determined that file-based validation, used too broadly, creates the risk that actors could obtain certificates for sub-domains they don’t legitimately control. Therefore, the CA/Browser Forum has passed a ballot disallowing file-based DCV for wildcard certificates and will require that each FQDN in a multidomain certificate be verified individually.

This means that the CA are testing ALL FQDN's as provided by AutoSSL from cPanel for a localhost domain. Surely it is the responsibility of AutoSSL to only provide to the CA the actual FQDN's that exist and NOT waste the CA processing by including FQDN's that do not exist, or FQDN's that point to remote locations that should not be a part of an SSL certificate for the localhost. The CA's bandwidth is already under load without adding extra pointless requests.

Essentially, AutoSSL is asking the CA to test for "certificates for sub-domains they don’t legitimately control" which is exactly what the industry is trying to avoid.

TL;DR
I think it is AutoSSL's job to check what is live and what is not.
I think the current CPanel process is not using the actual FQDN records and is creating more work and errors and wasting resources for server admins and CA's.
I think this is a significant bug in the AutoSSL process and not just something that needs a feature request.

 

[cPRex]

Thanks for that clarification. I think this will help us get somewhere. I'll just answer in order to make sure I don't miss anything.

1 - AutoSSL reads the domain data from what's in Apache. It doesn't know if the DNS exists or not when the check starts, as that is the point of the DCV verification on the system. If the domain has a vhost, or is otherwise configured to exist in Apache on the server (addon, park, alias, etc.) AutoSSL will check for it.

2 - I think this one is where the confusion is as it's not just "where the DNS records say they are" but also "where AutoSSL runs from." AutoSSL has two ways of performing the verification check - the DNS method, or DCV method. Either way would confirm that the server that AutoSSL is running on is the authority for the domain. Here is one example that happens a lot:

-AutoSSL runs on domain.com on server A
-there is sub.domain.com with DNS that points to server B
-AutoSSL will happily issue a certificate for domain.com, but since it doesn't run on the machine where sub.domain.com is hosted, it wouldn't be able to secure that, even though the DNS is configured properly. This will return an error stating the IP address of the domain points to a different server. This can also happen if records are removed from a DNS zone, but the domain still exists in Apache, as outlined here:

Potential reduced AutoSSL coverage notification

Symptoms You will receive a notification like the following. domain.tld: AutoSSL would normally renew this certificate now, but X of the website’s secured domains just failed DCV. To provide you wi...

support.cpanel.net

3 - I *think* my longer answer to number two covered this.

4 - I see where you're coming from, but that's just not the intent of the AutoSSL system. AutoSSL system tries to secure all the domains present on the machine, and if the DNS is broken or missing it lets the owner of the machine know it needs to be dealt with.

Let's look at it from the other perspective. What if I have the domains created normally on the machine but there is a typo in the DNS zone? The DNS zone would be "live" but that may or may not match up with anything on the Apache side of things.

 

[thowden]

Hi

Apologies for the lengthy delay in a reply (I got distracted with family matters). I think this is (was) an important topic and I wanted to follow up.

For anyone who is interested, on my servers I have removed the Comodo errors by simply swapping to use Lets Encrypt as the SSL provider.

@cPRex : Thanks for the extended reply. I still think the configuration and testing process is flawed, but given that my servers are ok and there is apparently minimal interest from anyone else, I will let it go.