For each domain I manage I request two certificates: RSA and ECC. For simplicity, I request/rollout the RSA and ECC certificates always together.
According to Rate Limits - Let's Encrypt, renewals are subject to the Duplicate Certificate limit of 5 per week.
This means, in the case I decide to renew my certificates three times within a week, on the first renewal both the RSA and ECC will be renewed. On the second try, again both the RSA and ECC will be renewed.
On the third try, only one of the RSA/ECC certificate will be renewed, the other will fail because of the “Duplicate Certificate limit”. This will leave the system with a functional RSA and dysfunctional ECC certificate (or vise versa). Now, the problem for this dysfunctional system is surely not in Lets Encrypt, but can happen.
I propose switching the “Duplicate Certificate limit” to an even number, so that on systems issuing both RSA and ECC certificates, either getting both certificates fail, or both succeed.
You could also ask, why do I want to renew a certificate more than once a week.
I do not need this, usually. I have a script for updating certificates, which calls other ACME-clients (now acme.sh, before certbot). This script needs to be changed sometimes. E.g. with the alternatives root chains ISRG Root X1 and DST Root CA X3, I want to issue for some use cases X1-based certificates (e.g for port 25), for other uses cases (port 443), by the same script, I issue X3-based certificates. Changing the script, and running it, shows some errors, so the script needs to be modified and rerun ... after a week. So the need to request more than one certificate renewal per week is always exceptional, but does happen.
Not forcing renew will lead to a situation, where changes to my script for obtaining new certificates, are tested once every two months, and changes can be also done once every two months.
I welcome the idea to apply the 5/week limit separately to RSA and ECC.
The rate limits are not implemented to bully and irritate users. They're implemented to keep the increased load on Let's Encrypts systems to a minimum in case of malfunctioning clients and/or abusive users. I don't think doubling the duplicate rate limit is a good idea with the purpose of the rate limits in mind.
If you happen to run into the duplicate certificate rate limit, it means you've got 2 to 3 perfectly fine RSA and ECDSA certificates already. Use those instead of issuing another new certificate and determine the reason for the abusive behaviour towards the Let's Encrypt systems and consequently fix it.
Also note that testing should be done on the staging environment, NOT on the production environment. So if you want to modify any script or setting in the client, please use the staging server first until you're satisfied. Only then use the production environment.
I explained why I think that the Duplicate Certificate limit shall be an even number.
In a perfect world, limit of one certificate per domain and week is sufficient. However, the exact mechanisms to obtain certificates vary very much in detail for each users. E.g. acme.sh likely does not have an option to generate by a single run both a X1-based and X3-based chains.
Rerunning a script for renewing a certificate must rerun the whole process completely form the beginning, when run manually, in order to ensure that rerunning the script automatically also works reliably.
As I use DANE, I cannot afford requesting new certificates too often, as DNS needs first some days to get updated with the new TLSA records, and only after that many days (as a matter of fact I use for the number of days the magic number 7), the new certificates, obtained in the past, are actively replaced on the servers, and the old TLSA records are removed.
That said, I personally do not have a huge problem with the 5 certificates per week limitation.
However for some users, which forget about all the details how certificate renewal works, the current odd number can lead to (unnoticed) problems.
While I appreciate your concerns to certain users having issues with this, I still fail to see how this is an issue. When running into rate limits, there usually either is an issue with the ACME client or users are completely messing things up. In both cases I don't think adding another single certificate to the rate limits will actually help the user in question. It'll just burn through that extra certificate too, ending up rate limited anyway, but now with 6 instead of 5 issued certificates.
The only very specific situation in which your proposal could help someone, is when they issue 4 certificates, two RSA and two ECDSA, without issuing a fifth for some reason. At that exact point, they'd have to realise they are about to possibly hit a rate limit. At that exact point, they'd have to realise "I only have one shot left!", assuming something is wrong with the previously issued certs for some reason. (Why would there be anything wrong with them to begin with?). Why wouldn't they realise that earlier? What happened with those 4 perfectly fine issued certificates earlier?
While I agree the scenario above is possible, I'm a little bit pessimistic in that it's also an unlikely scenario and that users hitting rate limits are usually not aware of the rate limits to begin with. And they'll probably just issue 6 certs and hit the rate limit at that point.
IMHO, I think raising the ratelimit from 5 to 6 is a fair idea in light of the ability to have 2 types of Certificates.
As others said above though, the proposed scenarios for this event are fairly unlikely or misunderstood.
The Duplicate Certificate Limit is usually only reached due to:
Errors in a Client
Errors by a User
Anti-Patterns in Integration
This particular ratelimit is one of the most often "abused" limits, so I don't think ISRG is going to be excited about increasing it for all. Doing so for only those instances where there are two types of certs attempted would likely mitigate their concerns, but that is a substantial engineering effort.
The limit applies to successful Certificates issued, not AcmeOrders attempted.
Clarifying what @Osiris said above, an EndEntity/Leaf/Subscriber Certificate from LetsEncrypt is compatible with both roots/chains. There are two different chains, but the Intermediates (R3, E1) share the same exact private key used to sign the EndEntity Certificate - the only difference is those intermediates are signed by different trust roots. They are basically (and might be!) the same CSR, each signed by a different trusted root. This is what allows for browsers and clients to build alternate trust paths. You can manually download and install the alternate chains, or recycle them from a previous download if they have not changed.
I can understand the charm of coupling the rate limit to the number of possible key types, but it might have implications. E.g., what if EdDSA certs are also allowed and possible in the future? Are we going to increase the rate limit to 9 or even 15, "because having just 2 attempts" (2 * 3 = 6) is not enough when dealing with 3 types of certs?
No, in my opinion, even though the thought is kind-hearted, it's also a slippery slope. Let's Encrypt has added the rate limit of 5 for a reason I think. And, the staff may correct me if I'm wrong, it's not specifically to give users 4 failed attempts before they get it right. That's what the staging environment is for! It does offer some "grace" before the rate limit hits obviously, but when we take multiple certificate types into account, where does it end?
This is confusing for me, as it sounds like you're implying that that R3 and E1 have the same keypair (which is not true). I think what you meant is that you can build a path to DST Root CA X3 and ISRG Root X1 from the same leaf, which is true. But this doesn't have anything to do with the intermediates, it's just a question of whether you're using the root cross sign or not.
Indeed, I think @jvanasco is a little bit confused about the 2x2 key type vs. certificate chain matrix
R3 and E1 can never have the same private key, as R3 is a RSA certificate and E1 is an ECDSA certificate. Both could have a "long chain" chaining up to DST Root CA X3, but that is NOT offered by Let's Encrypt for ECDSA certificates signed by E1. You could script this yourself if required obviously, but no ACME client could do it on its own using the offered chain(s) by Let's Encrypt.
Anyway, changing an intermediate chain shouldn't require re-issuing a certificate in the first place, as it does not change the end leaf certificate. So to me, this is all a non-issue to be honest.
By the way, note that an ECDSA end leaf cert signed by E1 chaining up to DST Root CA X3 would be terribly long:
ECDSA end leaf cert <- E1 <- ISRG Root X2 <- ISRG Root X1 <- DST Root CA X3
@9peppe I think it's customary to have the arrows pointing from root to end leaf cert, signifying which certificate signed which. Also, adding "x-sign" doesn't add anything, as the "<-" (or "<" if you will) signifies a signing operation, which would obviously mean that it's a cross-sign instead of a self-sign. Only the root certificate at the rightmost position would be self-signed. "Cross-signed" is just a manner of speaking, but technically not different than e.g. E1 signing an end leaf certificate. It just differentiates between self-signed and not-self-signed when talking about certs that are also root certificates.
A server only sends one payload as part of the negotiation. The limit to certs in the payload is pretty large. In private corporate environments, I've seen 5+.
In terms of serving RSA+ECDSA, under nginx you configure both as multiple definitions if ssl_certificate / ssl_certificate_key, then prioritize your choice of certs by setting ssl_prefer_server_ciphers on; and ordering the list of ssl_ciphers accordingly. you can also leave that blank and let the client decide, but basically nginx chooses the corresponding cert/key based on the cipher negotiated with the browser. I don't know if/how apache/caddy/etc implement this.
Let's Encrypt didn't add an alternative chain for the E1 chain as the idea is that clients modern enough to use ECDSA wouldn't benefit from the DST Root CA X3 chain. At least, I thought that was the idea behind it. Although, even Android 4 does have ECDSA capabilities and also does require the DST Root CA X3 cross-sign..
