Don't store cert backups

[gohai]

Those are inconvenient if you don't want to run Redis as LRU cache. We are more interested in not silently discarding any certificates, and scaling Redis with increasing number of domains, so we don't.

If this change is not acceptable, another scheme could be to store the previous (":old") certificate in addition to the current one (":latest"). This way we'd only be storing at most two certificates per domain in Redis, and not a growing number due to renewals.

[GUI]

Apologies for the delay on this one too, but I’ll try to take a look at this in the next couple weeks. Thanks again!

[GUI]

Ah, I had forgotten that we were indefinitely storing all the previous certificates, so thanks for catching this! I can see how this could become an issue with lots of certificates, particularly for in-memory stores like Redis.

That being said, I would like to retain the ability to keep previous certificates for debugging purposes by making this more configurable, instead of getting rid of the backups completely. I might be overly paranoid, since I'm not sure I've actually ever had to use the old certificates, but I'd probably prefer to keep a few old copies around for my own installations (again, I just personally tend to be overly-paranoid about deleting things :).

So my general idea for how we could maybe make this more configurable might be something like:

• Keep the timestamped certs as-is.
• Introduce a new keep_previous_certs option that you could use to tune how many previous certs to keep. We could maybe default it to 3 (or maybe that's just me still being overly-paranoid), but you could set it to 0 for your use-case of not wanting any backups.
• After storing a new latest cert, we'd run a cleanup process to delete all the old certs except the last keep_previous_certs ones. This cleanup process would also help prune old certs from existing installations.

Does something like that approach make sense to you? If so, I know this more configurable approach might not be something you need for your use-case, so while you're more than welcome to implement it, I'm also happy to implement these changes at some point.

Thanks again!

[gohai]

@GUI Thanks for having a look!

From the point of our use-case: I feel that the benefit of having extra backups in Redis is limited unless there is a built-in mechanism to fall back to those backups in the event of an issue. We never had any issues with storing certificates - and I believe even accidentally deleting and re-requesting one is much less of an issue in terms of Let's Encrypt rate-limits, compared to the rate-limits one runs during other failure modes (e.g. Too Many Pending Authorizations).

So I believe in case of a problem we would most likely simply switch to a day-old backup, and study the differences with help of the log file. But any scheme that limits the amount of backups being held per-domain is certainly acceptable for us!

On our systems, I purged all backups from Redis (after harvesting their timestamps to set expiry) with:

EVAL "local keys = redis.call('keys', ARGV[1]) \n for i=1,#keys,5000 do \n redis.call('del', unpack(keys, i, math.min(i+4999, #keys))) \n end \n return keys" 0 *:15*

[bacheson]

I have 800mb of certs clogging a redis instance....I'd love to see the keep_previous_certs setting make it to the next release

[bacheson]

is this going to be merged in? this is becoming a huge problem for us

[GUI]

This is finally part of a release in v0.13.0 that's now published. Thanks!