Hacker News Reader

Comment by justinsb | Hacker News Reader

I love LetsEncrypt - the only problem I've hit is the rate limits (in particular 20 new certificates per registered domain per week, when moving domains). I guess I could have avoided this by combining names into a single certificate, but I wonder why there's not an option to pay/donate to bump the limit temporarily: when I hit the limit I would gladly pay $50 or $100 instead of going through the manual process with a legacy CA. Even though wildcard certs will make this better, the fear of accidentally hitting a limit and being unable to renew certificates remains a concern for me.

View on HN

kiallmacinnes already mentioned that rate limits have no effect on renewals, but more importantly: There's a fairly simple process to bump rate-limits if your use-case requires it[1].

[1]: https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw8...

Once you hit this limit, you are not prevented from renewing existing certs.

You do have to be a little careful, for example adding a new SAN to a cert might fail due to 20-per-domain-per-week limits, attempting to renew that cert without removing the extra SAN will fail.

Thanks for the note on the renewals (and the caveat!) - that does make it less concerning as it would only impact new services.

> I wonder why there's not an option to pay/donate to bump the limit temporarily

> I could have avoided this by combining names into a single certificate

You can get a cert (via <=20, 100 SAN combined certs) 2000 subdomains per week.

I actually don't really understand your problem case though. What do you mean by:

> when moving domains

This requires sharing the same cert and key for everything. Lots of software doesn't really like this way of doing things, I've been bit by the 20 limit too - and yes, I could have swapped to SANs, it wouldn't have fit with the deployment tooling for all the different things!

> This requires sharing the same cert and key for everything.

That entirely depends on where/how you're terminating TLS.

Do you really have > 20 different pieces of independent software all doing their own TLS?

This is exactly what things like HAProxy are for.

Yes, with Kubernetes, the patterns used are a little different than if you were to setup TLS and haproxy by hand (I actually use nginx, but it doesn't particularly matter).

You deploy software, that software declares it needs TLS for its endpoint, and certs are obtained.

While moving from one cluster to another, a new deployment of everything was done - about 20 different services - a few minutes work with Kubernetes. However, the fetching of TLS certs stopped working for the very last service!

Yes, I should have migrated the certs, however, the migration was happing due to a failure - I couldn't access the old certs.

I now make sure to backup those secrets rather than rely on re-issuance.

Still, for a usecase like Kubernetes, 20 certs per domain per week is limiting. I do totally understand that the quotas are in place because cert issuance is expensive, but I'd happily pay a yearly subscription fee to LE to cover the costs and help fund them if the option was there!

It's possible to have another implementation of the ingress controller that will not create one certificate per host

This is kind of what I expected too. Surely that component of the architecture can (even if the OP's doesn't) be smart enough to handle various certificate scenarios - there must be someone using it with a wildcard certificate, for instance.

It's possible, but that would weaken security.

Each independent application is isolated from each other, sharing a TLS cert/key among them all means we're weakening security - again, the Kubernetes patterns here would mean we need to duplicate the secret data into each applications namespace, allowing a compromise of one to compromise the TLS of all.

There are legitimate reasons to not share a single TLS cert for everything in an environment like Kubernetes.

(I'm nearly certain it's not possible to reference secrets cross namespace when declaring an ingress secret, or mounting a secret)

> the Kubernetes patterns here would mean we need to duplicate the secret data into each applications namespace, allowing a compromise of one to compromise the TLS of all

yeah, this would be wrong indeed.

Is there any requirement for an TLS terminating proxy acting as k8s ingress to actually store the TLS secrets in the same namespace where the requesting ingress object lives?

The semantics require it, as the ingress resource references a secret without the option of providing a namespace for that secret.

There may be ways around this, however, I've never personally looked for them.

By "when moving domains" I mean that I'm enabling a production domain (project.com), where previously I was working on a development domain (project-dev.com). More recently, I was deploying gitlab and exhausted my quota simply because of mistakes I made along the way. This was simply my mistake, so I don't think it would be appropriate to request an official rate limit increase. If (say) a $100 donation to the EFF allowed me to specify a domain on which the rate-limit-counters would be reset to zero (as a one-off), I'd likely have done that - it's easier than changing the process of how I'm managing certificates.

Reply on news.ycombinator.com