Let's Encrypt Failing on one new virtual domain

Nice idea - but that got the same refusals as always. Oh, and also tried only
anoyingdomain.com

Are you able to do the file compare - your server file with the file on Git (you can just copy the text and put it in a file locally)?

Was that not what I posted Nov 2 above (the nginx .cnf) in response to Ilia ? that started the side issue about the regex line?

I meant (the server file)

ā€œ/usr/share/webmin/virtualmin-nginx/virtual_feature.plā€

and the contents\code at

ā€œvirtualmin-nginx/virtual_feature.pl at master Ā· virtualmin/virtualmin-nginx Ā· GitHubā€

Comparing those 2.

As it looks to me as if that perl file creates\updates the nginx.cnf file.

@Dibs
Well that was hard work (probably harder than it could have been - my lack of knowledge) 3218 lines of code most of which made little sense to me and nor should it. But as far as I could see, scanning what appeared to be tortuous to maintain, was the same as the Git version - well that is what I would expect. Especially as it is a new box + new Virtualmin download.

I also just started over yet again. this time using the anoyingdomain.com as the FQDN and Host default domain. (so no additional virtual domain) but it still fails to pick up SSL from Letā€™s Encrypt.
the http page shows ok so this remains a problem.

Website Enabled

Host default domain

Also Iā€™ve noted in the ā€œVirtual Server Action Logā€ entries by a webmin pl script of Created Let's Encrypt DNS record for ****.com followed 3 seconds later by Removed Let's Encrypt DNS record for ****.com Now this might be correct but I thought the addition was managed by the Letā€™s Encrypt certbot an not by webmin. Is webmin deleting the SSL as soon as LE creates it?

There were too many requests of a given type :: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

Oh well - so it is true they really donā€™t like this domain name
If they didnā€™t keep failing for no justifiable clear reason Iā€™d stop trying.

I read somewhere else to try a ping on the domain name if Letā€™s Encrypt is failing to find A records. So I did. Not a problem. Correct IP

1 Like

Even more problems this morning

Different domain different DO box different Virtualmin install (same OS and versions)
This has failed in just the same way:
Requesting a certificate for *****.online, www.*****.online from Let's Encrypt .. .. request failed : Web-based validation failed : DNS-based validation failed :

Iā€™m beginning to take this personally

Using a few more tools to attempt to get to the root of this problem

gives me:

Info: Html-Content with meta and/or script, may be a problem creating a Letsencrypt certificate using http-01 validation

and https://dnssec-analyzer.verisignlabs.com/
indicates DNSSEC problems for the domain

No RRSIGs found

but still no solution :frowning:

This is not a problem at all. You could simply skip setting up DNSSEC to avoid additional complexity.

This issue is not related to Virtualmin itself. Your domain must be publicly available for for Letā€™s Encrypt validation to be successful. For that to happen you should configure DNS for your domain correctly. You can check how the worlds sees you domain DNS configuration using DNS Checker website.

If you search Letā€™s Encrypt Community forums those kind of questions are everywhere.

1 Like

I donā€™t think I have (well not intedntionally) and no idea how to disable it,

I have checked with just about every tool I can find including
nslookup
dig
dig + trace
whois

they all show the correct IP4 as shown on the A records (and IP6) this has been an issue for over a week it is a .email tld (but I have the same problem with a .info and .online tld so I doubt if that is the reason)

I have even tried a OS upgrade to Ubuntu Linux 22.04.1 (no joy with that either)

Using virtual-server.name - Server Configuration ā‡¾ DNS Options page and most importantly removing any DNSSEC related records from your domain registrar.

Check with external tools like dnschecker.org.

I have even tried a OS upgrade to Ubuntu Linux 22.04.1 (no joy with that either)

Virtualmin doesnā€™t perform OS upgrades, itā€™s done by the package manager. And, please do not switch subjects.

I have checked that and it has always been set as ā€œNoā€
As for DO and Gandi - I do not understand why they would have changed and added DNSSEC (Remember this was/has been working fine for years on a different DO droplet until I moved the domain on Nov 1.

Yes. That was one of them. Result ticks and correct IP4 in all of them (but removing the default CD check (DNSSEC) does result in a slightly less complete map. BUT plenty for LE to find.

Sorry. Not quite a change of subject. In my frustration over this. I have completely destroyed the DO droplet and started a new one with newly loaded Virtualmin LEMP and very little else. I even tried another domain name (actually 3) each as primary host domains (I wanted to eliminate both the domain name and the virtual hosting as a problem)
I have also tried the basic box with no Virtualmin (in preparation for giving up all hope) and the cert bot - but even that fails.

So I am pretty sure it is not Virtualmin most likely something that has happened either at DO or Gandi.

You could spin up a VPS at Linode - plenty of discount codes about to effectively get a free one or 3 for a month (or 2)ā€¦

This would confirm\discount the theory of whether you have an issue at Do\Gandi.

PM if you need a code for Linode.

Thanks, that is a good idea - Iā€™ll add it ToDo for tomorrow. Though will have to wait 48hrs for NS record changes/domain transfer. Iā€™m afraid Iā€™m quite a loyal user of DO and have several droplets on the go. Less of a fan of Gandi (but up to now a happy user).

Well that was exciting !NOT!
@Dibs

  • Set up new box at Linode.
  • Went back to Gandi - pointed the NS to the Linode NS and disabled DNSSEC (they make that an option)
  • waited until 100% DNS Check for both A and AAAA
  • installed Virtualmin on box (no errors)
  • requested SSH from LE
    => STILL same set of errors :frowning:

It doesnā€™t make sense that this thread is still going. This is not a complicated problem.

Letā€™s Encrypt fails for one of two reasons 99.99% of the time. Fix them, and itā€™ll work.

  1. Are there DNS records for every domain name you are trying to get a certificate for, and do they point to the Virtualmin server? Are you sure? Do not make this complicated with DNS checkers and other crap that just confuses the issue. Only A records and CNAME records matter here. Just do host domain.tld or nslookup domain.tld somewhere other than the server itself.
  2. Can you access the filesystem in the .well-known directory for all of those domains? Create a file in public_html/.well-known/test.html and visit http://domain.tld/.well-known/test.html in your browser. If you cannot reach it, this is why it fails. Fix that. Itā€™s either a redirect rule or a proxy rule or something else sucking up the request.

Thatā€™s it.

@Stegan - assuming Gandi is a registrar: use their nameservers and create your A\CNAME records there. The IP address needs to point to your VPS at Linode.

Anything else is probably just over-complicating matters.

This assumes that you have Virtualmin installed on a VPS, a virtual server created (only with HTTP but no HTTPS\SSL) and if nothing else a ā€œHello Worldā€ page at the root (for the Virtual Server) and you see that page when browsing to it via

http://www.annoyingdomain.com.

Then, in Virtualmin enable SSL - browing to

https://www.annoyingdomain.com.

should give you a cert ā€œerrorā€ as it should be using a self issued cert.

[Do Step 2 in Joeā€™s reply in post 57 at this point]

Then request an LE cert.

I donā€™t understand why either. Perhaps it is because no one knows a solution? Perhaps it is because I do not understand why. Perhaps there is no clear help for a noob user? The amount of life energy I have wasted on this defies belief.

But I do appreciate everyoneā€™s 2c thrown at it.

The fact is it remains unresolved.

In answer to your questions:

  1. I have stuck with the one domain name for now (I accept although the other domain names were all failing with the same error, they are confusing the problem.) So YES the A records now point to the box on Linode. They were put there by Linode along with the AAAA record. They are confirmed by DNS Checkers (not just my idea - see above) and as I also said above nslookup (from other boxes show the correct IP4 address. AND if you put the IP4 in a browser (or the domain) you get the ā€œWebsite Enabledā€ default page.

  2. AS before can reach the TEST PAGE on the new box (yes it is a new page) just as before I had to create the sub dir ā€œ.well-knownā€ in public_html before creating the file. which loads perfectly in the browser.

and yes LE still issues the same errors as in my first post when I use Virtualmin. So much for 99.99% of the time.

As this is now on a Linode box Iā€™m reasonably comfortable to PM or email the IP4 or even domain name so you can test for yourself.

What is the full error?