Certbot: How do I enable ACMEv2 and retrieval of wildcard certificates?

[SunburntRock89]

If you're having trouble using Certbot and aren't sure you've found a bug or
request for a new feature, please first try asking for help at
https://community.letsencrypt.org/. There is a much larger community there of
people familiar with the project who will be able to more quickly answer your
questions.

My operating system is (include version):

Ubuntu 16.04 Server.

I installed Certbot with (certbot-auto, OS package manager, pip, etc):

2 Versions: Plesk Package, certbot package from certbot repo.
Certbot package version: 0.21.1

I ran this command and it produced this output:

In: certbot -d *.works.wtf certonly
Out: Wildcard domains are not supported: *.works.wtf

Certbot's behavior differed from what I expected because:

The LetsEncrypt site says that Certbot is now compatable with the ACMEv2 api.

Here is a Certbot log showing the issue (if available):

Logs are stored in /var/log/letsencrypt by default. Feel free to redact domains, e-mail and IP addresses as you see fit.

Here is the relevant nginx server block or Apache virtualhost for the domain I am configuring:

N/A, certonly

[ArchangeGabriel]

You must use DNS-01 challenge. Which mean you must have a way to modify and publish and updated DNS zone from withing your server.

[SunburntRock89]

Could you please tell me the flag for this?

[ArchangeGabriel]

It’s not just a flag, but everything is available in the doc. They are some plugins for several DNS providers listed there, if yours is not you might open a feature request here to ask support for it (there are already some open for things like Gandi for instance, so be sure to use the search before opening a new one).

[ArchangeGabriel]

Hum no, you need certbot >= 0.22 in fact, sorry for having missed that in your first post.

[SunburntRock89]

OK.... How do I go about installing that? Do I have to compile from source?

[ArchangeGabriel]

You can either wait for it to be published in the PPA, install via pip or something similar or indeed build from source.

Would I be you, I would rather wait on the official package to be updated. This will let you some time to look at setting up the DNS challenge properly, which you can already try without wildcard just to check everything works, and then when the update will be available (which should not take long), you will be ready to get your wildcard cert.

[talyguryn]

Yeah, you can use certbot from sources

root@cs12:~# git clone https://github.com/certbot/certbot
...
root@cs12:~# DOMAIN=example.com
root@cs12:~# cd certbot 
root@cs12:~/certbot# ./certbot-auto certonly --manual -d *.$DOMAIN -d $DOMAIN --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
...
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:

qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

Add TXT record press Enter. You will get another one record. Add it too.

Then check in the second terminal window if records were deployed:

root@cs12:~# host -t txt _acme-challenge.example.com
_acme-challenge.example.com descriptive text "qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI"
_acme-challenge.example.com descriptive text "oMmMa-fDLlebdUhvhMD5MinJ2EeFpdP0F9lUPTShh4w"

If all right then go back and press Enter

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-06-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Update: Check out complete guide on Gist with steps for installing, setting up and renewing certs.

[ohemorange]

Thanks for answering so thoroughly @ArchangeGabriel! We're working on updating our packages for Ubuntu, hopefully they'll be out soon.

[ArchangeGabriel]

@ohemorange You’re welcome! Honestly, I feared that we would see an influx of people trying to get wildcard certificates while having no insights about what the DNS-01 challenge is, but apparently it did not happen (yet at least).

[AubreyHewes]

Nice one @talyguryn, As a follow up on @talyguryn

When creating one cert on apex with wildcard you will get __two__ challenges..

Using -d "example.com, *.example.com" _give me a cert on apex and wildcard on the apex_

You will be challenged _twice_, once for example.com and again for *.example.com

So don't think that on the second challenge it has failed.. and you need to change the value. just add the extra challenge to the dns. Wait for propagation and continue,

Possibly the output should be changed so that it is easier to see which domain is challenged?

[sinkcup]

docs: https://sinkcup.github.io/letsencrypt-wildcard-certificate

[nathan-alden-sr]

@AubreyHewes, I'm having the same issue. I'm not sure how to issue a single certificate for both example.com and *.example.com. Unfortunately, certbot requires that I modify the TXT record twice. This causes validation to fail for one of the domains. Is there a way around this?

[mnordhoff]

@nathan-alden You need to set both TXT records at the same time. Don't delete the first one when adding the second one.

[AubreyHewes]

@nathan-alden
You get two challenges.. This _seems_ like certbot wants you to modify the same TXT again. But the second value is for the second domain, So add a new TXT record for the second domain.

i.e.
If using -d "example.com,*.example.com" the first challenge is for example.com so add a TXT for this. Continue after propagation.
The second challenge is for *.example.com so add a TXT for this. Continue after propagation.

[fizux]

I had a good experience using the docker version. As a side note, make sure to set the TTL for the TXT entry to something like 1 minute so that you don't have to wait an hour for the 2nd entry to propagate.

docker run -it --name certbot \
  -v <certs>:/etc/letsencrypt \
  -v <logs>:/var/lib/letsencrypt \
  certbot/certbot certonly --manual \ 
  -d *.<domain.com> -d <domain.com> \
  --agree-tos \
  --manual-public-ip-logging-ok \ 
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory

[lorinkoz]

Wondering. Why do we require dns-01. Can't you just spawn a server on port 80 (any form of http challenge) and probe I own the wildcard domain by generating N random subdomains and connecting?

[robertvalik]

@AubreyHewes, I have found out that you need only one challenge/record in DNS - just have to guess the correct one.

I have one certificate for four domains and their wildcards. Every domain has only one TXT _acme-challenge. It is pretty inconsistent as three domains work with the first challenge in certbot output and the values seem to be the same every time I run it.

The fourth domain does not work with first record in output but works with second and this one seems to change every time I run the certbot.

I use this command:

/usr/bin/certbot --renew-by-default certonly --manual --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns-01 -w /usr/share/nginx/letsencrypt-root/ -d *.domain1.sk -d domain1.sk -d *.domain2.sk -d domain2.sk -d *.domain3.sk -d domain3.sk -d *.domain4.sk -d domain4.sk

I did this by trial and error - I just did not know that you can have two same DNS records with different values :-) Next time I will try that.

[mnordhoff]

@robertvalik It's not possible to use the same TXT record value for two different validations, including example.com and *.example.com.

Let's Encrypt allows an authorization to be reused for a while, currently 30 days. If your account validated something recently, it can issue more certs without validating again. However, due to Certbot limitations (#5342), Certbot asks you to set the same TXT record again, even though it won't be checked again.

So what must have happened is that there was already a valid authorization for one of the names, so the fact that the necessary DNS record didn't exist anymore didn't matter.

[lorinkoz]

@francoism90 One might want a wildcard domain for several reasons, one could be serving few static subdomains, other, serving potentially infinite subdomains (e.g. software as a service). In the latter case (my case,) one already has a wildcard in DNS file, and actually any random subdomain should properly resolve. I am wondering if a form of http challenge could be provided for this scenario. Thanks for all your hard work!

[jbauson]

I had a success to generate certificate by issuing

./certbot-auto certonly --manual -d *.example.com -d example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Now I'm just wondering on how can I renew the certificates

<> certbot renew
<> certbot-renew
<> certbot-auto renew

I'm confused, I tried ./certbot-auto renew since I used the same command when requesting, but I just want to make sure if it's the correct way.

[bekab95]

Can we automate wildcard certification ?

[mnordhoff]

@ufo911 Of course. For example, using Certbot's RFC 2136 plugin:

certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

Or the acme-dns manual auth hook:

certbot certonly \
  --debug-challenges \
  --manual \
  --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

https://certbot.eff.org/docs/using.html
https://community.letsencrypt.org/t/getting-wildcard-certificates-with-certbot/56285

If you need help, you can post a topic on the Let's Encrypt forum.

[bekab95]

@mnordhoff
is it necessary for DNS TXT record to be live on every renew ?

[ArchangeGabriel]

@ufo911 Of course, a renew is just a certificate request re-using the previous parameters.

[francoism90]

@ArchangeGabriel Stange it is telling me it tells me to set new TXT-records:

#!/bin/bash
certbot certonly \
  --manual \
  --agree-tos \
  --manual-public-ip-logging-ok \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d domain.tld \
  -d "*.domain.tld"

Is this normal? Why are new tokens being generated?

[ArchangeGabriel]

Sorry if I wasn’t clear, yes there is a new TXT record on each request. Because this is a challenge-response validation, and reusing the challenge would be a very bad idea.

So actually you can remove the TXT record as soon as you got the certificate, but there is a new TXT record to publish (and remove once successful) every time you renew.

[francoism90]

@ArchangeGabriel Hmm, don't think that's an option for me. Creating a new TXT-records may take up 24h to complete and if something goes wrong, you'll end up with a lot of downtime.

I'll use the general way instead. :)

[ArchangeGabriel]

Sure, DNS challenge is not the easiest one. But for wildcard, there is no other possibility, at least currently. I don’t know if for instance this could be replaced by sending the challenge to a random subdomain name in the wildcard space (e.g. if you ask for *.domain.com, it would try to read the challenge response at somerandomstring.domain.com to verify you have indeed control on the whole *.domain.com space). This way having your wildcard redirection in DNS would be enough.

[francoism90]

@ArchangeGabriel This would be a good option, but would DNS verification still be needed in this case? Does it offer something needed for a secure wildcard setup?

[ArchangeGabriel]

No, my idea would be to offer an alternative to DNS challenge.

For a wildcard setup, you need to prove control over all the subdomains. The only obvious way to do this is to prove technical ownership of the corresponding DNS zone.

Now I’m wondering whether there could be another way more like the other challenges types. Asking random subdomain would prove that you have control over a wildcard redirection. I don’t know whether that would be enough for the IETF, I guess they have thought about it and there must be some issues.

For instance I’m wondering whether this case is possible:
– somespecificsub.domain.com points towards a given IP;
– *.domain.com and domain.com points towards another IP.

In that case, you could answer requests for the main domain and any subdomain excepted somespecificsub.domain.com. And I think it wouldn’t be right to deliver you a *.domain.com cert. So if that is possible, then we would need some additional setup. Like a permanent TXT record telling that it is authorized to do random subdomain verification for the wildcard challenge response. That way DNS configuration would just be fire-and-forget, and you could more easily validates a wildcard.

Anyway, I don’t know with who this should be discussed and at which point they have considered this setup, neither what are the exact required criterion for delivering a wildcard securely. I guess I should just read the RFC for that, but I don’t have time for this.