I currently have 9 certs for 5 different domains on my server (one by itself, and 4 pairs rsa+ecc).
Of course, they tend to all renew at the same time. Should I stagger them?
How can I randomize their renewals with acme.sh, and when should I renew?
Should I go for 30-20 days randomly before expiration and let them get out of sync organically?
I'm pretty sure Let's Encrypt doesn't mind 9 renewals at the same time when you realise LE issues 2,5 million certs per day (~29 certs every second on average).
Just make sure you don't renew all 9 renewals at 00:00 or any other exact hour.
Also, I'm not sure how acme.sh works, but Certbot renews all certificates sequentially.
yeah, but I still want to avoid renewing the rsa and ecc ones in the pair at the same time. it seems... a bit pointless.
I don't follow. How is that pointless? And also, does acme.sh renew certs in parallel?
No, but it will renew them in the same run, and I wanted some overlap between two certs for the same domain, but not that much
root@Quake:~# acme.sh --list
Main_Domain KeyLength SAN_Domains CA Created Renew
lampone.qualcuno.xyz "4096" no LetsEncrypt.org Wed 26 Jan 2022 11:22:09 PM UTC Sun 27 Mar 2022 11:22:09 PM UTC
lampone.qualcuno.xyz "ec-256" no LetsEncrypt.org Wed 26 Jan 2022 11:22:14 PM UTC Sun 27 Mar 2022 11:22:14 PM UTC
mail.qualcuno.xyz "2048" no LetsEncrypt.org Sun 23 Jan 2022 11:22:08 PM UTC Thu 24 Mar 2022 11:22:08 PM UTC
nc.qualcuno.xyz "4096" no LetsEncrypt.org Wed 26 Jan 2022 11:22:22 PM UTC Sun 27 Mar 2022 11:22:22 PM UTC
nc.qualcuno.xyz "ec-256" no LetsEncrypt.org Wed 26 Jan 2022 11:22:26 PM UTC Sun 27 Mar 2022 11:22:26 PM UTC
quake.qualcuno.xyz "4096" no LetsEncrypt.org Wed 26 Jan 2022 11:22:34 PM UTC Sun 27 Mar 2022 11:22:34 PM UTC
quake.qualcuno.xyz "ec-256" no LetsEncrypt.org Wed 26 Jan 2022 11:22:38 PM UTC Sun 27 Mar 2022 11:22:38 PM UTC
wallabag.qualcuno.xyz "" no LetsEncrypt.org Wed 12 Jan 2022 01:26:59 PM UTC Sun 13 Mar 2022 01:26:59 PM UTC
wallabag.qualcuno.xyz "ec-256" no LetsEncrypt.org Wed 26 Jan 2022 09:29:20 PM UTC Sun 27 Mar 2022 09:29:20 PM UTC
root@Quake:~#
The seems pointless to me when you renew 3-4 weeks before expiry.
Renewal emails start at 20 days 
I would.
I would avoid randomizing anything - keep them on a set schedule.
Simply "start" them 30-45 days apart.
[that may require some early renewals to accomplish]
I think randomizing 0 to 60 minutes in the hour is a good idea to lessen the load around the whole hour on the LE systems.
That is already built into the ACME client - OR is it?
I'm talking about randomizing the renewal date [not the hour within that date].
Recent Certbots: yes. Acme.sh? Wouldn't count on it personally.. Maybe, maybe not.
You're right, they don't include any random wait in the cron job:
25 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null
I set mine to 25 mins after midnight [timezone EST] and hopefully that doesn't find too much load - LOL
Seems like a missed opportunity/oversight.
Certbot used a randomiser in the cronjob earlier too, but recent versions have the randomisation build into Certbot itself.
When renewing from something non-interactively (i.e.: cron/systemd timer), it'll just pause a random amount of minutes.
If you look at the code of acme/sh it does have multiple entries for "rand" or "random" et cetera. It seems it adds a randomised time for the Windows timer and its cronjob when acme.sh is instructed to add them.
Anywho, I think the topic is more about:
Being that he has two certs for the same FQDN, should they both expire/renew at the same time?
I think that is also a missed opportunity for some easily added "redundancy".
But it really depends on what any given browser will do when presented with two certs.
OR better yet, when presented with two certs and one has expired!
I wouldn't care less. Let's Encrypt advices to renew after 2/3rds of the valid time.. You're left with 30 days of finding out what went wrong. That's a lot of time. Sure, you can offset both certificates an X amount of time (30 days? 45 days?), but why bother..
Real redundancy would come from issuing certs from LE and having a different CA as backup.
Browsers don't get presented with two certs: the certificate chosen is decided upon the agreed cipher suite: RSA cert for a RSA cipher suite or ECDSA cert for ECDSA cipher suite.
Although one can also think the other way around: the cert determines the chosen cipher suite. But that's just tométo/tomàto: a server wouldn't agree upon an ECDSA cipher suite if it didn't have an ECDSA cert configured. A smart webserver wouldn't choose a cipher suite corresponding to an expired certificate. I'm not sure if webservers are that smart tho 
I agree that using two CAs is more redundancy - but two certs from the same CA isn't fake redundancy.
And there is nothing to stop one from doing both: Stagger the renewals 30 days and using two CAs.
Really real redundancy - LOL
But that still leaves the big white elephant in the room...
What will browsers do when they encounter an expired cert [but another perfectly good one is available]?
What will web servers do when they have access to two certs and one of them is expired?
Are there are SMART things out there (besides SmartPhones - that aren't that smart at all) ? ? ?
If a browser encounters an expired (leaf) cert, it will complain loudly, because it won't know anything about the other one--the browser isn't given both certs, it's only given one.
Again, that seems pointless when certs are renewed 3-4 weeks before expiry.
There already exists:
This sounds like overengineering and premature optimization, and is far more likely to create problems than solve any.
Set it and forget it.
[just set them 30 days apart - one time only]