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
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
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