We have a few certificates because we're hosting >100 domains.
If we have five certificates, and renew them twice in a week, will we hit the Duplicate Certificates limit since the account has received five duplicate certificates?
Or is the limit specific to the set of domains that were duplicated, so we can renew the whole set of certs up to 5x in a week?
It's per set of domains.
Why are you renewing a certificate once or even twice a week? It should be renewed between 60 and 90 days.
The Duplicate Certificate limit exists across accounts, however it is for the exact same certificate. If a certificate contains "Example.com, Foo.Example.Com, Bar.example.com", the limit applies to any accounts trying to issue that exact same certificate. Adding or removing a domain from that certificate would mean it is not a duplicate.
The Duplicate Certificates limit is specific to the set of domains that are duplicated.
There are other limits, though normal usage wouldn't hit them. But usually it's the kind of thing where if you have to ask, your system is using more of Let's Encrypt's resources than you really need to. In general systems should reuse the one certificate, rather than like multiple servers each getting their own, at least once you're past a couple servers.
See the "Storing and Reusing Certificates and Keys" section of the Integration Guide.
If I had to guess... [no other choice given!]
I'd say that they expand the cert every time a new name is required - too many times per week.
[which means they are hitting a completely different limit]
OR
Lost in translation...
So, the real question is:
What problem are you trying to solve by reissuing the exact same cert (more than once per 60 day period)?
So, right, there's an x-y problem in my question. The context is we have a couple hundred domains, packed into a few certs due to constraints of our LB setup; each month when the cached validations expire, the person adding a new domain waits on a bunch of domains to revalidate, and often has to retry the process a few times because of LE-side DNS errors (reasonably close to this description, FWIW: DNS problem - SERVFAIL for (seemingly) correctly replied names). The workaround I was considering was renewing our certs more often than expiry requires to have a chance of getting revalidation triggered by an automated process between the time the cache expires and the time a human wants to make cert changes.
The volume as well as content of replies make it amply clear the LE community does not consider early renewals a good idea. 
I've made some other changes on our side to try to make the ergonomics of the process a little less bad already and can think of others. At this point I don't expect a solution, but now you have more context.
What is your load balancer? There may be some options for you!
It's an AWS ALB. We could deal with our issues by spreading client domains across more of its 25 cert slots and some other better tooling on our side. Just a matter of round tuits to clean up an existing setup. Thanks for your answers here.
Unfortunately I don't know of any tricks on that platform (or any other PAAS/SAAS options). If you were using a software load balancer, a handful have hooks during the SSL handshake that would let you dynamically choose a cert. ALB is likely doing that under the hood.
For example, we open sourced our ACME client / cert manager with an OpenResty (nginx fork) plugin to do dynamic ssl certificate loading GitHub - aptise/peter_sslers: or how i stopped worrying and learned to love the ssl certificate .
A few other approaches that could work...
LetsEncrypt follows redirects, so you could just run a redirect rule on all the /acme-challenge requests onto a dedicated domain. e.g. everything would redirect to http://acme-auth.example.com/.well-known/acme-challenge/{CHALLENGE}. That might get around the DNS errors if they are related to your nameservers and loadbalancers.
This one may be a long-shot, but your clients can delegate their acme_challenge text to a system you control, and then you can use DNS-01 authorization via an acme-dns (GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.) installation.
A lot of the community members here are very adamant about minimizing resources on the LE/ISRG infrastructure - and in most questions posed here, the underlying issue is a completely broken and mindless installation. In your case, I don't see any of that as applicable to one of the issues you mentioned - you're basically trying to find a better way to re-allocate domains across a limited number of certificates as you enroll new domains.
The other issue you mentioned, I don't quite understand -- you shouldn't need to renew an identical certificate more than once every 60 days. If you're adding a domain to a certificate, that's not a duplicate or renewal as far are LetsEncrypt is concerned - even though Certbot might call it that; it's an entirely new certificate.
I'm probably missing something, as AWS's ALB isn't a product I've used yet, but why would you be using Let's Encrypt's certificates with it rather than AWS's own Certificate Manager (which gives you their own CA's free certs that automatically renew as long as you keep the validation CNAME in your DNS)?
why would you be using Let's Encrypt's certificates with it rather than AWS's own Certificate Manager (which gives you their own CA's free certs that automatically renew as long as you keep the validation CNAME in your DNS)?
Good question! We don't control customers' DNS; they just point a couple CNAMEs at us when they sign up. In theory we could use ACM for new domains and LE to support existing ones but it makes ACM a bit less attractive. (We couldn't have used ACM from when we started because it didn't exist then.)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.