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
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
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.
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
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.
- 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
ornslookup domain.tld
somewhere other than the server itself. - 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 visithttp://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:
-
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.
-
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?