Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do I enable ACMEv2 and retrieval of wildcard certificates? #5719

Closed
SunburntRock89 opened this issue Mar 13, 2018 · 30 comments

Comments

@SunburntRock89
Copy link

commented Mar 13, 2018

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

This comment has been minimized.

Copy link

commented Mar 13, 2018

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

This comment has been minimized.

Copy link
Author

commented Mar 13, 2018

Could you please tell me the flag for this?

@ArchangeGabriel

This comment has been minimized.

Copy link

commented Mar 13, 2018

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

This comment has been minimized.

Copy link

commented Mar 13, 2018

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

@SunburntRock89

This comment has been minimized.

Copy link
Author

commented Mar 13, 2018

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

@ArchangeGabriel

This comment has been minimized.

Copy link

commented Mar 13, 2018

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

This comment has been minimized.

Copy link

commented Mar 13, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2018

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

@ohemorange ohemorange closed this Mar 14, 2018

@ArchangeGabriel

This comment has been minimized.

Copy link

commented Mar 14, 2018

@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

This comment has been minimized.

Copy link

commented Mar 14, 2018

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

This comment has been minimized.

@nathan-alden

This comment has been minimized.

Copy link

commented Mar 18, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2018

@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

This comment has been minimized.

Copy link

commented Mar 19, 2018

@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

This comment has been minimized.

Copy link

commented Apr 23, 2018

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

This comment has been minimized.

Copy link

commented May 15, 2018

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

This comment has been minimized.

Copy link

commented May 24, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented May 24, 2018

@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

This comment has been minimized.

Copy link

commented May 25, 2018

@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

This comment has been minimized.

Copy link

commented May 27, 2018

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.

@ufo911

This comment has been minimized.

Copy link

commented Jun 16, 2018

Can we automate wildcard certification ?

@mnordhoff

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2018

@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.

@ufo911

This comment has been minimized.

Copy link

commented Jun 18, 2018

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

@ArchangeGabriel

This comment has been minimized.

Copy link

commented Jun 20, 2018

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

@francoism90

This comment has been minimized.

Copy link

commented Jun 21, 2018

@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

This comment has been minimized.

Copy link

commented Jun 21, 2018

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

This comment has been minimized.

Copy link

commented Jun 21, 2018

@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

This comment has been minimized.

Copy link

commented Jun 21, 2018

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

This comment has been minimized.

Copy link

commented Jun 21, 2018

@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

This comment has been minimized.

Copy link

commented Jun 21, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.