top | item 16577714

ACME v2 and Wildcard Certificate Support is Live

1024 points| schoen | 8 years ago |community.letsencrypt.org

310 comments

order
[+] kyledrake|8 years ago|reply
First, congrats, this is great news! There's a lot of use cases out there that require a wildcard cert or work far better with them.

> It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.

Please don't do this. It will break millions of sites needlessly. Most installations of lets encrypt plugins aren't going to auto update to v2. A lot of us are also using custom v1 code for various reasons that may not be easy to change.

The preferable end-of-life date for ACMEv1 (sparing any existential security issues) should be never. Otherwise you will be executing a Geocities-sized web meltdown every time you phase out a version of the API.

[+] jaas|8 years ago|reply
The reason we haven't announced an EOL for ACMEv1 is that we won't announce one until we are confident we won't cause the kind of meltdown you describe.
[+] dspillett|8 years ago|reply
If the EoL is far enough after the release of V2 then I think it is preferable that people start getting security warnings for sites that stop working: it is an indication that they are no longer maintained so potentially not receiving security updates for other matters.

Obviously a decent length of grace period would be the correct way of deprecating the older version, to give people time to update their infrastructure accordingly. I would suggest at least a full year (giving at least four renewal cycles to test changes in a QA environment before being forced to update production), probably more. Perhaps, if possible, a year for new certificates and two years for renewals?

[+] belorn|8 years ago|reply
Since the certificate need to be updated every three months they have access to exact number of how many people use ACMEv1. They also have as naturally part of the process the domain names of those users. This should allow them to very slowly watch as the number of v1 users drops until there is so few that they can try contact any remaining users before deciding to set an end-of-life to that version.
[+] Siecje|8 years ago|reply
When you run the Let's Encrypt official client (certbot), it updates itself.
[+] rkistner|8 years ago|reply
They already disabled TLS-SNI-01 for new certificates because of security issues [1].

This was a major breaking change, without any advance notice, but nothing melted down.

I'm sure the other validation endpoints are used a lot more, but the effect shouldn't be any different, especially if give a deprecation notice of a year or two.

[1]: https://community.letsencrypt.org/t/important-what-you-need-...

[+] wereHamster|8 years ago|reply
Depends only on how much different v2 is from v1.
[+] Jaruzel|8 years ago|reply
One of the wonderful aspects of this, that no-ones pointed out yet, is that these can used for INTERNAL domains, without you having to run your own internal CA.

i.e. lets say your internal network DNS domain is 'my-company-lan.com' - all you have to do is ensure that 'my-company-lan.com' is also registered in public DNS[1], and then you can secure ALL your internal services using a free LE wildcard cert, that's automatically trusted by all platforms and browsers[2]. For some companies that's going to be a BIG cost and resources saving.

--

[1] but not actually used for any public facing services.

[2] Mostly...

[+] Jaruzel|8 years ago|reply
Going to reply to my own comment here.

It's at this point that I swear profusely at Microsoft yet again, for pushing the concept of '.local' domain suffixes a decade ago. As it's not a legal TLD, I can't get certs for any of my internal services without rolling my own internal CA, which only works automatically for Windows domain machines, and not for anything else.

[+] Shoothe|8 years ago|reply
Just remember that the cert will be logged (Certificate Transparency) so any names there will be disclosed to the public. Wildcards help a little here though.
[+] fulafel|8 years ago|reply
You could do this before too, without wildcards.
[+] massaman_yams|8 years ago|reply
For anyone wondering how to actually obtain a wildcard cert this way, here's the quick version:

1. Use acme.sh: https://github.com/Neilpang/acme.sh

  acme.sh --issue -d *.example.com --dns
If your DNS provider has a supported api, you may be able to automatically publish the DNS records required using a slightly different command - see here: https://github.com/Neilpang/acme.sh/tree/master/dnsapi
[+] b3lvedere|8 years ago|reply
Thanks! This looks awesome. Can i automate it as well?

I have been toying a little with wildcard using certbot on my Ubuntu OpenVPN appliance, but was a bit unsuccessful at the moment.

Maybe i should just try and build a very tiny virtual sever that does nothing but spit out a wildcard domain certificate to some predefined destinations to have it used in anything that wants a certificate. Could be beneficial to a (large) infrastructure to have an always-ready certificate to use for free. Dunno if EV validation will uphold though.

[+] kureikain|8 years ago|reply
acme.sh is great because it support manual DNS mode. It also way easier to use compare with other similar client. This is all it takes for me.

./acme.sh --issue -d noty.im -d '.noty.im' --dns

It then told me to add TXT record, which I just manually do because I used RackSpace cloudns which has no built-in support.

I manually verify DNS with dig, when it's ready I just do:

./acme.sh --renew -d noty.im -d '.noty.im'

then the cert(private key and full chain) are stored in ~/.acme/noty.im/

These privateky and fullchain can be used directly with nginx without any modification.

[+] neals|8 years ago|reply
The amount of money I've paid for this... I recon some of these providers are going under soon?
[+] shawabawa3|8 years ago|reply
> I recon some of these providers are going under soon?

I really hope so.

The cost to providers is exactly the same for a wildcard and a standard certificate, and yet they costs hundreds of dollars. It's unbelievable it's lasted this long

[+] nkkollaw|8 years ago|reply
If it was up to me, even right now.

This is great news!

[+] b3lvedere|8 years ago|reply
I don't know. Will Letsencrypt also replace EV certificates?
[+] eric_b|8 years ago|reply
I'll happily pay money to get a cert that expires in 3 years instead of 90 days. Some of us don't feel like faffing about with cert renewal every quarter. (I know there are tools and clients that can "make it seamless" - until the ACME endpoints are down or something).
[+] 0x0|8 years ago|reply
DNS providers and domain name registration companies are probably going to get pestered about API access for updating TXT DNS records now... :)
[+] blattimwind|8 years ago|reply
I never understood why DNS providers are so reluctant to offer standards-based access, like nsupdate(1). It's easy to set up, it can do everything, it's secure, requires no custom anything and it just works.
[+] JorgeGT|8 years ago|reply
I started using Cloudflare just for their DNS API - the dynDNS providers baked into my router's firmware went under so I started pointing the DNS record to my home dynamic IP with a cronjob that called CF's API.
[+] nodesocket|8 years ago|reply
Use Terraform to manage records. They have support for lots of DNS providers (AWS Route53, Google Cloud DNS, Cloudflare, DigitalOcean, Azure DNS, DYN, DNSMadeEasy, NS1, UltraDNS, PowerDNS).
[+] stevekemp|8 years ago|reply
Store your DNS records under revision control, and updating your records can be as simple as a "git commit && git push".

https://dns-api.com/

[+] blibble|8 years ago|reply
is it common for DNS hosts to provide delegated access at the granularity of individual records?

I don't want my webserver to have the ability to change my entire zonefile just so it can authorise certificates!

[+] jack_jennings|8 years ago|reply
Now here's to hoping that Heroku supports this soon. That will to mean I can a last migrate a number of apps that require wildcard domains to their platform.
[+] snowwolf|8 years ago|reply
I'm intrigued. What kind of app that you could host on heroku requires wildcard certificates? Bearing in mind that heroku can't really support wildcard subdomains for a single app. Each custom subdomain for an app needs to be added to the app. And then if you enable Automated Certificate Management for the app (which uses LetsEncrypt under the covers), they'll happily fetch a cert for each listed subdomain.

And Heroku already supports wildcard certs (that you need to provide yourself) if you use the SSL addon.

[+] mbaha|8 years ago|reply
I have a feeling they've been working on this. Their https support has always been top notch!
[+] urda|8 years ago|reply
This is great news! Let's Encrypt has helped me secure many of my own boxes without having to maintain my own CA, very happy to see them grow.
[+] rospaya|8 years ago|reply
Can anyone list any negatives of Let's Encrypt? I've been using it since the start and just can't find any practical downsides.
[+] ocdtrekkie|8 years ago|reply
The only significant concern I have is that if LE were to essentially "take over" the CA industry, you know, due to being free, and awesome, we'd have a massive single point of failure for the entire Internet's security model.

My biggest peeve with the whole "HTTPS Everywhere" push is not the general notion of using encryption, but that the encryption is annoyingly coupled with the CA system, which is terrible for many reasons.

[+] ryandrake|8 years ago|reply
The one that always sticks out is the certs’ extremely short expiration period. The IMHO weak rationale for this was mentioned in another thread here (See jjeaff‘s response upthread).

It would be nice if they simply offered two choices:

1. I love automation! Give me a 90 day certificate.

2. I understand the security trade-offs. Give me a 3 year certificate.

[+] elahd|8 years ago|reply
The service is great, but they're really the only free SSL cert game in town. As more sites start using their certs, they'll wind up becoming a single point of failure.
[+] kccqzy|8 years ago|reply
They won’t ever issue EV certs.
[+] Santosh83|8 years ago|reply
I do hope GitHub employs this for rolling out https for Pages sites using custom domains too.
[+] sheraz|8 years ago|reply
Great news, but interesting to see that they still recommend securing individual domain names. I imagine this is for security purposes?
[+] anubhavmishra|8 years ago|reply
Thank you letsencrypt team! Really appreciate all the hardwork to get this out.
[+] inetknght|8 years ago|reply
This whitepages unless you disable javascript or enable connections to discourse.org. How disappointing.
[+] thinkloop|8 years ago|reply
On the face of it wildcard certs seem easy to implement - just match anything in place of the * - but clearly that's not the case as it took years to complete, anyone mind sharing some of the subtle challenges and complexities involved
[+] NKCSS|8 years ago|reply
I just wished there was a Windows client that just works with IIS. Every time I try, it just errors out and gives me headaches (certify, Let's Encrypt Simple Windows Client, etc.)
[+] komuW|8 years ago|reply
Shameless plug, I created sewer[1], which is a letsencrypt client that you can use both as a (minimalistic) python library or as a command line application. And I just added ACME v2 support. Check it out,

1. https://github.com/komuw/sewer

[+] Manozco|8 years ago|reply
I did not see it on the forum, but seeing that the wildcard feature requires DNS-01 challenge for getting the certificates, does it mean automatic renewal is impossible without DNS api ? (or is it possible to renew without the dns challenge ? )
[+] brightball|8 years ago|reply
Can this be used for multi-level subdomains?

Like *.subdomain.example.org?