All of these issues with 3 month certs, rate limiting, and limited certs/domain stem from much more complicated problems and it isn't fair to expect Let's Encrypt to tackle those.
Setting up my 5 domains, hosted on one small (virtual) server instance was just a breeze. Esp. compared to my former experience with StartSSL.
And now, with a cronjob doing auto renewal everything is solved.
So for me at least Let's Encrypt just made life better.
It took me about 45 minutes from "never done this" to "all sites done with a cron job for auto-renewals".
The final thing I did once everything was set up was donate to the project.
The 3 month cert limit is an arbitrary limit by Let's Encrypt, and has nothing to do with a more complicated problem.
They could just as easily make it 6 months or a year, but instead they chose 3 months.
Broadly speaking Certificate Revocation is garbage. It doesn't work. So when a bad actor generates a bad certificate there's a legitimate chance that without Certificate Pinning, that Certificate will be accepted even if theoretically revoked. A three months max duration limits the potential liabilities to three months.
Additionally three months offers the better theoretical security against state actors. While a 2048 bit key is normally considered to take tens of years to break, it is possible a state actor with unlimited resources could construct a quantum computer that could cut that time down significantly. If the certificate pair is regenerated every three months using a safe cryptographic source this makes breaking it likely not worth while even for a quantum computer.
But what attack is that blunting?
1. A bad actor with access to the system will just regenerate another LE cert and carry on.
2. A bad actor who has injected a bad cert, but without system access, still has three months to conduct his fraud which is more than enough time to phish 90% of the user-base.
I'm not privy to the LE decision-making process but 90 days seems like the result of a bad compromise. Automated certs should be renewed on a very-high-frequency ( like hourly ) otherwise there's little benefit over the traditional model, and a lot of downsides such as breaking pinning.
90 days seems to have been chosen to be painful enough to push people into adopting auto-renewal but not frequent enough to overload LE's system, and thus not actually providing any security gains.
FYI: You can renew your cert without changing the key, e.g. for mail servers and DANE/TLSA.
http://www.internetsociety.org/deploy360/blog/2016/01/lets-e... (part 1)
If I'm unaware of these limits and use them up all at once, I'm locked out for a week instead of having to wait 1/rate to issue just one more.
Token bucket is a good idea, and I agree that it would make the user experience of hitting rate limits less onerous. We implemented sliding windows because they were straightforward to implement based on our long-term database state. I'll do some thinking about whether we can emulate a token bucket style on top of that without having to add another source of truth for rate limit information.
On the other hand, it shows, yet again, how dysfunctional the certificate industry is.
Even if you're not allowing it to directly mess with apache2 or nginx configuration files and want to run it in standalone mode. For example to get a certificate for my 'test' environment public facing smtpd:
sudo ./certbot-auto certonly -v --standalone --standalone-supported-challenges http-01 -d mail.mydomainname.us
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/mail.mydomainname.us/fullchain.pem. Your cert
will expire on 2016-08-17. To obtain a new version of the
certificate in the future, simply run Certbot again.
- If you lose your account credentials, you can recover through
e-mails sent to email@example.com.
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
Now we have three files, the certificate itself, the
certificate itself and the full chain, and the private key:
/etc/letsencrypt/live/mail.mydomainname.us# ls -alh
drwxr-xr-x 2 root root 4.0K May 19 14:36 .
drwx------ 3 root root 4.0K May 19 14:36 ..
lrwxrwxrwx 1 root root 42 May 19 14:36 cert.pem -> ../../archive/mail.mydomainname.us/cert1.pem
lrwxrwxrwx 1 root root 43 May 19 14:36 chain.pem -> ../../archive/mail.mydomainname.us/chain1.pem
lrwxrwxrwx 1 root root 47 May 19 14:36 fullchain.pem -> ../../archive/mail.mydomainname.us/fullchain1.pem
lrwxrwxrwx 1 root root 45 May 19 14:36 privkey.pem -> ../../archive/mail.mydomainname.us/privkey1.pem
(I wrote the original version of standalone in certbot, but I'm just trying to stand up for the people who complain that something is complicated in their use case.)
Almost hit the limit before I got it working
There are a lot of use cases this blocks - Plex's use case  where they issued certs for all their users; large organisations (I'm sure there are more than 20 sites run under .mit.edu sites by different teams who wouldn't want to share multi-name certificates); and of course using ISP-assigned hostnames like host86-186-141-3.range86-186.btcentralplus.com (admittedly there are other reasons LE might not want to issue certs for that final case).
Does anyone know the reason for that limit? It seems quite low considering they allow 500 certs per IP address and 300 pending authorizations at a time :)
> large organisations (I'm sure there are more than 20 sites run under .mit.edu sites by different teams who wouldn't want to share multi-name certificates);
This is why we've added a form to request rate limit overrides. If mit.edu wants a higher rate limit, all they have to do is ask. We're trying to strike a balance between offering a free service that works for most people, and running the risk of abuse.
Also, even if mit.edu doesn't apply for a rate limit, people can issue certificates for 20 new sites under mit.edu per week, or 1,040 new sites per year. And in fact you can see a number of such sites in the crt.sh logs: https://crt.sh/?q=%25.mit.edu&page=1 (note: loads slowly).
If I wanted to issue certs for a few hundred microservices running in a VPC, assuming I could get them to DNS validate, do you think I'd get approved for a rate limit exemption? Or are exemptions more of a well-you-have-to-have-a-really-good-reason thing?
For use-cases like Plex (or generally things that require a large number of subdomains), there's now a form you can use to request rate limit adjustments.
It's easy to set up tons of subdomains and request gobs of certs, which generally eats into the resources we have (database, bandwidth, HSMs). We need to limit that behavior to make sure legitimate users are getting good service.
Based on some public posts, I believe Let's Encrypt is using Gemalto HSMs, though I'm not sure which model or how many of them.
Just because my local pub runs a free shuttle bus to the train station, that doesn't mean they are obligated to transport my bulk freight for them.
This doesn't work for me - I used to do this with the Lego client using the DNS challenge for my registrar, Namecheap. Unfortunately by the second or third challenge it would hang and eventually give up. I didn't have the problem splitting the subdomains into seperate certs and running them 5 minutes apart.
The problem is likely in over restrictive rate limiting from Namecheap, but either way one of them needs to loosen up.
Does anybody else know about the Namecheap restrictions? I don't use their API for anything else but the LE DNS challenge (adding TXT records once every other month)
Or perhaps you need to revisit your decision to require "many subdomains" and consider whether it's a sensible decision if it relies on somebody else providing SSL certs for them inexpensively or for free.
You can buy a wildcard cert for under a hundred bucks these days - how much obligation do you think LetsEncrypt have to change their product to save you $100/year because of your design decisions? If LetsEncrypt (or Namecheap) don't work for you, pay someone who sells a thing that _does_ work for you (or change your requirements).
Point is, I had only 8 domains on the cert and it didn't manage to complete most of the time. It's either an issue with the LEGO client, LE or Namecheap API.
All it takes is 5 (or 20?) users to delete their accounts and you've used up your Let's Encrypt quota for the entire week!
Without wildcard certificates or a method to remove subdomains from a certificate, LE is still useless for UGC sites with per-user subdomains.
1. There is no way to remove a domain from an existing certificate. Changing a certificate in any way always results in a new issuance. That's just how certificates work, nothing specific to Let's Encrypt. Certificate issuance cannot be scaled to infinity, so the same limit has to apply here (otherwise anyone could just bypass the rate limit by adding and removing subdomains and launch a DoS that way).
2. The relevant rate limit here would be 20 per week, not 5. (5 is for completely identical domain sets, i.e. duplicates)
3. Do you revoke the certificate after reissuing it without the subdomain (i.e. because it's a delegated domain and your user explicitly wants to remove trust)? If not, you might as well keep it around until your next renewal of that particular certificate and remove it at that point.
That does seem like the best workaround for now. Idealy in the future I hope we can synchronously make a LE API call on the spot instead of having to manually manage a revocation queue.
You're right that the default tooling would not work quite the way I described, but this use-case seems to call for a more low-level ACME library anyway, and with that it should not be too complex to implement some kind of bucket system where you just split your subdomains in buckets of 100 each, and occasionally rebalance them as subdomains are removed (i.e. merge two buckets into one when they have less than 100 subdomains total, etc.)
Let's Encrypt is a public service, aimed at operators of individual systems who host web content or email in a casual sense, were poorly served by the complexity of getting and maintaining a TLS cert, and who empirically were basically not doing TLS.
Your posited blog host is going to be a professional or semi-professional web admin. Just call up Comodo or whoever. There's a product for that need. Let's Encrypt is not it.
In the vernacular: cry me a river.
As a webhost we have offered SSL certificates to customers for ages. Unless it's free you will see very little uptake. Which eliminates the main purpose for LE to exist, from what I was told.
I also have a rather compelling use case for far more than 20 subdomain certificates a week, but there is absolutely no "market" for that use-case - it simply increases Internet security. Which was the entire stated goal of the project, I thought.
First I've heard that LE is only for personal use :)
Not to mention the whole process is so very incredibly fugly. For something as important as it is why is there not an official online UI to manage certs? I know of atleast one online client that does exactly that but it's not official. We need the process to be as simple as making a facebook account for example. I am not very knowledgeable in certificates btw, so I may be just about to have a duh'oh moment..
Edit: Forgot to mention, I can't use auto renew scripts because my sites run on shared hosting and I don't have any kind of command line access. I have to manually upload certificates via cpanel.
Additionally, long cert lifetimes are dangerous because revocation is ineffective and things like heartbleed happen.
With that said, still a big supporter of Let's Encrypt for folks who can tolerate the constraints.
While it's designed to cycle all your certificates every day, you can still configure it for weeks/months. It's also based on credentials rather than domain verification (shameless plug, I'm Anchor developer)
You're comparing engineer time to the wildcard cert transaction price. You're neglecting to include the time for dealing with the wildcard cert (including manually remembering to renew that).
With process automation, you (or better: a collaboratively supported tool) gets progressively better at nailing renewals.
JoshTriplett's "renew every 30 days, 60 days to fix the problem" approach strikes me as inspired.
Given a 90-day duration, set up automated renewal for every 30 days, and if that renewal fails, you'll have 60 days to deal with it.
There are some good reasons behind the automation practices we encourage though, and if you're doing that stuff then the lifetime doesn't matter much. Worth considering regardless of who your CA is.
Thanks for your support!
I fully expect over time for others to compete with LE, using free certs as a loss leader for other services. I also expect the NSIs and Symantecs to continue making money catering to businesses for multiple reasons, some possibly reasonable, some stupid.
Of course, LE could make themselves more attractive to firms like mine, given the automation angle - I've had cert vendors try to offer tools to do this, but they have all been terrible, broken, security nightmares, or all three. Get this part bullet proof and I can imagine companies switching right after someone forgets to renew...
https://github.com/ietf-wg-acme/acme/pull/124 is "Enable the server to specify requirements for issuance" which seems to include wildcard cert support, but was only merged into master about 5 weeks ago. I presume further discussion is ongoing.
Personally I'm glad that they're taking the time to get this right. They could have probably supported wildcard certs a while ago, but it would have been through some mangled and limited method. The method they're now looking at seems to be much more future proof.
Of course, I may be completely wrong about this, but the above is what I gather from following the issues.
You shouldn't do anything by hand to renew certificates. The short certificate lifetime encourages you to automate the process.
Clients exist for Windows, and web servers exist for Windows that include native support for ACME and Let's Encrypt.
The problem is, if Let's Encrypt were to just operate like any other CA and provide certificates with lifetimes of one year (or more), there wouldn't be much of an incentive to go through any of that trouble in the first place, and users would just continue to manually renew things once every year (or not). SSL configuration would still be a PITA. With short-lived certificates, there's a big incentive for server software, control panels, shared hosting providers, etc. to provide first-party support for ACME. Clients will keep nagging them to do so or move on to competitors. This strategy seems to be working out just fine, as we're seeing many control panels (like cPanel), hosting providers (OVH) and other software (Synology DSM) add ACME support. I would not be surprised to see ACME support for all mainstream server software (think: apache, nginx, postfix, IIS, etc.) similar to Caddy within the next year or so.
What I'm getting at is that while the "forced automation" bit is currently a bit of a drag for some users, this strategy is the most likely to lead to a 100% (transport-layer) encrypted web eventually.
Of course (and to put it bluntly), you're free continue to put your users at risk, just like browser vendors are free to gradually break sites served via HTTP somewhere down the line.
Our goal is to encrypt the entire Web, and that means working with an almost innumerable combination of operating systems, server software, hosting providers, management interfaces, permissions, deployment strategies... Most people have a very positive experience using Let's Encrypt but it's difficult to ensure that everyone does.
It's not possible for us to build the tools necessary for every situation (financially or otherwise). Our strategy, which has been working pretty well so far, is to focus on running a secure, stable, and well-documented CA API and let our community decide what clients need to be built (and build them). This has resulted in a range of client software suitable for different situations and preferences:
This includes web-based interfaces for getting certificates from Let's Encrypt (see the "Browser" section of the client options document). Hopefully one of these will work well for you.
Then you need to look at this. CPanel just released their awesome plugin for letsencrypt. No need to do any command line stuff.
Not overly familiar with Windows administration (or the tools available to work with SSL/TLS stuff), but you can use Docker to automate basically all of that; IIRC it's supported on Windows now.
>Not to mention the whole process is so very incredibly fugly.
On the contrary, the process is pretty simple, even if you're going fully manual!
1. Generate a CSR for the domains you want to register
2. Place a proof of ownership somewhere on your server in a way that Let's Encrypt can verify it's there
3. Contact LE's API and tell it what domains you want to register, what you want to get signed, and where your proof is
4. Get a signed cert back. The rest is just server configuration to point to the cert.
If you use something like `certbot-auto`, it's basically a GUI step-through process.
The point of letsencrypt is to have auto-renewed certificates. It's intended to force you to automate the process.
I'd argue that among people who know about Let's Encrypt, VPS hosting is more popular than cPanel-style shared hosting.
It looks like current versions of CPanel now have native support for Let's Encrypt: https://features.cpanel.net/topic/provide-support-for-lets-e...
I'd wait for your host to update its cPanel (unless you absolutely need https, then I'd either change hosts or buy a certificate elsewhere).
Disclaimer: I work there
Personally I think you're badly mis-categorizing LetsEncrypt there - it's not like they're trying to bug you into signing up for a $29/month "Personal Plan" or a $199/month "Professional Plan" by keeping their limits low. They're giving their service away for free, and trying hard to only exclude the very edge cases of people who need way more resources to satisfy than the 99%.
If you've got a plan that requires hundreds of ssl certs per week to operate, and you don't have a revenue stream to pay for them, your plan needs more work. Just 'cause someone offers "free coffee", doesn't mean you can make a business out of showing up with a pickup truck full of 44gal drums and demand to have them fill you up for free so you can give it away to the customers at your restaurant...
By SaaS I meant company offering subdomains/custom domains that needs LE - not LE itself. It's not a SaaS company to being with.
> They're giving their service away for free.
LE is not a charity. It's a business.
Ahhh, sorry, my misunderstanding. (But an alternative comment - it's not that those SaaS companies "need LE", it's just that they want free ssl certs. I _want_ free Tesla's - my local Tesla dealership doesn't care... That doesn't make their prices "ridiculously high", it a problem with my expectations.)
> LE is not a charity. It's a business.
Not sure I (or they) agree with you there:
"Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. Let’s Encrypt is a service provided by the Internet Security Research Group (ISRG)."
"Consider becoming a sponsor or simply donate via PayPal."
Sure there's a wide grey line between "a business", "a 501c non-profit", and "a charity" - but if your revenue stream comes from a "please donate or sponsor us" link, not your product's pricing (whether that's a thing/service you sell, or the privacy of your free users you're selling), I think you're a lot closer to the "charity" end of that line than the "business" end.