j4cob
Joined 11 years ago
Karma
208
Submissions
13
Member since
Jan 17
Recent submissions
Comment · 5 years ago
Comment · 8 years ago
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...
Comment · 8 years ago
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.
Comment · 8 years ago
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
Comment · 10 years ago
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.
Comment · 10 years ago
(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).
Comment · 10 years ago
(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.
Comment · 10 years ago
FWIW, cPanel just announced Let's Encrypt integration with their AutoSSL feature: https://blog.cpanel.com/announcing-cpanel-whms-official-lets...
Comment · 11 years ago
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.
I work on Let's Encrypt. I'm glad you find the service useful!