Let’s Encrypt 2016 in Review
letsencrypt.org
letsencrypt.org
From my own use case, integrating TLS for my site via LE and the autocert package in Go has been seamless. It's completely free (if you want it to be), and it looks like I won't have to worry about renewing certs anymore. The service LE is providing is amazing. Just thinking of the millions of dollars they're collectively saving everyone, yearly, is pretty crazy.
If anyone at LE reads this, thank you for your work!
It is a small token of how much time they saved us from setting up ssl for our clients. These small monthly donations can add up help them thrive in the future.
What's crazy to me is that their crowdfunding campaign [1] has only raised $100K so far, considering what they're doing.
1: https://www.generosity.com/community-fundraising/make-a-more...
LE has saved us from spending many man hours of time updating certificates across all dev, staging, and live machines across all of our servers every year (which just so happens to be almost exactly the amount of time needed to forget some of the details of what needs to be done...).
But all that being said, when are we going to see a competitor pop up? Clearly what they are doing is working, so when are we gonna see some others attempt to do this? Having all your eggs in one basket is never a good thing in any part of life (no matter how perfect that basket is).
Having more than one "Let' Encrypt" would at the very least spread out some of the risk, and might even enable them to specialize a bit more (perhaps the competitor could target the issue of wildcard certs, or be somehow tailored for the use case of needing thousands of subdomains).
Has there been anyone else trying this?
1) Let's Encrypt are based in the United States and are already forbidden from issuing domains to certain people[0] due to US law.
2) Having a separate production implementation of an ACME-compliant system would help make sure that the protocol is as robust as it can be
[0] Notably Iran and Syria - several certificates issued for gov.[ir|sy] had to be revoked after they slipped past their blocklist: https://community.letsencrypt.org/t/blocklist-incident-novem...
https://crt.sh/?Identity=%25.sy&iCAID=16418 https://crt.sh/?Identity=%25.cu&iCAID=16418 https://crt.sh/?Identity=%25.sd&iCAID=16418 https://crt.sh/?Identity=%25.ir&iCAID=16418
What would be the motivation for a competitor?
I don't think 'competitor' is the right word here -- maybe 'second basket so all our eggs aren't in one'.
Regarding client certificates: There aren't really many good reasons to use publicly-trusted certificates for client authentication, but if you insist, you can use Let's Encrypt for that. The certificates do have the id-kp-ClientAuth EKU.
"Too big to fail" is the problem with the current CA system, and today's well-run TBTFCA is tomorrow's global security crisis.
As a user, if I have to wait 24 hours (or more, depending on queue depth) for a Let's Encrypt batch queue to be processed after I sign up for some free blogging platform before I can use an assigned subdomain, then I'm probably going to close my tab and never come back. Let's Encrypt hasn't fulfilled its goal until this doesn't happen any more. This batch queuing model is necessary so that sites don't exceed the Let's Encrypt daily quota.
Some applications rely on wildcard subdomains, and require a wildcard certificate to be instantly responsive.
To anyone thinking "just don't use encryption until after the cert has been provisioned"—not going to work if you use HSTS. Your users have to wait all day before they can use their subdomain.
The existing rate limits[1] should have very little effect even for very large integrators. A form for rate limit adjustments exists for those who need a large number of subdomains (and would rather not obtain a wildcard certificate) or need to add new domains at a very high rate (i.e. the WordPress.com's and OVH's of this world).
If I don't batch multiple SANs into one certificate and stagger a certificate queue, I will very quickly run into the Let's Encrypt rate limit.
If I don't want my users to wait for the queue to be processed, I could immediately request a new certificate for every new user's subdomain, but then I'd be limited to 10 new users every 3 hours.
Obviously LE employs a handful of people, and they are in some ways an "advertisement" for Mozilla (not that it's a bad thing). Those alone are some reasons why something might want to be attempted.
But I'm not necessarily thinking of a standalone "free certificate company" but maybe more of a "bonus" to some other product or service.
Think something like a domain host providing certificates themselves (which IMO makes a hell of a lot of sense).
This is what I expect we'll see more of, rather than a second (and perhaps slightly different) Let's Encrypt. Major cloud providers will probably add their own variants of what Amazon offers with AWS Certificate Manager (ACM); more CDNs will start offering one-click SSL (like Cloudflare); "traditional" web hosting providers and control panel vendors will (hopefully) support SSL by default (like cPanel with AutoSSL, which supports Comodo and Let's Encrypt).
With the help of Let's Encrypt and through some cooperation, we could make easily "pluggable" SSL cert providers where you can choose who you want with the click of a button.
Just out of interest, how are you managing the 90-day renewal schedule? Don't you need some means of verifying that timely renewal has occurred.
Since you mention dev and staging I assume you've implemented a central certificate-management server that talks with LE and then issues the certs to the internal machines?
Also include command like below as part of your automated audit scripts:
echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -dates
http://www.shellhacks.com/en/HowTo-Check-SSL-Certificate-Exp...
openssl s_client -connect google.com:443 </dev/null 2>&1 | openssl x509 -noout -enddate
Not the parent, but I use certbot running monthly with a cron job. It skips any domains that aren't up for renewal, and renews domains when they are close to expiry.
I then get a monthly email telling me which domains were updated and which ones were skipped.
It's completely painless. 90-day renewal isn't a problem when the whole process is completely automated.
If it runs monthly, and one of your renewals fails (i.e. transient network error), your certificate may expire before it next gets the opportunity to renew it.
I don't run enough sites that this is a problem.
Everything is kept behind our application authentication, and they almost never have "real data" on them so it's not really an issue for us. And having the certs on the dev machines just makes setting up and testing with HTTPS that much easier and it's a no-brainer with LE (plus it lets us ensure that everything there is working correctly, and gives us fully authenticated HTTPS connections with our dev servers!)
In the rare event that we need a dev server and can't put it behind our application auth, it's generally locked to localhost and we use SSH forwarding until it can be.
As for managing the lifetimes, we just use certbot the same as we do for the production machines, similar to the way the other commenter pointed out. And I believe one of our guys has some alerts setup for monitoring the expiration of the certs and warning if it gets too close to expiring, but I don't really know anything about how that works.
The next step I'd like to see is all the $5 shared hosts supporting HTTPS by default via something like Let's Encrypt. There's really no excuse anymore.
BTW, shameless plug: We've found this process so easy that we've spun a side project out of our main SaaS project called clearalias.com. It's basically a Let's Encrypt proxy that makes it even easier to publish customer content via custom domains secured with HTTPS.
Excellent point. I can see Lets Encrypt turn into one of those crucial infrastructure providers (similar to square/stripe/paypal for payments) but for https
I should probably update things.
Why do all the other CAs cost so much and take so long when the actual cert is generated in seconds?
Isn't that how it's supposed to work and LE is breaking the rules, thus living on borrowed time?
If it was possible to be so easy why no else did it? What is the secret ingredient?
AFAIK the cost of previous SSL certs have been largely artificial. Obviously running servers and paying staff to keep an automated process in place isn't free, but I recon the cost has always been inflated quite a bit. There's also an artificial scarcity introduced because not everyone can start a CA and getting a root certificated trusted is non trivial. Let's Encrypt is sponsored so they do make some money, but this allows them to issue certs for free.
0: https://en.wikipedia.org/wiki/Extended_Validation_Certificat...
I guess "so much" should be put in perspective: Domain Validation certificates, like the ones Let's Encrypt issue, are not really expensive - resellers typically offer them for something like $10/year. The more expensive certificates - OV and EV - involve some degree of manual verification of the information on the certificate (such as the company name). That's a large part of the cost.
But yeah, commercial CAs are (were?) money printing machines. Running Let's Encrypt costs about $3M/year, and they support >20M active certificates. Commercial CAs are going to have some marketing and support expenses, but the rest would be profit.
> Isn't that how it's supposed to work and LE is breaking the rules, thus living on borrowed time?
All CAs (should) follow the same set of rules - the Baseline Requirements. Let's Encrypt has had a pretty good track record so far - definitely better than some of the big commercial CAs like Symantec or Comodo.
> If it was possible to be so easy why no else did it? What is the secret ingredient?
To be fair, they were not the first free CA - both StartSSL and WoSign offered free DV certificates (for non-commercial usage). Not the best examples, I suppose.
Cloudflare offered free SSL (via Comodo) for their customers as well, as does cPanel via AutoSSL It's definitely viable, just took some time for people to care enough about encrypting the web to make it happen.
Which is how we got Canonical/Ubuntu (and how Shuttleworth could afford to be a space tourist):
Because some agencies have the monopole to print them and they've made it very difficult for anyone else to get into that printing business and it turns out that that product is valuable to a lot of people and they're willing to assign a lot of money to it.
From their support:
"Though we believe increased web security is a good thing, we also think that using certificates from free providers can get more risk and uncertainty into your business. Additionally, we would like to draw your attention to several disadvantages and drawbacks of Let's Encrypt certificates:
1. No OV/EV support or possibility (no possibility to issue a certificate with medium or high assurance and user trust level);
2. Insufficient level of domain validation and the absence of brand validation ( All publicly trusted CAs are flagging the certificate containing IT, financial and other public words, brands etc for additional security checks, which is not applicable for LE.)
3. Short validity period (for LE certificates - only 90 days, for all trusted certificate provides - up to 39 months).
Since the nature of shared and reseller hosting implies having a significant number of independent customers' accounts on the same server instance, we cannot put at risk our other clients by enabling not fully secure technology.
These and other concerns (for example the fact that ACME-script for Let's Encrypt requires root access and is able to overwrite server configs) make us refrain from supporting Let's Encrypt on our shared servers. We hope for your kind understanding on the matter."
----------
Feel free to reply with other hosts that don't support LE, so I can avoid them (and hopefully others too!)
This is one of the problems I've had with LE, and the community defends it by saying that there are other tools, and forks of tools you can use, when the problem with those is that they could easily go out of date if LE changes anything and they'd never be fixed. Updating your certificates needs to be done in a reliable and contained manner, but nobody wanted to admit that LE tools doesn't do that.
I don't recommend LE unless you're actively maintaining a server and can invest the time into creating your own contained update script. I know hosters like Dreamhost have it built in and will auto-update for you, which is nice.
There are unpaid supporters for three-letter agencies who have made moves to ban encryption. With LE anyone can obtain a certificate and set up an in-memory ephemeral message board that uses "unbreakable encryption." I don't know of any people who would be able to explain how to implement cryptography actually taking this stance.
There are apologists for the rent-seeking behaviour of academic journals, usually ill-informed (wrongly assuming that editing and peer review are not volunteer positions) and repeating arguments verbatim from those on the payroll that happen to resonate with whatever political line they follow. Still, they themselves are not on the payroll.
I can imagine, given sufficient technical knowledge or an article aimed a mass audience, certain pro-market contrarians could definitely find reason to hate this. Maybe even twice.
If you're genuinely pro-market, you should have no problem with an industry that pools funds to mitigate rent-seeking behaviours of an oligopoly, reduce the cost of a product for which there is no substitute and increase utilisation of other resources.
Which is it?
Are there any plans or water-cooler discussions around supporting wildcard or multi-sub-domain SAN wildcard certs?
W3Techs[1] is generally a good source for this kind of information. Themeforest seems to be using them, for example. (Certificates issued by Let's Encrypt are counted under the IdenTrust root on W3Tech, since that's the CA that cross-signed Let's Encrypt.) Generally speaking, they get used on low-traffic sites (compared to the other major CAs), but that's not really surprising.
[1]: https://w3techs.com/technologies/details/sc-identrust/all/al...