Your post is kinda spammy to me, that's what I think
It's great people implement Let's Encrypt in their product, but in my humble opinion, your post screams 99% "spam!" and just 1% "Let's Encrypt". Your screenshot isn't even from the Let's Encrypt implementation..
Well, I’m assuming your main intention is to deliver a CDN If a user intents to use the CDN “for real”, it’s no problem the CDN itself generates the private key, as it needs this to act as a TLS endpoint. But if a user only uses your service to get a certificate and consequentially doesn’t use your CDN-service any longer, I’m not so enthusiastic: private keys should only be known by the people and/or services which really need to know the private key.
So my suggestion would be to emphasise on the “Look, we’ve added Let’s Encrypt functionality to our CDN!” (a few screenshots on how the implementation works would be nice!) without too much emphasis on the “Look, we offer a CDN!” part, but not so much on the “You can use our service to get a certificate, even without using our CDN!”, as the latter would be a bad implementation as a 3rd party has the private key.
And yes, I am pretty critical when it comes to cryptography
And again, it’s great if Let’s Encrypt is being used out there, don’t get me wrong. I very much like the fact you bother to implement it! Kudo’s! It’s just the way of putting it out there
@schoen, just curious, are you part of LE’s team? Is it possible for us to negotiate a higher quota for our implementation of LE since we’re deploying LE for users.
The most important aspect is in the IP restriction, since we have a single Anycast IP validating all the LetsEncrypt challenge.
The second is the 5 subdomains for 7 days.
Internally, It is so easy to get an SSL cert that we dogfood all our sites, including subdomains, etc, with LetsEncrypt certs merely by pointing the IP address to our CDN. And that has definitely exceeded the 5 subdomain restriction.
Do you have an email that I can email you regarding this?
I don’t really see the problem. As far as I can tell from your website, you’re not a webhoster hosting multiple sites with a common domain name for each sites hostname, correct? Users with all kinds of hostnames (and different domain names) can use your CDN.
So if you’re hitting the 5 certs/7 days rate limit because some of your users are using a common domain name, the only solution would be for LE to lift the rate limits entirely, for everyone. As everyone can be a customer of your CDN. And that’s not very likely to happen in a short time from now as far as I know…
AFAIK the limit is "5 certs per domain per 7 days". If you're hitting it, that would mean you or your customers haven't made up your/their mind and are requesting the re-issue of certs for the same domain more than 5 times per 7 days.
Perhaps a solution would be to offer test certs (--test-cert, --staging) for people to mess around and check out your service, and only issue a real cert when they are happy with their setup.
You’re right actually. I just realised that the throttle per IP has been lifted to a really reasonable number. So I guess we can consider this issue closed.
That’s also only a problem if you generate a new account key for every certificate you request… But it should be very much possible to use a single account key. So the X registrations per Y hours for a single IP wouldn’t be a issue.
If a user intents to use the CDN “for real”, it’s no problem the CDN itself generates the private key, as it needs this to act as a TLS endpoint. But if a user only uses your service to get a certificate and consequentially doesn’t use your CDN-service any longer, I’m not so enthusiastic: private keys should only be known by the people and/or services which really need to know the private key.