Most of the time in incredibly regulated sectors, most of the products you see are huge, proprietary, and generally crap. It's such a rare treat to see a nice, simple thing that works in such a bureaucratic environment.
It really shows that Let's Encrypt are completely driven by wanting this thing to exist and be amazing, since they will slog through all the baseline requirements to get there. Most other open source initiatives fail when they reach the compliance stage because the work just becomes completely not fun.
Kudos to all the people at Let's Encrypt, and I wish y'all a very happy new year!
With that said I have huge amounts of respect for all the people (e.g. at Mozilla) who makes the CA system work.
The only thing that worries me about LE is that it's almost too easy. What happens when 90+% of the Web is running certificates from the same issuer? Are there any plans to run alternate free ACME CAs to prevent Let's Encrypt from becoming a single point of failure?
Not that I've given it deep thought, but do you think their core strategy would fundamentally make it easier for a second wave if it ever came to that? Compared to traditional CAs Let's Encrypt is all about automation and rapid expiration, and they've not only built significant open source tools to that effect but also gotten the community used to operating that way. At least at a high level it seems like they had a steeper hill to climb just in terms of being quite different from before, but now that the standards have improved and practices are in place it'd be a lot easier for everyone to simply point at new ACME CAs if LE ever went down, and old certificates would then cycle out rapidly and automatically. Obviously actually establishing a good new CA that would be trusted wouldn't be trivial itself, but it's also more abstracted from the end user then before. And there are major entities that could step up in an emergency.
I may be missing something here, but at least my feeling has been that LE is not merely providing a good service for now, but permanently improving the entire ecosystem in a lasting way and that if root forbid a meteor hit them or something it'd still be possible to recover better then before.
ISRG was created in 2013 to be the legal entity behind the Let's Encrypt service. It's not being "spun out," we just never had a website for the legal entity itself until recently.
This is an interesting question. Let’s Encrypt is built on openness and open source software, so it’s possible to ”clone” their service. However, it would require some funds to do so. (According to the article, they now operate on $3.6M/year.) So I can’t see that happening soon, not as long as Let’s Encrypt run their service in a trustworthy manner. But perhaps some entity would spin up a niched version. E.g. if a country would launch it’s own LE service for their citizens and domestic companies and organizations.
[Edited again regarding funds required.]
It looks like a bad thing, but the TLS CAs are organized in such a way that any rogue issuer can compromise any certificate. This way, consolidation only reduces the risks.
That is incredible!
At a 4% withdrawal rate, Let's Encrypt would need $100 million invested to not need to ask for funds in the future (assuming they don't drastically increase their operating expenses).
Governance and oversight is mandatory though; Wikipedia has net assets almost near $113 million  and requires less than 600 servers to operate (plus colo costs, connectivity, technical staff, etc). On the other end of the spectrum, OpenStreetMap costs $118k a year to operate .
There's a strong argument that entities like Wikipedia having to constantly go back to the community trough to survive, assists in keeping them well behaved. I prefer to keep Wikipedia begging and slightly desperate, rather than obese, detached, entitled, crusty and overly bureaucratic.
The user community that funds them can kill them off through funding deprivation in a short amount of time if Wikipedia decided to become a scumbag. Their annual cost to operate has perpetually increased, it's closing in on $100 million now (three or four more fiscal years at the rate they've been increasing it). They wouldn't survive long without the donations flowing in every year. They could plausibly make a large deal with eg Google on advertising if the user funding dried up due to bad behavior, however that would just be more likely to accelerate their implosion.
It's dangerous to the mission of a charity / non-profit to hand it a position of certain financial perpetuity. All organizations are very much susceptible to bureaucratic creep and wandering off mission in such situations. It's why many of the great philanthropists (Buffett, Gates and Carnegie to name a few) have sought to expend their fortunes relatively rapidly in charity rather than have the charitable trove exist in perpetuity via a perma-institution for parasites to attach to over many decades.
A benefit to Wikipedia’s situation is they go directly to their user base for funds. When nonprofits are financially precarious or dependent and rely on small numbers of moneyed donors, they can just as easily go off mission and/or become corrupted.
What you're describing is exactly the situation that Mozilla has been in for the last decade or so, and I always feel a little uncomfortable about it. The vast majority of their income is from search deals with one or two vendors.
Perhaps nothing can preserve institutions from ossifying than date-determined termination.
That's one (of several) reasons WoSign / StartCom was distrusted, they tried very hard to conceal the change in ownership of StartCom.
Assent might well be given, but it isn't automatic. This came up for Symantec selling their CA business, and also for other CA outfits doing internal reorganisations which wanted to be clear that these were paper exercises (e.g. for branding) and had no effect on which people controlled the CA in practice.
On a Google Android device, such as a Pixel, Google are responsible for the OS trust store, as they build the entire OS, but in practice it's basically the Mozilla trust store.
To the extent that we can say "Everybody else will have to go along" with anything when it comes to the trust roots, I'd suggest it's whatever Mozilla, a public charity, chooses to do. A brutally frank person might suggest that for-profit trust stores (all the big ones except Mozilla are for-profits) see considerable value in having unwelcome but necessary decisions made officially by somebody else before they "reluctantly" go along with them.
Also, Google is a very big company, the people who work on Google's Certificate Authority, the people who work on Chrome, and the people who co-operate with Mozilla are three separate groups at Google.
This is really exciting. The CloudFlare BGP hijack and subsequent attack of myetherwallet.com could have been much more successful if they had also been able to get a valid certificate. Having this multi perspective feature would make it even harder to get a valid cert during a BGP hack. Of course those falsely attained certs would still be logged publicly in a certificate transparency log- but better the cert never gets created to start with.
> We had planned to add ECDSA root and intermediate certificates in 2018 but other priorities ultimately took precedence.
I was particularly looking forward to ECDSA. Not for any real reasons other then I want to try it out. I currently have their 4096 bit RSA cert on a raspberry pi and the SSL negotiation is particularly slow according to Newrelic. Im curious to see how EDSA performs on a raspberry pi.
I'd also be more exited about getting EdDSA leaf certificates than ECDSA.
Note however that you can go to EC today. Your device doesn't care about the CA keys, so those still being 4096 bit RSA makes no major difference to you.
Your device does care about the CA keys, because it has to validate the certificate chain. But the Let's Encrypt CA uses a 2048-bit RSA key, regardless of the size of the key you're using.
For a server the certificates are just a pile of bits to be transmitted. Server software could be introspective but in general it isn't, e.g. it doesn't do AIA chasing.
But you're correct that I had misremembered the root as being 4096 bit and it's actually 2048.
See https://github.com/certbot/certbot/issues/2080 for some long debate and my most recent thinking about this. (I predict some discussion about this at Real World Cryptography in January, if only because I'm likely to ask some real cryptographers for their opinions there.)
I’m glad to see that they’re prioritizing this. Not a giant leap but still an important step for ensuring the stability of the CT system and the trustworthiness of the CA system.
However, I really think that they need some (free) competition --- their market domination is becoming a little extreme. Someone else offering free certs via the ACME protocol would be nice
The way that I learned about this is that acme.sh (the awesome ACME client by Neil Pang) announced support for BuyPass alongside Let's Encrypt:
Obviously this is really great in every respect, including a potential opportunity for finding compatibility bugs with ACME implementations.
So perhaps what you were hoping for has already happened!
(Edit: also, thanks for your support for Let's Encrypt!)
(Further edit: apparently the BuyPass ACME certs are valid for 180 days, as against Let's Encrypt's 90 days, but only let you list approximately one domain per cert, as against Let's Encrypt's 100 domains per cert. https://community.letsencrypt.org/t/acme-sh-supports-tls-alp... It's still awesome to see more options for ACME support and definitely makes it more credible that it wouldn't be as serious a problem if Let's Encrypt went away some day for some reason.)
If anyone from LetsEncrypt is reading, I just want to say thanks. Your tools have enabled me to quickly and easily set up encryption for several domains and sub domains.
And your documentation is great. Being able to select an operating system then a server and receiving crystal clear instructions on how to proceed is fantastic for a non devops guy like me.
Moving forward easily and painlessly will absolutely never be underappreciated on my end. Thank you!
* Code signing, particularly driver signing on Windows (thanks for making this very difficult for open source, Microsoft)
* Script signing, a-la Powershell AllSigned mode (even though it's caused me pain in the past and needs better IDE support)
- Embedded SCTs, so you don't have to worry about certificate transparency.
- Must-stable flag support.
- ECDSA leaf certificates.
Digicert is doing an excellent job too, although expensive, trying to push the tech forward with new flags such as signed HTTP exchange, but LE is not only free, but they are _better_ in many ways.
(That post doesn't track support on VPS plans because if you have root, you can run Certbot, Caddy, acme.sh, or other options to get the certificates yourself.)
I wonder how many other CAs do this as well? The third sentence suggests few.
I have heard we would not be the first CA to do multi-perspective validation, but as far as I know we would be the only CA of significant size doing it. I do not know of other CAs doing it today, but we have not done an exhaustive survey.
Also, architecture and implementation details matter for this kind of feature. How many perspectives, what networks... We are lucky to be working with a great group from Princeton that has been helping us design our implementation.
Can't easily do this and prevent squatting without onerous identity requirements.
This one caught me by surprise earlier in the year. When I was building some new infrastructure to support HTTP-01 validations in a multi-region deployment (routed using least-latency), one day I suddenly started seeing what looked like multiple validation requests hitting my EU deployment. Had me very confused for a few minutes, first thinking my logging infrastructure was suddenly very broken, or I had somehow configured my load balancers to cross regions, except the requests were coming from many different public addresses.
After some more minutes of digging and I found out about multi-perspective validation on the staging environment.
Anyway, good idea. And it seems to work from what I've seen. It seems just a surprise when it turned on while I was literally working on code/infrastructure to handle validations.
And all that for free!
If you are a regular user, please consider donating to the cause: https://letsencrypt.org/donate/ You can make a one-time donation or set up a recurring one.