We currently have 8 Dev/QA environments, and we are trying to make a cert for each one. How can we avoid a rateLimit? It seems like there is a limit of 5 per domain in a 7 day period. I would just bundle them into a single cert, but since LetsEncrypt doesn’t support wildcard, we have too many SANs to just bundle all 8 environments into a single cert.
Error: urn:acme:error:rateLimited :: There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: powerdms.net
We currently have 8 Dev/QA/DevOps environments. Each with 17 SANs. We expect to grow this to 10-15 environments over the next year. Ideally, we would get a wildcard for each these domains, and be done with it. But, LetsEncrypt doesn’t support wildcard yet. In order to test a full ‘stack’ of our environment, and have them all running at the same time, this is what we came up with. It might not be the best solution, but it’s what we’re going with. We’ve got most of the groundwork laid with Chef to automate standing up each environment. Just need the certs in place so we can (more) accurately test as if they were production servers.
17*8 = 136. You could fit that in 2 certificates. So I don’t really see the problem, other than that you’ve already hit the limit. Probably because you didn’t know about the limits in the first place (it’s mentioned in the FAQ). Tip: experiment on the staging server first. It hands out useless certificates (as in: useless issuer, the rest is just as the real deal), but that way you’ll know your way around the client if you’re ready to request a working certificate. That way you’ll minimize the risk of accidentally hitting the rate limit.
So you’ll just have to wait for the sliding window to lift your limit in 7 days (or less if you requested your first certificate earlier…)
Agreed on both counts. (We could fit in 2 certs, and we need to wait until the limit is lifted in 7 days)…
However, going with the Chef model, it’s either 1 cert total, or 1 cert per environment. It’s not the ‘chef way’ of coding to say … if (env == blah , or blah, or blah) use cert1 … else if ( env == blah or blah or blah) use cert 2… It’s much more efficient to just call the chef run and use a variable that utilizes the chef_environment as part of the path to locate the cert… i.e.
node.chef_environment = “vagrant”
node[:certname] then resolves to vagrant.powerdms.net.pfx
node.chef_environment = “qa3”
node[:certname] then resolves to qa3.powerdms.net.pfx
I think there is no way to avoid RateLimit at the moment. However 5 certs / week means 20 / month. Assuming you have issued the certificates for 5 of the environments already, your only problem is that you will have to wait one week to issue certs 6-10. After that all you need to do is renew certs 1-5 every 1st of the month, certs 6-10 every 9th, 11-15 every 16th. Spreading renewals in a two month period you can easily get for example 40 different certs per domain. Also keep in mind that limits are probably going to be relaxed in the future.
PS. I use 8 day intervals just to be on the safe side.
a) Why you does not use the staging environment of LE for your dev environment ?
b) You can use SAN and build one certificate that is valid for up to 1000 FQDNs.
You can add up to 100.
We’ve got most of the groundwork laid with Chef to automate standing up each environment. Just need the certs in place so we can (more) accurately test as if they were production servers.
