I couldn’t find anything in the code about rate limits being decreased on revocations. It seems to make sense that way, since the revocation doesn’t somehow negate the additional load.
Your rate limit counts seem accurate and match what I got on my domains.
Your description is exactly right, as is your example.
And yes, the reason revocation does not reduce the limit is because the CA has to continue producing fresh OCSP responses for revoked certs until they expire.
Fun fact: The CA must be able to sign 30 OCSP responses for each certificate issued before it expires, over its lifetime (90 days/certificatex1 ocsp response/3 days=30 ocsp responses/certificate )
thx. is there a way for us to poll or something via a web API so we can see what our current rate limit states are? Just doing a lot of testing of huge (100 domains per cert...the limit) SAN certs, and don't want to hit the thresholds, but also don't want to drive myself nuts staying under them if there is an easy way to determine my current state?
but why the insane requirement of resign OCSP for revoked by the CAB? I mean once revoked, always revoked, period, or is that wrong and you can actually un-revoke a cert?
Probably has to do with the validity period of the OCSP response. Perhaps the standard doesn’t allow signing a response further than X seconds into the future in order to avoid abuse. Otherwise if somebody would compromise a CA certificate, they could increase the time limit so clients requesting the OCSP status would deem it valid for whatever time period the attackers deemed fit.
With that said, we can’t be sure everyone requests the OCSP status in said time period. The server must therefore sign a response for every time period. I don’t know if the standard has any requirements how the client must/should process a situation where a OCSP response says a certificate is valid when an earlier response says it’s revoked.
I get the point but for revoked certs should be one-time signed and in case revoke dont care about the time but the fact that there IS a revocation in there that is valid from the point of trust chain.
What is the reason for this incredibly low limit of 5 / week for a domain? What is the consequence of allowing say 100 ? Please consider raising the limit as it makes using the system very unpractical.
5 is actually not low...that would be a new cert every weekday! If you need to test scripts, etc they always have the staging server that you can test against that has low/no limits AFAIK:
Keep in mind (from my OP), this count determined by the number of certs upon which a given domain appears, NOT the number of times it appears on a cert. So,you can have successful issuance of a cert that looks like this
and that only counts as 2/5 of the limit being discussed, even though you have now 29 hostnames covered with those two certs. Does that make more sense?
For example, We are moving from CACert to Letsencrypt on 70 servers (VM + physicals servers) for 160 names all under the same domain name (crans.org). All sites and servers are controlled by the same organisation, so the name has nothing to do on the PSL.
To circumvent the rate limit, we came up with 2 VM (a main and a backup) as https end point, sharing the same ip (shared with keepalived), and generating 2 certificates (max 100 SAN by cert and need 160 names) with all the names on it. The communication is then proxied on a secure vlan in http to the real server.
glad you got it worked out. I think the new arrangement you have, offloading your SSL to a front end piece (like a load balancer) is more typical and why the project sets 5 as a limit that should work (generously) for typical scenarios.