I wonder why the automatic process of renewing a LE certificate is now failing.
It says the DNS based verification has failed, was expecting for a TXT entry that has NEVER been here before. Something like :
Detail: DNS problem: NXDOMAIN looking up TXT for
_acme-challenge.myfailingdomain - check that a DNS record exists for
this domain
I then tried to create such an entry in the DNS zone, but verification still fails,
stating this time that the content expected is not valid.
After searching the web, I see taht is supposed to contain a token.
But what is that token, how can I get it ?
Isn’t this so-called all-automatic process malfunctionning ?
Any kind help very much appreciated.
Thank you again to the team behind Virtualmin ! You rock !
Well, thanks to both of you, Stefan and Joe, but that is not relevant here.
My A records are OK, this is not the point of the error message that says the content of the TXT entry is incorrect. My DNS are handled outside the server (OVH) and have a very good response time, low TTL. After searching on the Internet, I found this interesting post that clearly explains an alternative method to obtain the missing token. It works, token is being validated from the outsided DNS in a breeze.
The question is : why do I have to interfere in all this (messy so-called automatic renewal that should be handle automatically by Virtualmin, don’t you think ?). Another one, also : why does this work on some virtualhosts and not on that one (and another one too).
More over, by following the explanations in the link I sent, I have to copy and paste the content of cert files generated in a ‘live’ folder in etc/letsencrypt if I want to them to be taken in account (by the way, the certificate truns OK but an error message is still displayed in the LE section of the SSL subsection… bug ?)
Isn’t this the point. Why is web validation failing?
and why is it falling back on DNS validation that also fails?
makes me suspect A records (who/where are they set)?
I told OP how to figure that out in the very next sentence.
DNS validation will always fail if Virtualmin is not managing DNS. It can’t possibly work. If Virtualmin were managing DNS, it would not fail. A records are irrelevant to DNS validation. DNS validation requests a TXT record with a specific string in it.
@Joe
OK, then how can I get (or… guess) the specific string you are mentioning ? Only the step by step validation process seen in the link I found allows this. The virtualmin process is full-auto and doesn’t let the end user participate. The DNS option is always activated.
That’s not what I suggested you do. I suggested you fix web validation.
Do what I said above: Put a file in .well-known, and if you can’t browse to it, fix whatever reason that is. It’s never anything complicated, but I can’t possibly guess which one applies to you until you do the necessary troubleshooting steps.
I’ll also mention that Let’s Encrypt validation is a heavily discussed topic here in the forum. And, since it can only be one of three or four things, it’s usually very easy to fix.
At your command, Joe, but well, I think I can’t do that here ; the situation is :
I want to revalidate mail.domain.com (MX) whose A record is 11.22.33.44
but the domain.com (WWW) A record points somewhere else 55.66.77.88
and I don’t have access to that server.
Tell me why, when I first asked a cert from LE for this very mail.domain.com everything went fine, it installed and ran very well for 90 days. No questions asked, full auto - as always - the bright side of LE.
I am here stating only about renewal. The automatic process of cert renewal that goes usually transparent, suddenly stops there (while working fine for other virtualhosts in the same server).
So, as it can’t validate via web/http, it normally falls back on DNS and asks for a specific content - token - that hasn’t been provided in the due process and that I can’t either provide, thus complains with some “content expected is not valid” !
I repeat, if I manually initiate the process as stated in this link
the process is intelligently conducted and give time to the user to feed the correct token to the expected TXT record. The cert is then being renewed fine (except being put in another directory than the one expected by Virtualmin thus needing to copy the contents of the generated certs in the Update Certificate and Key/Pasted text boxes).
That link is about using certbot directly. If you want to use certbot directly, you can do that.
If Virtualmin is not managing DNS, you cannot get a certificate via DNS validation using Virtualmin.
These are two different names. Unless you’re trying to get a certificate that matches both, it is completely irrelevant that they are in two different places (unless Virtualmin thinks they’re on the same server and is trying to validate for both domains, which you obviously should not do). What happens on domain.com is irrelevant, if you’re trying to get a certificate for mail.domain.com, and vice versa.
Web validation makes a request to .well-known directory for the the domain(s) associated with the requested certificate.
DNS validation puts a token in a TXT record in the zone. If you control the zone you control all the domain names within it. But, Virtualmin cannot do DNS validation if it is not managing your DNS. If you are trying to use DNS validation, and Virtualmin is not managing your DNS and you cannot use web validation for some reason, you must use certbot and either one of the APIs supported by certbot, or the manual process.
But, if you’re trying to do it manually by creating a TXT record yourself at time of renewal, you cannot expect it to be automatic!
Edit: To be clear, the TXT record changes every time you validate (which happens every time you renew). You can’t create the TXT record once and forget about it, and have it renew automatically. Something has to update DNS on every renewal.
Well, Joe, thank you for that clear answer, we are close to an end. Ditching external DNS seems a good idea. I am perfectly unable to tell you why all my certs used to renew fine for years without using inside DNS (I’ve always kept the DNS option ticked because I noticed that without doing this the DMARC and DKIM would not work - but now, I realize this is totally relevant with what you wrote above). However, externalizing DNS requires to copy-paste most of the DNS records provided by Virtualmin (for a good validation of DMARC and DKIM records or https://www.mail-tester.com/ checks for example).
I guess I will reconsider DNS management from now on, while using manual renewal of my failing certs the time I set all this up : secure DNS operation requires several/slave and master servers to operate smoothly, it takes time to set that up and test the whole thing…
but well, I think I can’t do that here ; the situation is :