Let's Encrypt Failing on one new virtual domain

Operating system Ubuntu Linux 20.04.5
Virtualmin version 7.3-1
LEMP Bundle

Just added 2 more domains. First went perfect :smiley: no problem a breeze - thanks the Virtualmin default page showing with https All ready to go :+1:

The second domain failed with Let’s Encrypt errors :frowning_face: 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.
 - 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

   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 :-1:

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

thank you


Thanks for the suggestion.

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

Still puzzled :confused:

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.

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.

loading the page in the browse now seems to work but only http. Ive also used the tool at DNS Propagation Test for example.com - Explore the results but it indicates Not Found except for Turkey and Brazil !!

Something seriously wrong with propagation so I’m going to sleep on it and try again tomorrow AM when they may have all woken up.

I have never known propagation take this long

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?

Did that and it works (slight glitch with FTP needed root access but done and displays in browser as http://domain.tld

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 ?

As far as I know – no. As long as a domain publicly available and your ownership can be validated, I don’t think Let’s Encrypt cares.

1 Like

Does the initial request to http://your-domain.com/.well-known/text.txt got redirected to http://your-domain.com?

Yes it did.

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.

have you tried http based validation ?

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 :anguished:

OK even more bad!

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.

1 Like

It says:
No website redirects have been defined yet.
and the same for all the virtual servers. I’m assuming this is correct yes?

It is important to figure out what is making this redirect. What is the content of the web server config for the virtual server in question?

Sorry I’m an old “newbe” can you point me where to look - do you mean the nginx config?
or somewhere in the Virtualmin menu?