j4cob

Wow, thank you for all of your work on Sensei's Library! It made a huge impression on me in ~2003, and has really helped me understand Go better and get stronger.

I work on Let's Encrypt. I'm glad you find the service useful!

Folks may also be interested to read this useful summary of issues around locally installed roots: https://github.com/njh/dymo-root-ca-security-risk/blob/maste...

The implicit threat model here is "no one outside your machine can do something to you to make 127.0.0.1 traffic route elsewhere." It's true that software running on your machine can make copies of things and send them elsewhere, but that's not the point of the sentence you quoted.

FYI, OpenSSL has a new flag that makes the "-extensions" part somewhat simpler, but most people won't have it in their copy yet: https://github.com/openssl/openssl/pull/4986

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.

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

(Let's Encrypt engineer)

Token bucket is a good idea, and I agree that it would make the user experience of hitting rate limits less onerous. We implemented sliding windows because they were straightforward to implement based on our long-term database state. I'll do some thinking about whether we can emulate a token bucket style on top of that without having to add another source of truth for rate limit information.

FWIW, cPanel just announced Let's Encrypt integration with their AutoSSL feature: https://blog.cpanel.com/announcing-cpanel-whms-official-lets...

This was a performance decision. Cross-signing the root instead of the intermediate would mean that web servers would have to include both the root and the intermediate in the chain they serve, rather than just the intermediate. That would add a full packet to each handshake.