Live data from Hacker News

Rate Limits

letsencrypt.org

111–120 of 121 posts

Re: Rate Limits

#111

Earlier quoted context omitted.

Wait, what? How does the 3 month cert limit stem from a much more complicated problem? 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.

> How does the 3 month cert limit stem from a much more complicated problem? 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 mo…

> A three months max duration limits the potential liabilities to three months.

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.

Re: Rate Limits

#112
post #9

Earlier quoted context omitted.

So... this is less an issue with Let's Encrypt and more an issue with restrictions imposed by cPanel and your choice of host.

In fact isn't shared hosting the most common type of hosting? Any larger sites can afford paid certs anyways so letsencrypt is especially suited for smaller sites like mine, that can't afford the cert but also don't have the luxury of a dedicated machine/vps.

You're right that it's a pain for users trying to do it themselves, but some shared hosters already offer integrated LE, like DreamHost[1]; hopefully most will, if users push for it.

[1] https://www.dreamhost.com/hosting/ssl-tls-certificates/

Re: Rate Limits

#113
post #88
post #62

Let's Encrypt doesn't support removing subdomains from a certificate like it supports adding subdomains, so people offering per-user subdomains need to create a completely new certificate every time a user deletes their account. 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…

> LE is still useless for UGC sites with per-user subdomains 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…

I do completely agree. Use right tool for your job.

Re: Rate Limits

#114
post #19

Earlier quoted context omitted.

I think LE's 90-day expiration reason #2 is really the key: encouraging automation. So what it really is investing effort once and working for arbitrarily period of time. If the TLS certificate renewal process cannot be automated but must be manually done for some reason, that perhaps LE certificates are really not what you are looking for.

The chances of automation failing is higher than the chance our SSL certs will need revocation. With that said, still a big supporter of Let's Encrypt for folks who can tolerate the constraints.

If critical automation failure is treated as a serious bug in LE, then it should really just be a matter of time before 99.9% of them are fixed and LE can enter a state of maintenance rather than development. LE (the client) don't need to expand until it can read mail.

Re: Rate Limits

#115
post #59
post #50

For 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.

And unless something really odd is happening, a small server owner will run into these problems when first setting up your LE certs for automated renewal and not any time thereafter.

Not even then. They should be using the staging servers for all testing and integration so they'll never hit the limits (a small server owner will not be needing more than 2,000 certificates per domain to be issued per week).

Re: Rate Limits

#116
post #4
post #3

Earlier 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.

Either change host or automate submission of cpanel's certificate. This could need modifying an ACME client. It might mean letsencrypt is not ready for you (yet).

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).

Re: Rate Limits

#117

Earlier quoted context omitted.

I appreciate what Let's Encrypt is doing, and have even donated, but internally at our org (as a DevOps), I cannot sell certs that expire every 90 days; $300/year for a wildcard cert is a small price to pay for 1 year expirations.

I'd absolutely love to have wildcard certificates as well. I think Let's Encrypt has plans to offer them, as soon as they finish producing a new version of the ACME standard that supports authorizing them.

It looks like that should be happening soonish if I read the Github issues correctly.

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.

Re: Rate Limits

#118
post #59

Earlier quoted context omitted.

And unless something really odd is happening, a small server owner will run into these problems when first setting up your LE certs for automated renewal and not any time thereafter.

That is something I do not see in my own (n=1) experience. The only problem I had was with a poorly written crontab entry, that was totally my fault. 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.

This was also my scenario.. 10 domains, one virtual server..

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.

Re: Rate Limits

#119

The official advice from LE about many subdomains is to combine them onto one cert with Subject Alternative Names. 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 apa…

" … one of them needs to loosen up." 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 you…

Er, hang on, I don't have a sense of entitlement about this and if it came across that way it wasn't intended.

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.

Re: Rate Limits

#120
post #74

The official advice from LE about many subdomains is to combine them onto one cert with Subject Alternative Names. 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 apa…

If Namecheap sends a specific HTTP Status Code or a header like Retry-After when it performs rate limiting, this could probably be fixed in the lego DNS provider code for Namecheap. Do you happen to have any logs from when this happens? (Not sure how verbose the logging is and whether that information would be included, but it's worth a shot.)

I don't i'm afraid but I will try and pull one this weekend. Only reason I didn't do this previously is i'm pretty confident it's a Namecheap issue so i'd rather not bug the LEGO devs about it if so.
Post reply on HN