Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating a certificate request for trusktr.io and *.sk8.earth
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
My web server is (include version): A custom server written by me with Node.js.
The operating system my web server runs on is (include version): Arch Linux with certbot 2.7.4 running on Python 3.9.2 (I don't remember why I'm not on latest Python, but presumably there was an error with 3.10.x at the time when I was setting it up, and maybe that error is gone by now so I should try again).
Both domains are working (but as you can see you'll get a HTTPS warning in your browser):
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Simulating a certificate request for trusktr.io and 4 more domains
The dry run was successful.
I want to reduce work by not having to manage lists in multiple places, so I was hoping a wildcard would do the trick.
The problem, and the solution, are the same as in the two topics you linked. Let's Encrypt requires you use DNS validation in order to obtain a wildcard cert, and the --standalone authenticator you've told certbot to use can't do DNS validation. You'll need to use the DNS authenticator, preferably with a plugin that will automatically make the necessary updates to your DNS records.
Thanks for explaining that, but I've no idea what to do. Can please show sample commands for this case (considering that I manage my DNS records manually via Linode)?
I currently have all the sub-domains I'll be using listed in my DNS settings (A/AAAA), and I would like to automate that too but that's for another day.
Also, be aware that a wildcard cert is only for one level. A cert for *.example.com works for a.example.com and b.example.com, but not for c.d.example.com. (And there's no way to have more than one wildcard in a name.)
Yes, DNS wildcard matching works differently than cert wildcard matching. Don't blame Let's Encrypt. It's how the entire PKI system works including how browsers (and other TLS clients) match URL names against the cert SANs list and all that.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for trusktr.io and *.sk8.earth
Error adding TXT record: 401 Client Error: UNAUTHORIZED for url: https://api.linode.com/v4/domains/1989170/records
Where would I make a feature request for SSL wildcards that can cover any level subdomain?
You might want to look at software like Caddy instead for your web server, which can handle automatically requesting a cert for a specific hostname as soon as it starts being used.
My guess would be the CA/Browser forum, but I wouldn't hold your breath.
You can join as an observer, but you have to complete some paperwork first. At that point, you can make suggestions, but the members don't have to vote on them. I used to be an observer representative there, and I could make suggestions, and the members didn't have to vote on them.
I think multi-level wildcards are something that many people have wanted for a long time and that might have some practical uses. But it's also something that has some major potential for abuse or accidents (imagine a hypothetical certificate valid for *.com that included all subdomains... that would be terrifying).
The rule that you can't have wildcards apply to more than one level of subdomain has existed for long enough that I expect a lot of people at CA/B Forum would be very uneasy with getting rid of it now. I'd personally like to see that discussion happen in order to clarify everyone's understanding of the risks and potential mitigations, but I expect it would end up rejecting the idea.
@schoen, in your hypothetically terrifying example, the wildcard had only one "dot": "*.com"
As more dots are added the less terrifying the example becomes.
How many dots would a wildcard cert require for it to be considered "relatively safe"? Four? Five?
I can't imagine that this would freak anyone out: *.sub3.sub2.sub1.example.com
Could then also be used for all things left of it: (*)*.sub3.sub2.sub1.example.com
Such "wildercards" could then have two requirements:
can only include one * [which must be the left most character in the name]
must contain five [non-consecutive] periods in the name
That would obviously not be allowed because ownership on the internet starts with the second level, enforced by the fact that websites can only be visited with second-level domains (example.com). It simply wouldn't fly.
What might be doable is an additional syntax, one that can only apply for 3rd level or higher, f.e. **.foo.com or **.sub.foo.com
