Wildcard certicate poorly supported

Got it, but I'm thinking enough great to... break my automation script. :grinning:

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


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 :wink:
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.


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)


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.


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.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.