Got it, but I'm thinking enough great to... break my automation script. 
These services did run always as domain suffix so I recently decided to adopt https mantaining the same logic, thats it..
you can't avoid having a rewrite(as wildcard doesn't cover sub-subdomain) so I think it'd look better rewrite everything as subdir than url format changing back and forth
4 Likes
Yes, it is a fast solution to my renewal script problem.
But I see subdomains making everything more simple and comphriensive.
I neither can't resist to ask LE to invent the "wild-car" in place of the wheel 
Absolutely for posterity, not for myself....
Daniele Bonini
PS: the blinking eye could be the time, not the beer..
Because then I (and everyone else on the Internet) could request a wildcard cert for your domain and the validation proof would already be there - and I would get a wildcard cert for your domain.
The TXT record value must change.
To ensure that the person making the cert request is the one putting the TXT record in DNS.
Something a bit more complicated but along that line of thinking and would still fail security scrutiny... might be:
To pass some shared token encrypted with the private key that encrypted the currently issued wildcard.
That would prove that the requestor holds a valid certificate for that domain.
But what happens when the domain is sold...
The previous owner can continue to renew their cert for a domain they no longer own.
So, you see, each proof must be made with a unique entry; And it must be seen in the current DNS zone.
4 Likes
Ie: while the TXT record does always its job the .wellknown file is very nice to have, in fact it is a "beauty"... that must have some defined content inside itself.
Can I play around this "content" by setting it with a dynamic value like
echo sha256($check_datetime + $cert_privatekey) > .wellknown/$check_wellfile
that let Certbot to complete its check?
This could be automated by the hook....
No you need to do it this way.
DNS-01 challenge
This challenge asks you to prove that you control the DNS for your domain name by putting a specific value in a TXT record under that domain name. It is harder to configure than HTTP-01, but can work in scenarios that HTTP-01 can’t. It also allows you to issue wildcard certificates. After Let’s Encrypt gives your ACME client a token, your client will create a TXT record derived from that token and your account key, and put that record at _acme-challenge.<YOUR_DOMAIN>. Then Let’s Encrypt will query the DNS system for that record. If it finds a match, you can proceed to issue a certificate!
And for deep details look at RFC 8555: Automatic Certificate Management Environment (ACME)
2 Likes
A: This can't be compared as you expect:
- LE would have to know the privatekey [VERY BAD - no one should ever know that]
- LE would have to know the exact datetime used in the hash [impossible to know - when outside your system]
B. There is already a perfectly good working wheel to carry the HTTP-01 authentication.
2 Likes
If DNS validation with wildcards is difficult to implement or cumbersome, you might be better off seeking a rate limit adjustment, or if it's truly a public suffix for customers getting it listed.
Then something like caddy's on demand tls might work. It asks an endpoint that you provide if it's allowed to get a certificate then gets one for the site automatically.
6 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.