Is there a discrepancy, or are the numbers for different things?
renew command will take a look at all active certificates and renew those who are close to expiring - which is currently defined as 30 days before the expiration date. If your certificates aren’t due for renewal yet, the client won’t renew them.
The reason why a daily cronjob is recommended is in order to avoid issues caused by service downtime on Let’s Encrypt’s end, or any issues your server might have. If you, for example, run the cronjob just once every month or every two months, and the service just happens to be down during those times, you’ll end up with an expired certificate eventually. By doing it daily instead, Let’s Encrypt would have to be down for 30 consecutive days for that to happen, which is rather unlikely.
Thanks @pfg, now it makes sense. :]
Also, renewing doesn’t count towards your limit. (Or does it, pfg? I know some people force a renewal for whatever reason.)
To put it a little more precisely: You can renew a certificate even if you have already hit the “certificates per registered domain” limit, but renewals do count against that limit.
Renewal in this context is defined as issuing a certificate with the exact set of names you have issued before.
So, it counts towards the limit, but the system lets the renewal happen, but only prevents from creating certs for new domains that weren’t being renewed?
Yep, that’s correct.
I requested a new certificate yesterday evening and installed a cronjob. From the logs it didn’t skip renewing the certificate.
So I ran the renew command again manually and it renewed it again. Checked the nginx access logs and the acme challenge did take place.
Did I manage to hit a bug in the renew command?
EDIT: Oh, never mind. I had renew-by-default enabled in my cli.ini