Just added 2 more domains. First went perfect no problem a breeze - thanks the Virtualmin default page showing with https All ready to go
The second domain failed with Letās Encrypt errors and I canāt figure out why.
The error log displayed
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for *****.com
dns-01 challenge for www.*****.com
Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl
Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl
Waiting for verification...
Challenge failed for domain *****.com
Challenge failed for domain www.*****.com
dns-01 challenge for *****.com
dns-01 challenge for www.*****.com
Cleaning up challenges
Running manual-cleanup-hook command: /etc/webmin/webmin/letsencrypt-cleanup.pl
Running manual-cleanup-hook command: /etc/webmin/webmin/letsencrypt-cleanup.pl
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: *****.com
Type: dns
Detail: DNS problem: SERVFAIL looking up TXT for
_acme-challenge.*****.com - the domain's nameservers may be
malfunctioning
Domain: www.*****.com
Type: dns
Detail: DNS problem: SERVFAIL looking up TXT for
_acme-challenge.www.*****.com - the domain's nameservers may
be malfunctioning
I donāt understand I did not create TXT records for the other domain !
The nameservers are correct just like the first domain but the site is not found, no default page - no certificate
i believe itās a problem of letās encrypt and not virtualmin sometimes is successful sometimes fail i believe it is a problem from letās encrypt even with plesk i face the same problem it fails to receive also certificates
But have now tried 4 times to make the request through Virtualmin ā Server Configuration ā SSL Certificate [Letās Encrypt] all with the same result.
I even added th TXT record as indicated in the above log, but it still fails.
In Virtualmin ā Server Configuration ā DNS Records: Both A records are there and point to the correct IPv4
DNS validation is the fallback method. Web validation is preferred and happens first. So, why is it using DNS validation?
And, if you do need to use DNS validation for some reason, you donāt create the TXT records, ACME or Virtualmin does, and they are created in realtimeā¦because they change on every request. If you arenāt hosting DNS locally (or in some way managed by Virtualmin), you cannot use DNS validation. Web validation can work regardless of where DNS is hosted.
It looks like Virtualmin is not managing your DNS, and so the TXT records canāt be created.
So: I recommend you use the default web validation. If that fails, post the errors.
Joe
Thanks for the input. Iām not sure I understand. I really have no idea why this domain failed yet the other one added early today, went through and is working well since.
I have gone back to the original domain issuer and checked the nameservers there (the domain was created several years ago and was working well. The nameservers there point to the box on DO where the droplet was created and the A records on the Droplet were changed yesterday (I have never known propagation to take over 36 hours)
Virtualmin created its own self-signed certificate as a default and that is showing as the ācurrent certificateā on the SSL Certificate page.
Itās not clear to me what youāre saying here. Is the droplet your Virtualmin system that is trying to issue a cert?
And, I continue to wonder why DNS is involved in validation for Letās Encrypt at all. If web service is working right, and you donāt have an app, redirect, or proxy rule thatās sucking up requests to .well-known directory, DNS will never be involved (except in looking up the names). There should be errors before the DNS validation failures that is what you should be trying to solve.
Thanks once again Joe for your valued input. Iād hate to think Iām confusing things.
In an attempt to clarify:
Virtualmin is running on a DO droplet. (brand new 31/10)
The domain was registered at a well known French Company many years ago.
The domain nameservers have always pointed to DO nameservers BUT hosted on a different droplet/system running a pascal driven website.
Objective: I am transferring to my DO droplet.
So have added the domain name to my DO droplet (A records at DO)
(the old droplet host has been destroyed ā¦ so is not interfering)
The domain was added to my box as a virtual server (see initial post above this was at the same time as doing the same process for a different project/domain that worked without a hitch)
I assumed (after a wait for 24hrs for propagation) all would be managed the same by Virtualmin. The only webservice that is working right is the display of the default Virtualmin web page but obviously only http - I have not yet brought the original pages in from a backup so no pascal)
Oh! as for this morning I have just transferred a 3rd domain into my box - again this went completely without a problem - didnāt have to wait this one went in less than 12 hrs. Virtualmin and Letās Encrypt perfect.
I have also looked at the propagation Tool used above and again it is showing most of the world as failing but slightly better than last night. China, Peru, Spain, Canada, Australia and a few other obscure countries so really do not understand why Letās Encrypt cannot find the A records. It is still failing.
I guess the obvious option is to delete the virtual server from Virtualmin and try again from step 1 - as today progresses that might be my only option.
DNS would be the only validation method if Also request wildcard certificate? is selected.
I guess the obvious option is to delete the virtual server from Virtualmin and try again from step 1 - as today progresses that might be my only option.
Maybe it would be fastest, although you could debug it deeper first. Try creating a test.txt file under /home/your-domain/public_html/.well-known with some content and try accessing it via http://your-domain.com/.well-known/text.txtin your browser.
Also, when requesting SSL certificate at Server Configuration ā¾ SSL Certificate page, if you set Check connectivity first? to Test connectivity, does it complain about something?
Could not find the option to Check connectivity first but attempted Letās Encrypt but still failed with same log.
I have also repeated a propagation check - the US now seem to be awake and globally A records OK almost everywhere. AAAA and MX records catching up fast.
Anyone know if Letās encrypt objects to certain domains tlds or IP ?
OK so meanwhile back at the ranch - Iāve given up! Pressed the Big RED button and deleted the virtual domain.
Started over again well it only takes a few minutes to add another top level virtual domain,
But Failed again!
Exactly the same as above
Requesting a certificate for *****.tld, www.*****.tld from Let's Encrypt ..
.. request failed : Web-based validation failed :
.. DNS-based validation failed :
everything else done ok and default page refreshed in browser.
Sorry naresh335,
I donāt understand āhttp based validationā? Of āLetās encryptā?
Do you mean āIs the site visible with httpā ? - Yes
Do you mean instigating Certbot the old way? apt-get install python-certbot-nginx - No ( but how without breaking all the other virtual domains? and why?)
Everything (that log) seems to be telling me it is a DNS issue yet it canāt be as I can see the default page in http so it must be SSL
I thought why not create a subserver of one of the domains that already has a SSL working?
Seemed like a good idea No?
Even that FAILED - Iām beginning to suspect Letās Encrypt has something against my IP.
This is the source of the problem. You need to figure our what is making a redirect. Start from looking at Server Configuration ā¾ Website Redirects page.
no problem a breeze - thanks the Virtualmin default page showing with https All ready to go 
and I canāt figure out why.
