Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
The DNS for your co.uk has both an IPv4 and IPv6 address. I see that HTTPS requests to co.uk use a cert with a different name hostyournet.uk. This one only has an IPv4 address.
Is that intended? Are you sure the IPv6 address is correct? Because Let's Encrypt favors IPv6 when defined in the DNS.
The error message from cPanel isn't the most helpful. It is a summary of what the Let's Encrypt server actually sends along with some info of its own. The key part though is that it says LE got an incorrect reply to the HTTP Challenge.
The other part of the error about the IP address comes from cPanel. For some reason its DNS query has a different IPv4 address than I see. So, that's either some regional difference or an issue with its resolver. In any case, that's not the first thing to sort out. But, since it does not show the IPv6 address it makes me think that is where the problem lies. That is, if your own system can't resolve IPv6 DNS perhaps inbound HTTP requests on IPv6 are a problem too.
HI Mike,
Yes due to the Cert expiring its auto resolving to the server hostname which is why its using a different cert (.uk)
The serer is setup for both IPv4 and IPv6. Its the same setup i'e used for a few years minus its on a newer OS (Alma 10) 4 month old.
Yes, sadly that all the error i see in the cPanels WHM error.I did remove the old expired .co.uk cert to try force it to create a new 1 which has failed.
I have a ticket out with the data center to check there DNS servers to see if thats where the issue lies but i dont get how.
The server does resolve IPv6 requests,
[root@cpanel-uk ~]# ping6 google.com
PING google.com (2a00:1450:4009:c17::71) 56 data bytes
64 bytes from sv-in-f113.1e100.net (2a00:1450:4009:c17::71): icmp_seq=1 ttl=115 time=2.18 ms
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 2.184/2.215/2.240/0.024 ms
[root@cpanel-uk ~]# ping6 letsencrypt.org
PING letsencrypt.org (2a05:d014:58f:6200::259) 56 data bytes
^C
--- letsencrypt.org ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12269ms
Ya im not sure whats going on but i wonder if LE using a incorrect IP to the server or something weird?
Yeah, cPanel has removed the error that would show the IP used. Is there a cPanel log that shows the original?
Note LE queries the authoritative DNS servers directly. This site (usually) shows the same IP addresses: https://unboundtest.com (it can differ when the DNS is mis-configured and for anycast and similar regional issues)
Your DNS config for the co.uk domain has some delegation and glue problems. And, you should fix those. See the Warnings here: hostyournet.co.uk | DNSViz
But, if the below are the correct IP then the DNS query is not the problem
hostyournet.co.uk. 0 IN A 78.129.248.2
hostyournet.co.uk. 0 IN AAAA 2001:1b40:5600:300::3
If the IP are valid the most likely next reason is something in Apache. Have there been any changes to that since you last got a good cert for this domain? Common issues are duplicated VirtualHosts or mis-matched DocumentRoot to what you configure for the cert request.
HI Mark,
Ip's are right for both its the only account on that server.
Other than system updates nothing and my other server that hosts my clients has no issues with LE.
Checking autossl folder the json file for the request there nothing new thats not in the file that cPanel shows the as the error.
As for the DNS errors i wonder if thats a knock on effect of whats going on, as the server hosts the DNS records for the .co.uk domain. the errors seem to be pointing from Enom's DNS servers.
The faulty delegation may explain why your cPanel saw a different IP than the authoritative DNS servers send out. But, the authoritative ones are what LE uses.
What do your Apache access logs say? You should be seeing inbound requests from LE and an HTTP reply of 200. You should see the http response of 200 since the error is saying LE's said "wrong" data and not "not found" which would be a 404 reply.
Hopefully the Apache access log identifies which VirtualHost it was handled by. If not, you may need to create unique access log file names to check that. Then make sure that VHost DocumentRoot is the webroot path used by cPanel's AutoSSL as the location to write the file. cPanel is not my specialty so not sure exactly where you set that.
I saw one of the domains in your prior cert was a wildcard name. That would have needed a DNS Challenge which uses a DNS TXT record for validation. But, the error in your post #1 is clearly for an HTTP Challenge.
Is this Apache just for a couple VHosts or is it a large install? If smaller I'd suggest showing the output of this.
sudo httpd -t -D DUMP_VHOSTS
Look for the same name showing multiple times for the same port (port 80). That would be bad
The other server has more domains on 1 ip and doesnt have an issues like this one which is why i think it LE doing something weird on this server/request.
Oh, I may have led you astray. I said the original error came partly from Let's Encrypt but I don't think that is correct. I think those are both from cPanel.
You can see the user-agent at the end of those log records. They are from Cpanel-HTTP Client. The Let's Encrypt user-agent is very different (and contains Let's Encrypt). Those 3 records have different challenge tokens so represent 3 different domain names.
We can also see your server's IP at the beginning which is usually where the source IP is. But, we saw in the error message that cPanel detected a different target IP. Perhaps the DNS problems are causing this problem after all. Refer to the Warnings at: hostyournet.co.uk | DNSViz
In any case, Let's Encrypt doesn't seem involved at all (yet). Some ACME Clients do a "pre-check" before requesting the cert. They do this to avoid burdening LE with useless requests. This is nice of them to do.
And, it is this pre-check that is failing. If you can disable that pre-check it might actually work. I say this because your authoritative DNS servers are sending the correct IP and those are what LE uses.
Hey Mark,
Thanks them acne are the same as the requested logs in that autossl run.
Which means the LE getting the request, downloading the ack file im assuming then checking but it that check thats failing.
Im talking with the DC now cause this is not making any sense at all.
No, we haven't seen any evidence that the Let's Encrypt ACME Server received any request.
The process starts with an ACME Client requesting a cert. In your case that is AutoSSL. If it actually made a request the LE ACME Server would send challenges to the domains requested. But, we don't see those requests in your Apache logs. The user-agent (and the source IPs) would indicate that.
Some ACME Clients do a pre-check of the challenge. A "test run" if you will. This is done before submitting the request to LE. It is this pre-check that AutoSSL is doing that is failing. We see Apache log records identifying it and your own server's source IP.
I'm managed to track this down.
It doesn't make sence, why trigger now, why on this current live server, why this didnt come to light on old server.
The IP is a single IP that held on Enom nameservers apparently went live for 3 days in 2024 but then went dormant.
I've never used this IP before so that's why i never had a clue what it was.
Right now i have a ticket open with them to fix and explain what went wrong and hopefully will fixed this.
How how this record is active and not been overwritten by my server nameservers as ti should be.
I did a bit of reading on cpanel autossl and its using your HTTP-01 challenge. which uses http://<YOUR_DOMAIN>/.well-known/acme-challenge/<TOKEN> .
that's why it wasn't showing in the logs under ACME or LE ACME due to their weird implemention.
That is probably related to the delegation problems described by dnsviz
Yes, that is the normal syntax for an HTTP Challenge. I don't know why you wouldn't see the ones that actually come from the Let's Encrypt server. They are standard HTTP requests arriving to your Apache server.
In fact, for a successful HTTP challenge you will see 5 log records with the identical token for each domain name in the cert. There are 5 different LE validation centers around the world. The only difference in the Apache log records for those 5 is the origin (or source) IP.
We did see 3 different "test" challenges though from cPanel AutoSSL. AutoSSL calls them "preflight" checks. They don't give much detail in their docs but the log records you showed (and I highlighted) are part of this pre-check
Note:
When AutoSSL runs, the system performs a preflight check
It appears that you've tried to migrate your DNS setup from when it ran on name-services.com, this works for the most part except for the fact that you need to change your NS records.
hostyournet.co.uk. 86400 IN NS dns4.name-services.com.
hostyournet.co.uk. 86400 IN NS dns3.name-services.com.
hostyournet.co.uk. 86400 IN NS dns1.name-services.com.
hostyournet.co.uk. 86400 IN NS dns2.name-services.com.
This will cause resolvers including unbound (the DNS resolver used by Let's Encrypt) to switch over to dns*.name-services.com for resolving your domain and these name servers advertise 15.197.172.60 as your IP address.
Thanks both, Its been setup like this for years but only now has broke, I had no other issues or warnings till now. Hopefully i can get this fixed soon.
Thanks everyone for your help in this.
It was an issue with Enom in the end sending out 2 master DNS records 1 using theirs and 1 using my name servers.
I had to revert to theres with basic dns records and after 30 min revert back to my name servers.