Letsencrypt is really a fantastic project. I can (sorta) understand why people might squeal about 90 day cert lifetimes, but just wanted to put it out there that I think that LE makes the internet a better place. @jaas adding to this thread and providing context on the decisions they made is really is just the icing on the cake :)
Rate Limits
41–50 of 121 posts
Re: Rate Limits
#42What I personally find more inconvenient than any of those limits (as a non-power user) is the 3 month lifetime of certs. I am a windows user. Running a VM once a month just to renew my 3 certs is a huge headache. Will it really be that much of a burden to have like a year? 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 manag…
"..via cpanel"
Then you need to look at this. CPanel just released their awesome plugin for letsencrypt. No need to do any command line stuff.
https://features.cpanel.net/topic/provide-support-for-lets-e...
Re: Rate Limits
#43Earlier quoted context omitted.
Automation failing once shouldn't be a catastrophe; you could renew after 30 days and issue a pager alert if it fails. Then you'd have 60 days to figure out what went wrong, manually update it, and fix the issue with the automation.
At fully loaded engineer costs, if someone takes more than an hour or two to investigate, its already more expensive than a wildcard cert.
If all you care about is money, sure.
Re: Rate Limits
#44Earlier quoted context omitted.
I'm pretty sure there are letsencrypt windows clients. Which you can run every week to make sure they auto-renew. And you could do this as well by running the VM regularly, automatically. The point of letsencrypt is to have auto-renewed certificates. It's intended to force you to automate the process.
I can't run those scripts. My site runs on shared hosting, I don't have command line access. All I have is a file manager for my 'htdocs' and standard cpanel stuff.
get a better hosting environment.
Re: Rate Limits
#45What I personally find more inconvenient than any of those limits (as a non-power user) is the 3 month lifetime of certs. I am a windows user. Running a VM once a month just to renew my 3 certs is a huge headache. Will it really be that much of a burden to have like a year? 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 manag…
What certificate issuance through a public API (ACME) allows you to do is have your server software automatically request and deploy a certificate for your hostnames (like Caddy[1]). That's probably the simplest process you can get in this space, even compared to things like certbot (which does similar things, but is not a first-party component of the web servers it supports). There's no need for any kind of UI, the best case is: give your server software the URL to an ACME server (Let's Encrypt), your hostnames and (optionally) your email address, and it'll take care of things for you. It's a bit like DHCP leases - you're probably not managing those manually either, and there's certainly no need for a fancy UI. It just works behind the scenes.
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.
Re: Rate Limits
#46I really don't see what problem people are having with the 'official' certbot CLI client. It's very straightforward.
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
The results:
- 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 myname@mydomainname.us. - 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 total 8.0K 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
Re: Rate Limits
#47Earlier quoted context omitted.
Automation failing once shouldn't be a catastrophe; you could renew after 30 days and issue a pager alert if it fails. Then you'd have 60 days to figure out what went wrong, manually update it, and fix the issue with the automation.
At fully loaded engineer costs, if someone takes more than an hour or two to investigate, its already more expensive than a wildcard cert.
The few times I've had Let's Encrypt's automation fail it's taken a few minutes, not hours, to investigate and fix. Anecdotal, sure, but I don't see it taking hours to fix
Re: Rate Limits
#48I really don't see what problem people are having with the 'official' certbot CLI client. It's very straightforward. 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…
For some people, the command you gave would fail because they can't bind port 80 because apache or nginx is already listening there. And they might not be able to stop it and restart it. That's not the case if you're only running an SMTP listener, but it would be if you're already running an HTTP listener.
(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.)
Re: Rate Limits
#49I wish they didn't have the limit of 20 certs per registered domain. There are a lot of use cases this blocks - Plex's use case [1] 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.btcentralp…
The signing capacity of the HSM (or possibly HSMs, I'm not sure) holding the intermediate certificate is limited. These devices are quite expensive, so it's not that easy to scale this resource. In comparison to that, a pending authorization is just a row in some table, so that doesn't take up too many resources.
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[1].
[1]: https://docs.google.com/forms/d/e/1FAIpQLSfg56b_wLmUN7n-WWhb...
Re: Rate Limits
#50For everyone that complains about Let's Encrypt, I just want to state that Let's Encrypt solves the single largest use case for issuing certificates for domains - a single server you control which hosts one (or more) website(s).
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.