We’re still working on some of these things and you’re welcome to try it out or give us feedback. Right now my answers are
The autorenewal runs from a cronjob, which the OS package should install under /etc/cron.daily or perhaps /etc/cron.hourly.
If an autorenewal fails, it will be tried again the next time (the next day or the next hour). There should also be an e-mail notification if possible.
Yes, there are e-mail notifications but it requires having a mail submission agent installed on the machine where the client is running. This might not work on some machines and we’re not sure whether there’s a good alternative for those machines.
We’ll probably also have e-mail notifications if renewal succeeds.
This could change, but right now we have renewal starting at 30 days before expiry, and deployment (installing the new cert by updating the symlinks) at 20 days before expiry. The sysadmin can change this default on a systemwide basis or on a cert-by-cert basis.
It should be possible to run the renewal manually. We do need to figure out more about the UI for this. One approach is just to run the client again and request the same names with the same key – following a patch that I’m working on this week, that should trigger basically the same code as the renewer (but you can see any errors displayed to you from the client).
It’s not totally clear what counts as a “manual renewal”. If you used the renewer script or the client but ran them from the command line instead of cron, then yes. If you used the manual mode of the client, then it depends on what you did with the resulting cert and I’m not sure what the best answer would be (currently, probably yes if your original cert was obtained via something other than manual or standalone mode, and no if your original cert was obtained via manual or standalone mode).
As I said, we can use some help and advice with this, so you’re welcome to try it out if you have a machine and domain that can take a test cert and then see how it works (and whether you think it ought to work differently). There are still some changes coming down the pipeline that are described in GitHub issues flagged with “milestone: renewal”.
Right now the “renewal” mechanism is implemented under the hood by getting a new cert for the same names and same key, and then installing that into an appropriate directory under /etc/letsencrypt where it will be recognized as a successor to the previous cert. “Deployment” means updating the symlink so that the symlink points to the new one, and also restarting the web server (if any) so that it notices the change. These are currently implemented as separate steps, for example because a sysadmin might want to control when the server is restarted, or might want to inspect the new cert to make sure it’s OK before it goes live.
Also, deployment is only triggered if the renewal script notices that there is a newer cert installed than the one that the symlink currently points to. So the deployment at 20 days (or later) only happens provided that a renewal event has previously succeeded.
So alot of my suggestions would be from a CentOS non-nginx standard install perspective - which I hope my feedback and suggestions can help improve how that works with Letsencrypt client. Unfortunately, I'm no python programmer so it's basically will be feedback from an end user perspective