Live data from Hacker News

Rate Limits

letsencrypt.org

61–70 of 121 posts

Re: Rate Limits

#61
post #49

Earlier quoted context omitted.

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 fo…

Are you able to disclose the speed and/or cost? I know people working on cheaper HSM's. They might find the numbers useful as an assessment of how practical their own are.

I don't have any first-hand knowledge, sorry. (Not affiliated with ISRG.)

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.

Re: Rate Limits

#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 a certificate, LE is still useless for UGC sites with per-user subdomains.

Re: Rate Limits

#63
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…

A couple of points:

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.

Re: Rate Limits

#65
post #63
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…

A couple of points: 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…

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

Re: Rate Limits

#66
post #65
post #63

Earlier quoted context omitted.

A couple of points: 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…

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

My comment regarding revocation was to clarify that unless you're currently revoking each of these certificates after removing a subdomain, there's probably no reason why you should remove the subdomain right away (instead of with the next renewal). I'm not suggesting you should revoke the certificates if this is just an implementation detail and not about actively revoking trust.

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

Re: Rate Limits

#67
post #66
post #65

Earlier quoted context omitted.

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

My comment regarding revocation was to clarify that unless you're currently revoking each of these certificates after removing a subdomain, there's probably no reason why you should remove the subdomain right away (instead of with the next renewal). I'm not suggesting you should revoke the certificates if this is just an implementation detail and not about actively revoking trust. You're right that the default toolin…

I was referring to the issuance rate limits, not about letting anyone add domains to their certs.

Re: Rate Limits

#68

I 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…

I had a few issues debugging the callbacks fired for letsencrypt-auto (i.e. how --post-hook and --renew-hook) works.

Almost hit the limit before I got it working

Re: Rate Limits

#69

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

How much does it cost to manually renew your certificate every year? How much does it cost if you forget to manually renew it, or make a mistake with one of the manual steps?

Re: Rate Limits

#70
post #67
post #66

Earlier quoted context omitted.

My comment regarding revocation was to clarify that unless you're currently revoking each of these certificates after removing a subdomain, there's probably no reason why you should remove the subdomain right away (instead of with the next renewal). I'm not suggesting you should revoke the certificates if this is just an implementation detail and not about actively revoking trust. You're right that the default toolin…

I was referring to the issuance rate limits, not about letting anyone add domains to their certs.

Adding a subdomain would increase the "Certificates per Registered Domain" counter by one, just like removing a subdomain would. There's no difference.
Post reply on HN