It sounds like everything is running fantastically for them, and I'm really glad.
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).
I agree with the eggs/basket argument, though I suppose there's an argument to be made about a number of CAs being essentially too big to fail already, so what's one more?
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.
I think it would be nice to move toward having a lot of medium-sized nonprofit CAs instead of a handful of crappy commercial ones, which is the current situation.
"Too big to fail" is the problem with the current CA system, and today's well-run TBTFCA is tomorrow's global security crisis.
OMG yes on wildcard certs! My company has multiple domains and uses subdomains for every affiliate and we have thousands of affiliates. One *.example.com cert per domain and we're good to go. Now if only we could get IIS to support multi-domain wildcard certs so we could get all of our domains and subdomains under one master cert I'd be in heaven! (SNI doesn't work for us b/c ~12% of our traffic still uses IE7 or earlier).
So why not buy one now? I get the excitement about simple certification process, free access and refresh, etc. But if you have thousands of affiliates, current wildcard cert providers should offer a pretty good solution. Is anything missing there? I mean, if we ignore the idea why LE is good in general, $100 / year is nothing if you actually need a wildcard.
Oh we absolutely do just buy them now through RapidSSL. It's all of those other reasons I wish LE supported them. I wouldn't mind paying LE for them, I want an API for requesting them, a simpler certification process, and easier refreshes.
I don't get the desire for longer-life certs. I would argue that they should be shorter to keep the exposure of a leaked cert down. Whether a cert is good for a week or a year you should be automating the renewal.
Same as EFF/Mozilla. Let's Encrypt hasn't fulfilled their goal until everyone can get free HTTP encryption.
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.
This sounds more like a design decision by that blogging platform rather than something that's caused by Let's Encrypt. Excluding maintenance windows or any other unplanned downtime or performance issues (which happen relatively rarely), the issuance process doesn't take anywhere near close to 24 hours. Account registration, domain validation and certificate issuance is typically done in less than ten seconds.
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).
Edit: The document you linked to was recently updated, but the top of the page incorrectly says "Last updated: August 10, 2016". I wrote my response with the old document in mind. It's obvious to me now that this page was actually last updated in December 2016.
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.
I assume by "multiple SANs", you're referring to subdomains under the same registered domain? In that case, you can use the rate limit adjustment form or register your domain as a public suffix if that's more appropriate. The form has been available since August. The rate limits in general have not changed since back then (or even before, I don't recall) either.
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).
> But I'm not necessarily thinking of a standalone "free certificate company" but maybe more of a "bonus" to some other product or service.
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).
Yeah, and I'm also hoping they will gravitate toward more "standard" interfaces like you touched on at the end there.
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.
I think it's fairly likely we'll see a number of CAs adding ACME support at some point. Judging by participation on the ACME mailing list, there seems to be interest from (at the very least) DigiCert, Entrust and cough StartSSL. I guess most of them will want to wait for the standardization process to finish before announcing any plans.
> LE has saved us from spending many man hours of time updating certificates
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?
> Just out of interest, how are you managing the 90-day renewal schedule?
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.
No, we tend to keep our staging and dev servers public-facing for the most part. We do a lot of remote work, and it's easier that way.
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.
Presumably, you would want to have monitoring in place for certificate expiration either way, so this expense is not really specific to short-lived certificates.
That's what StartCom might thought when they announced their new service "Start Encrypt" around the same time when Comodo tried to get hold of the "Let's Encrypt" trademark which Let's Encrypt successfully fought back.[0] Then some more deserved buckets of shit hit their fan. I can't bring myself to call StartCom a competitor of Let's Encrypt.
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?