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.
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.
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?
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.
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.
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.
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.
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.
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.
> 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
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).
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.
Take a look at https://github.com/AnalogJ/lexicon. It's a python library that provides standardized, programmatic access to DNS entries for a bunch of major providers.
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.
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).
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.
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.
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.
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.
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.
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
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.)
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,
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 ? )
[+] [-] kyledrake|8 years ago|reply
> 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
[+] [-] dspillett|8 years ago|reply
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
[+] [-] Siecje|8 years ago|reply
[+] [-] rkistner|8 years ago|reply
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-...
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] wereHamster|8 years ago|reply
[+] [-] Jaruzel|8 years ago|reply
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
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
[+] [-] fulafel|8 years ago|reply
[+] [-] massaman_yams|8 years ago|reply
1. Use acme.sh: https://github.com/Neilpang/acme.sh
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
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 --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.
[+] [-] hardwaresofton|8 years ago|reply
https://letsencrypt.org/donate
Also the EFF:
https://supporters.eff.org/donate
[+] [-] diafygi|8 years ago|reply
[+] [-] neals|8 years ago|reply
[+] [-] shawabawa3|8 years ago|reply
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
This is great news!
[+] [-] b3lvedere|8 years ago|reply
[+] [-] eric_b|8 years ago|reply
[+] [-] 0x0|8 years ago|reply
[+] [-] blattimwind|8 years ago|reply
[+] [-] elahd|8 years ago|reply
[+] [-] JorgeGT|8 years ago|reply
[+] [-] mholt|8 years ago|reply
[+] [-] nodesocket|8 years ago|reply
[+] [-] stevekemp|8 years ago|reply
https://dns-api.com/
[+] [-] blibble|8 years ago|reply
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
[+] [-] snowwolf|8 years ago|reply
And Heroku already supports wildcard certs (that you need to provide yourself) if you use the SSL addon.
[+] [-] mbaha|8 years ago|reply
[+] [-] urda|8 years ago|reply
[+] [-] rospaya|8 years ago|reply
[+] [-] ocdtrekkie|8 years ago|reply
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
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
[+] [-] kccqzy|8 years ago|reply
[+] [-] Santosh83|8 years ago|reply
[+] [-] sheraz|8 years ago|reply
[+] [-] anubhavmishra|8 years ago|reply
[+] [-] mbonzo|8 years ago|reply
[+] [-] inetknght|8 years ago|reply
[+] [-] thinkloop|8 years ago|reply
[+] [-] gator-io|8 years ago|reply
[+] [-] NKCSS|8 years ago|reply
[+] [-] komuW|8 years ago|reply
1. https://github.com/komuw/sewer
[+] [-] Manozco|8 years ago|reply
[+] [-] brightball|8 years ago|reply
Like *.subdomain.example.org?