Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for itcusys.online
dns-01 challenge for itcusys.online
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. itcusys.online (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.itcusys.online - check that a DNS record exists for this domain, itcusys.online (dns-01): urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.itcusys.online - check that a DNS record exists for this domain
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: itcusys.online
Type: None
Detail: DNS problem: NXDOMAIN looking up TXT for
_acme-challenge.itcusys.online - check that a DNS record exists for
this domain
Domain: itcusys.online
Type: None
Detail: DNS problem: NXDOMAIN looking up TXT for
_acme-challenge.itcusys.online - check that a DNS record exists for
this domain
It’s not talking about an A record. It is talking about a TXT record that is generated in real time at the time of request. If Virtualmin is not managing your DNS, and if you haven’t properly delegated authority for DNS to the Virtualmin server and its secondary DNS server(s), then DNS validation cannot work.
Wildcards are not recommended, in general, but they can’t be validated in Virtualmin if Virtualmin is not managing your DNS, because it requires immediate creation of a TXT record with the necessary information.
A records are absolutely irrelevant here.
You posted another log for a non-wildcard request, which shows 404 errors from the web server, which is always one of three things.
DNS is wrong. Let’s Encrypt validation server is hitting the wrong web server when it tries to request the verification file. If you have correct A records this isn’t you.
You have a proxy or redirect preventing access to the .well-known path where Let’s Encrypt verification file must be accessible. Check this by putting an HTML or text file in /home/domainname/public_html/.well-known/ and see if you can browse to it. I assume you cannot. You have to fix that.
Misconfiguration of Apache (or nginx) Virtual Hosts causing the wrong site to be served. Browse to the domain (without https), do you see the right site? If not, fix that.
You can search for either of these problems, they’ve been discussed a ton, and it can literally only ever be one of those three things (wildcards can only be a DNS problem, because wildcards can only be validated via DNS).