Live data from Hacker News

Rate Limits

letsencrypt.org

51–60 of 121 posts

Re: Rate Limits

#51
post #45
post #2

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

Our you can save all the trouble and just continue staying on http.

Re: Rate Limits

#52
post #22

Earlier quoted context omitted.

@Achshar: VPSes have gotten exceptionally affordable lately. DO and AWS -- some of the current market leaders for cloud instances -- both offer reasonably-performant setups with high uptime for about $5/month, and that includes command-line access. I'd argue that among people who know about Let's Encrypt, VPS hosting is more popular than cPanel-style shared hosting.

I am a tiny single person company, VPS require a ton of setup and maintenance (for me, a noob). Believe me, I tried. I bought a vps with the intention to move over, but it was too much. I am not a unix user, I can manage xampp, but installing and making changes via command line, setting up php/mysql/apache/whatever else is more work than I get paid for. Something that just works is far more preferable to me as a coll…

Don't switch. I got a VPS for my personal site and projects a year or two ago (after 15 years of shared hosting) and if you're not comfortable on the Linux command line your server will get owned and be part of a botnet before a week is up.

Re: Rate Limits

#53
post #51
post #45

Earlier quoted context omitted.

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…

Our you can save all the trouble and just continue staying on http.

My point was that it incentivizes developers of server software to remove the "trouble" from your equation.

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.

Re: Rate Limits

#54
post #49

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

Re: Rate Limits

#55

Earlier quoted context omitted.

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.

> The chances of automation failing is higher than the chance our SSL certs will need revocation. 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.

Sounds like a great strategy!

Re: Rate Limits

#56
post #51
post #45

Earlier quoted context omitted.

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…

Our you can save all the trouble and just continue staying on http.

If you don't care about security and don't mind missing out on HTTPS-Everywhere users.

Re: Rate Limits

#57
post #49

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

HSM signing capacity is not infinite, and HSMs are expensive, but the real issue is just general DOS attacks. We aren't anywhere near our HSM capacity at the moment.

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.

Re: Rate Limits

#58
post #47

Earlier quoted context omitted.

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

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.

Re: Rate Limits

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

Re: Rate Limits

#60
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.

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.

Post reply on HN