First of all, not sure if this is really the correct section. If not, I am sorry.
I wanted to test the wildcard function for the SSL certs from my websites.
The certbot package is installed too.
I tried to use the manual way:
certbot -d domain.tld --manual --preferred-challenges dns certonly
I do know that I need to add a DNS entry. The odd thing is that from the tutorials/manuals, ones I run that command I should get a “key” which I need to combine with the entry. Oddly, when I do run it the requests gets finished and I don’t receive that mentioned key.
When I try to request a cert with the wildcard function marked (in webmin), I get this message (which is pretty much normal since I didn’t add the entry yet due to missing the key):
Failed authorization procedure. domain.tld (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.domain.tld, domain.tld (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.domain.tld
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: domain.tld
Type: unauthorized
Detail: No TXT record found at _acme-challenge.domain.tld
Somewhere I do miss something, but I currently don’t know where sadly.
If someone got a hint for me, that would be quite helpful.
When more information are required to do a proper statement, then just tell me what and I will do so.
If “key” means the 43-character token you might find it in logs if one was issued. Thing is, the TXT record workaround shouldn’t be necessary even though it can help get the job done. When DNS validation fails are you making new attempts afterward (without maxing out rate limits)? I think network hiccups cause problems often enough to fool us into pointing blame in our direction when the problem could be any network between our servers and Let’s Encrypt. I’ve seen Let’s Encrypt IPs in errors or logs time out when I trace or ping them but eventually validation succeeds after a second or third attempt.
I suggest not changing anything and keep trying if you are confident in your DNS setup. If it continues to fail try to figure out what’s slowing down lookups. If there’s a network issue http validation might fail too.
And since you’re comfortable at the command line you might as well try certbot’s dry run option. It isn’t in the web panel but evidently Virtualmin’s API can do it. Once a dry run succeeds be sure to replace the fake certificate with a real one.
The error says there is no TXT record, so that’s what’s happening as you note. I’ve never issued a wildcard in this circumstance (I’ve always either used Virtualmin or I was validating a zone hosted in Route 53, and had setup certbot to be able to write to the zone).
So, to get the obvious questions out of the way:
Is DNS hosted locally and managed by Virtualmin? If not, you can’t issue a wildcard with Virtualmin (and I don’t know if Webmin’s Let’s Encrypt form even offers a wildcard option…I don’t know if it even tries to validate via DNS).
Are the other DNS servers that are supposed to be secondaries? If so, are you sure zone transfers are working? It’s possible for Let’s Encrypt to query a different DNS server than the Virtualmin server itself, and if it doesn’t have that TXT record, it will fail.
I’m not sure what would cause certbot to respond appropriately when called on the command line, but you can test with --test-cert, which won’t trigger rate limited as quickly.
Thanks @Joe .
I highly assume my DNS is not managed from Virtualmin since I didn’t setup bind or any other service and I usually manage DNS settings at my domain hosters.
I could already figure out the “problem”. As I already know the record was missing due to not having the token. For whatever reasons I do get them now when I try to setup a cert with the dns challenge via certbot.
I just need to make sure to clear the old entries there and then test how long the propagation time for my hosters DNS system is. I know its fast, but that needs to be precise to get the job done.
I guess more tests with test-cert and dry-run are needed.
Gonna report back as soon as I am done, maybe it might help someone in the future or spark some useful thoughts.
Oh, as always (and for the same future users who might stumble on this thread), I recommend not using wildcards. They have a variety of security implications, and they’re (usually) harder to validate.
I know and that’s why I am not a huge fan of it. I am just testing around about one thing.
If I can’t get that done how I want it, I will not use wildcards anyways.
And as you, I wouldn’t recommend unless really really needed.
