Unable to `renew` or `certonly` with wildcard domains

Server
1

I’d been waiting for certbot 0.22 to be published in order to be able to use wildcard certificates. So finally today I checked again, lo and behold, it was there and ready.

In preparation for 0.22 to be available, I had tried a few things not realizing 0.21 didn’t have the feature yet. With that in mind, I had come up with the following command that I thought would work:

certbot renew --server https://acme-v02.api.letsencrypt.org/directory --nginx -d *.evie.codes -d *.omnic.xyz -d *.evie-banned.me

From this I got the following error: Currently, the renew verb is capable of either renewing all installed certificates that are due to be renewed or renewing a single certificate specified by its name. If you would like to renew specific certificates by their domains, use the certonly command instead. The renew verb may provide other options for selecting certificates to renew in the future.

Ok I thought, let’s try certonly…

certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --nginx -d *.evie.codes -d *.omnic.xyz -d *.evie-banned.me

I got the following logs:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address: <redacted>
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
<Agree/Cancel on ToS, I agreed>
<Yes/No on sharing email with the EFF, I agreed>
Starting new HTTPS connection (1): supporters.eff.org
Obtaining a new certificate
Performing the following challenges:
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.
<Above line duplicated (this one in white, first one in red)>
<Important Notes>

I also tried certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --webroot -w /root/wordpress -d *.evie.codes -d *.omnic.xyz -d *.evie-banned.me but got the same as above, minus the 2 questions and the “important notes”.

Note that I’m hosting this on an OVH VPS, my research into the user guide leads me to believe, from this error message, I would “have” to modify the DNS to include a TXT entry, but all plugins available are for other hosts, there doesn’t seem to be a manual one. My domain is registered on name.com for reference.

Is there an easy way out of this so I can get wildcards?

2

By the way, due to how wildcards work, and because Let's Encrypt doesn't automatically add extra names to certificates, that would be valid for names like https://www.evie.codes/ but not the parent domain like https://evie.codes/. You may want to use "-d evie.codes -d *.evie.codes -d omnic.xyz -d *.omnic.xyz -d evie-banned.me -d *.evie-banned.me" to cover those too.

For what it's worth, the ACME client acme.sh comes with a Name.com plugin.

I like Certbot, but if you want to stick with Name.com as a DNS provider, switching clients would be the path of least resistance.

There is -- you can use, for example, "certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'".

But you would be stuck running that at least every 90 days to manually renew your certificate. :slightly_frowning_face: So automating it, if possible, is far more pleasant.

3

Ok so let’s say I went for acme.sh instead of certbot, what sort of changes would I need to make? Uninstall certbot completely, follow the acme.sh readme and go from there? acme.sh seems easy enough to setup, and if that’s what it takes, I’m all for it.

4

You can also transfer your domain to another provider. I really dislike Name and recommend against anyone ever using them.

A few years back I realized they were doing wildcard DNS from my unregistered subdomains to an affiliate marketing scheme by default. If you set up DNS for example.com and www.example.com – unless you knew to specifically turn this feature off, any requests for foo.example.com would not return an NXDOMAIN but instead route as a valid DNS entry to a 3rd party marketing company that served up a bunch of ads. IIRC, one had to set up a wildcard DNS entry to turn this behavior off.

This was a complete nightmare for security and data-compliance concerns – a typo or removing a domain would send cookies/etc onto the third party websites. They insisted this was a legitimate practice for months, but finally backed down after they kept getting bad press. Some people discovered this behavior before me, other after me; someone got enough traction on HackerNews or twitter for them to finally stop.

In any event, IMHO you should use someone else. They pulled this scam for a long time insisting it was legitimate. Name does not deserve to be trusted with anyones DNS.

5

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