This is a ridiculously low limit for a SaaS provider.
It's free. It is a strict improvement from where things were.
Rate Limits
91–100 of 121 posts
Re: Rate Limits
#92Earlier quoted context omitted.
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
You can use the --test-cert or --dry-run flags for this purpose. The former just makes the client use the staging server (which has higher rate limits), while the latter uses the staging server to simulate renewal, stopping short of actually storing the staging certificates (in other words: ideal for testing renewal in production).
The dry run flag didn't trigger the hooks, didn't think about the --test-cert flag, would've been helpful! Thanks
Re: Rate Limits
#93I 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…
(Let's Encrypt engineer) > 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 th…
Oh, that's great! I didn't realise, from the rate limit page, that the exemption form exists.
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?
Re: Rate Limits
#94This thread would've made a much better example for the "users you don't want" article[1] than disabled children. It is not reasonable to expect a free service to solve all certificate related problems.
On the other hand, it shows, yet again, how dysfunctional the certificate industry is.
Re: Rate Limits
#95Earlier quoted context omitted.
(Let's Encrypt engineer) > 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 th…
Oh, that's great! I didn't realise, from the rate limit page, that the exemption form exists. 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?
In your case, why not use multi-name certificates? According to the article, Let's Encrypt lets you request up to 100 names per certificate, so you could cover all your microservices with just a few certs.
Re: Rate Limits
#96Earlier 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.
This is only true if all of your engineers are operating at 100% capacity all the time. In my experience that's generally not true (and if it was they'd probably burn out pretty fast). Unless you're staffed entirely by contractors and pay by the hour?
Re: Rate Limits
#97Earlier quoted context omitted.
(Let's Encrypt engineer) > 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 th…
Oh, that's great! I didn't realise, from the rate limit page, that the exemption form exists. 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 your use case, I'd recommend that you either combine them using SAN certificates, as one commenter suggested, or issue them over the span of a few weeks. Processing rate limit requests is one of the few non-automated tasks we do, and we really try to keep the volume to a minimum so we don't get overwhelmed.
Re: Rate Limits
#98This reminds me of the question of which kinds of attacks would be possible if Let's Encrypt issued SHA1 certificates.
Re: Rate Limits
#99Earlier quoted context omitted.
(Let's Encrypt engineer) > 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 th…
Oh, that's great! I didn't realise, from the rate limit page, that the exemption form exists. 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?
Are they public microservices? You mentioned VPC, so if they're not, you may be interested in running your own CA internally. Anchor [1] was written pretty much for that purpose, but with even faster certificate cycling by default (days, not months). Of course that's for internal services only - anything internet-facing would need a trusted CA.
Re: Rate Limits
#100Earlier quoted context omitted.
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
Anecdotal, but managing thousands of VMs, hundreds of ELBs, service discovery, several CI pipelines, and so on, its never a few minutes unless its a blatant misconfigured flag.
If you're issuing lots of internal certificates, you may be interested in using Anchor [1] instead. It's designed for that use case and with own service you don't need to worry about rate limits, name limits of similar issues.
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)