Hacker News new | past | comments | ask | show | jobs | submit login

(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 the risk of abuse.

Also, even if mit.edu doesn't apply for a rate limit, people can issue certificates for 20 new sites under mit.edu per week, or 1,040 new sites per year. And in fact you can see a number of such sites in the crt.sh logs: https://crt.sh/?q=%25.mit.edu&page=1 (note: loads slowly).

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.

[1] https://github.com/openstack/anchor

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.

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact