First, using the renew command fails in various ways, which is unacceptable when 1000s of certs require renewing, as renew increments all cert file numbers each renewal, so if renew is used, each host/domain Apache config must be modified to match incremented file numbers. Ugly for 1000s of certs.
You’d think, issuing the certonly command again would be sufficient. Nope. This results in an interactive prompt…
What would you like to do?
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
This is unacceptable too. Imagine typing “2” for 1000s of hosts + domains. Ugly…
Using --non-interactive with certonly is badly broken also. This results in a NOP + incorrect message…
Certificate not yet due for renewal; no action taken.
What seems to work is a brute force approach, as follows.
Rifle through all certs + find the ones about to expire. I suggest using a 30 day window to reduce
all the masses of email you’ll get about expiring certs. This email seems to start around day 20-30.
Once located, for each host/domain, delete all traces of /etc/letsencrypt files associated with host/domain.
If error, restore all /etc/letsencrypt files + notify interested parties manual intervention is required for this host/domain.
All files must be restored, else Apache will fail to start during restarts, as happens nightly with logrotate.
Do service apache reload (or your distro’s equivalent).
If error, restore all /etc/letsencrypt files + notify interested parties manual intervention is required for this host/domain.
Test site link with curl -I -L $URL.
If error, restore all /etc/letsencrypt files + notify interested parties manual intervention is required for this host/domain.
All this is ridiculous overkill, which could be fixed by fixing letsencrypt-auto to work sensibly, meaning if certonly is issued against existing cert, then allow --renew-replace flag or some other flag to auto answer “2” (renew + replace cert).
That's probably a small misunderstanding of how the client stores the certificates/keys. The client keeps an internal, "behind the scenes" directory in /etc/letsencrypt/archive/example.com for all certificates and keys. There's also a second directory, /etc/letsencrypt/live/example.com, which contains a number of symlinks that always point to the latest file in /archive. This is where you should point your web server software at, and the client will manage the rest for you.
Not 100% sure I follow. If you want to force renewal, you can use --force-renewal. Usually, you just want --keep-until-expiring and the client won't touch any certificates unless they're close to expiring. That is, if you don't want to use the renew subcommand. It sounds like the main issue with renew was the structure with /archive, so I'm guessing with the knowledge of /live that would probably work for you anyway.
Cert symlinks seem to be fixed now, so file enumerations (like cert1, cert2, etc) only pollute the archive directory, so live directory is always correct now, at least as of V 5.0 of letsencrypt.
You can use ./letsencrypt-auto --help all to get all CLI options.
I’d still recommend using renew instead. --force-renewal will always renew your certificates, even if they’re not anywhere close to expiring. renew or --keep-until-expiring will handle that logic for you.
