I don't want to post the good domain without permission, I've asked.
Happy to send it privately if that is possible.
It may be best the pause debugging for a while.
Eddiem.com is currently dead as I've changed the name-servers and it will take a while to propagate and fix any blunders.
The email address I use for this forum is dead too.
What I can say is the working domain uses cloudflare domain registration and cloudflare nameservers.
Most of mine use enomcentral for both but a few use the binarylane NS - ns1.binarylane.com.au etc. These also failed.
I not hopeful but need to see if changing NS does anything.
I think I moved away from ns1.binarylane.com.au years back because I had problems - to long back to remember.
I don't see how changing name servers would modify these symptoms.
The problem is that an HTTP request from an LE server is not reaching your server. There is no problem querying the DNS. Those errors have different messages.
If you click my "name" on this post you may be able to message me. But, know these are "direct messages" not "private".
That said, if the users of your domain are not having connectivity problems switching to a DNS Challenge may work around this problem. The LE authentication happens solely with the public DNS. I don't know how that is done with Webmin/VirtualMin or if it is even possible with that.
Sorry if that was covered earlier I have been away and did not review each prior post.
The working domain is sagittal.org
As I said - I'm not hopeful.
You don't see the error messages in Singapore?
I did check for geoblocks using proxies but there could be something wrong with the DNS propagation to some parts of the network.
I have one domain that passes the test and 9 that don't.
Its cloudflare domain and NS make it different. Have I missed something else?
Most of us here are unpaid volunteers. We don't have access to the internal servers of Let's Encrypt.
But, I don't see a good reason to focus on Singapore. You are only getting 3 of the expected 5 and if I remember right the pattern of LE Auth centers varied. Your most recent post of 3 was missing a Singapore and a US East Coast auth center. If either of those had worked your cert request would have succeeded.
Well, this is a very different config than your others. This is proxied at Cloudflare so your Origin Server is "behind" their CDN. You can have your DNS at Cloudflare without proxying but that is just "plain" DNS and considerably different than proxying and CDN.
I don't know how well you understand that proxy CDN but all HTTP(s) requests go to the Cloudflare CDN edge first and the edge makes a new connection to your Origin. This means that your Origin server only sees requests from a Cloudflare edge IP.
Both eddiem.com and eddiem.info are not proxied at Cloudflare and do not appear to have any CDN involved. This means that HTTP requests from anywhere (including an LE Auth Server) goes directly from the requester to your server.
This solves the mystery of why that works and your others don't (presumably none of them are proxied there either).
Definitely not a fair conclusion as I just explained.
All secondary LE Auth Centers are in AWS regions (today). One of the centers we often don't see in your logs when only 3 are shown is the AWS East Coast Region. As it happens I have a test server in an AWS East Coast region too.
And, I cannot connect right now to either eddiem .com or .info from my server. These two domains have different IP addresses right now.
A traceroute from my AWS East Coast server to either of those domains gets as far as Australia but never reaches your server. Does "Superloop" mean anything to you? That might be associated with the last good "hop" in a traceroute.
Thanx for putting in the time.
I did say that we should wait because eddiem.com was down as the nameserver info propagates.
It has been offline all day but is working again from here.
No, I don't use cloudflare and I don't know how it works.
I have other unrelated server problems to fix now.
That sagittal domain definitely is proxied at Cloudflare and using their CDN. These are the public DNS A / AAAA entries for it and these are all CF edge IP addresses
sagittal.org. 300 IN A 172.67.200.243
sagittal.org. 300 IN A 104.21.21.231
sagittal.org. 300 IN AAAA 2606:4700:3032::6815:15e7
sagittal.org. 300 IN AAAA 2606:4700:3034::ac43:c8f3
Yeah, which was why I also tried eddiem .info since it had a different IP in its A record. And, it was puzzling why a DNS propagation should affect the A record unless you also changed the IP for your server so thought I'd try anyway.
Right now I can reach both eddiem .com and .info and they return the same "home" page
Okay. If you want further help trying to debug that problem let us know when you are ready