* The cover image is originally by OpenClipart-Vectors and edited with great appreciation.
Introduction
Let's Encrypt supports wildcard certificate via ACMEv2 using the DNS-01 challenge, which began on March 13, 2018.
Certbot, its client, provides --manual option to carry it out.
I sincerely appreciate them.
I write how I generated my wildcard certificate with Certbot.
It was a very simple task : )
All what was necessary in addition is to add a TXT record specified by Certbot to the DNS server.
* Caution: As it is necessary to update Let's Encrypt's certificate every 90 days, a new TXT record is required at every renewal.
Body
Environment
Tutorial
The command is like this:
# certbot certonly --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory --manual-public-ip-logging-ok -d '*.<your.domain>' -d <your.domain>
Make sure to quote *.<your.domain> to avoid the error "no matches found: *.<your.domain>".
* Note: the order of -d *.<your.domain> and -d <your.domain> didn't seem to matter.
Here is the comparison of certonly options with a single certificate:
- --webroot -w <dir-path>
+ --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory --manual-public-ip-logging-ok
Besides, the detail of its command line options is here.
Then, the command replies:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for <your.domain>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.<your.domain> with the following value:
<acme-challenge-value>
Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Configure the DNS server to add a record to your domain.
The record is like this:
| Where | What |
|---|---|
| Type | TXT |
| Name | _acme-challenge |
| Value | <acme-challenge-value> the command shows above |
* Note: You might wait here a little while for DNS propagation.
Then press Enter.
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/<your.domain>/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/<your.domain>/privkey.pem
Your cert will expire on 2019-08-01. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot 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
Done : )
Conclusion
Thus I got my wildcard certificate and applied to my several servers.
It works fine today and my workload has decreased with almost the same security.
If you are in search for how to apply Let's Encrypt's certificate to OpenBSD httpd server, I wrote here:
Thank you for your reading.
Happy securing.
Top comments (27)
Would recommend using it along with acme-dns to get auto renewals working. If you use
--manual, you'll have to manually renew the certificates every three months. You could use the API provider by your DNS provider (if supported by certbot or acme.sh), but it's not as secure as using acme-dns.Thank you so much, Daniel.
I've found the problem in my solution owing to your advice.
The manual renewal requires a new TXT record every three months:
community.letsencrypt.org/t/how-to...
Nice Go OSS 😆
I updated my post.
Thank you, again!
LetsEncrypt have revoked around 3 million certs last night due to a bug that they found. Are you impacted by this, Check out ?
DevTo
[+] dev.to/dineshrathee12/letsencrypt-...
GitHub
[+] github.com/dineshrathee12/Let-s-En...
LetsEncryptCommunity
[+] community.letsencrypt.org/t/letsen...
Just curious. What is your use case for needing a wildcard cert?
I have a white label app that uses a subdomain to distinguish different brands - "coke.app.com" "pepsi.app.com" etc. Needs a wildcard cert to secure them all so we can add new subdomains whenever we want and not get ssl errors.
Running different servers. Like www. domain and domain as web servers and jabber.domain and domain as jabber servers.
For instance.
You really shouldn't mix/combine the security of completely different services (thats what a certificate is - service identity) in a single certificate. The proper solution is to up the automation surrounding your service's build process to include the asynchronous process of obtaining a certificate for each service.
If you need multiple hostnames for the same certificate (AND KEYPAIR), you should be using SAN certificates, not wildcards.
If you need multiple endpoints with the same DNS hostname, you make that a common SAN across multiple certs for each individual TLS endpoint.
As a follow-up, IMO, the only valid use case for wild card certs is for self-contained private PKIs usedd internally with external certs for the exposed service endpoints. An example would be a private mini-CA dedicated (and trusted) only for inter-node internal connections within the cluster.
Dear MichaelKing1832
Thank you for your description and follow-up.
I'm so grateful to you 🙂
I'll learn and get experienced much more...
Hey MichaelKing1832,
Do you have a reference source link for your statement: "You really shouldn't mix/combine the security of completely different services (thats what a certificate is - service identity) in a single certificate."
In a blog post of mine I want to link to your comment here but, also link to an official document/RFC.
Thanks a lot - and thanks heddi.nabbisen for this post!
Sorry about the delay, @bcjasond .
It is a best practice. When you use the same certificate for different services, you directly couple their identity and the security assertions/claims of the certificate. i.e. what was certified by the CA in issuing the certificate, as described in the CA's Relying Party Agreement (or RPA).
In the example, as long as www and jabber are 1) on the same host infrastructure, and 2) have the same security context assured by the certificate, then you're ok. But the second they're jot identical, you can't separate them because they're bound together and you'll need new, separate certificates anyway.
So it's easier to manage them independently, so they can have different security policies and assurances appropriate to each service.
For example, the www service might need to have an EV certificate for e-commerce reasons, while the jabber service only needs a DV cert. Or they run in separate docker containers, so you would have to jave separate copies of the keypairs and certificate anyway, but because you've coupled them, any maintenance (e.g
cert replacement) on one MUST be performed on the other.
It doesn't scale and it doesn't leverage loose coupling when two unrelated systems inevitably diverge from each other, and it doesn't enable detection of a certificate issue when distinction between www and jabber services is required, because they are literally two names for the same identity. This is more critical when the example is an HA system and you want to know which host you are actually connecting to - you can't. e.g
www1 and www2 are SANS in the same cert.
In closing, its not something you would find in a standard, but in your security policy in support of best practices, including clear identity assignment and infrastructure implementation specifications.
Me too 😉
Thank you!
On my home server, I route a variety of different outward facing apps to different sub domains, it’s much easier for friends and family to remember app.domain.tld.
Marvelous.
I am going to use it as an example 😄
The main shortcoming of LetsEncrypt is that it's faster to renew my certificates than it is to write a CRON job to do it every three months, so years later I'm still doing them all manually
That seems more your shortcoming.
;) It isnt that hard to write such a cronjob, is it?
Certbot, the primary acme client, does this out of the box.
Not at all! But it's even less hard to not write one
Actually, I update manually now, too. Haha 😆
certbot renewis useful.Well, I'll add a simple cron job in the near future, although automatic renewal without any writing is also my ideal... 🙂
I would recommend using acme.sh script instead of certbot. Way less dependencies and way easier.
I wrote about it on my blog. (just search for plantroon blog if you're interested)
certbotis in the repository of most Linux distros... At least on Debian you can simplyapt install certbotso it's actually easier to install than acme.sh is :)Both are good options though!
Not true anymore, you are required to snapd install it.
I'm not sure about that... It's still in the Debian repos.
That's true. But acme.sh is just one script to download, you don't really have to install it. I keep it in ~/.local/bin or /usr/local/bin on my systems. You need to supply hook scripts though, but that is required for Certbot too.
Thank you, Jakub, for your good information.
I found that (perhaps):
github.com/Neilpang/acme.sh
I haven't ever known of it since you told me 😀
You can use docker. Docker and Wild card ssl
Thank you for your good information.
While I use OpenBSD servers and thus am unfamiliar with using docker, it seems to enable us almost anything ☺️