Client auto renewals and failure notifications?


#1

How does the Letsencrypt client’s auto renewal process work exactly ?

  1. What triggers the auto renewal ? a cronjob ? some form of scheduler inbuilt ?
  2. What happens if there’s a client error or failure to auto renew ?
  3. Are their any email notifications to the owner/admin ?
  4. How does the admin/site owner know if auto renewal successfully processed ?
  5. How many days prior to SSL cert expiry date does the auto renewal process begin ? Enough time to work through client issues in auto renewal process ?
  6. If the auto renewal process doesn’t proceed for any reason, is there the option to manually initiate the
    renewal process ? same as manual renewals ?
  7. If any manually done renewals are done one time, would subsequent renewals still be in auto renewal queues?

cheers

George


#2

Hi,

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

  1. The autorenewal runs from a cronjob, which the OS package should install under /etc/cron.daily or perhaps /etc/cron.hourly.
  2. 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.
  3. 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.
  4. We’ll probably also have e-mail notifications if renewal succeeds.
  5. 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.
  6. 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).
  7. 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.


#3

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.


#4

thanks @schoen just the info I need to know

Yes that’s my plan I have setup a dedicated server and domain & subdomains entirely just for testing Letsencrypt however it’s on CentOS and non-standard Nginx - as I want to work on integrating Letsencrypt into my Centmin Mod LEMP web stack. So only way to test right now is manual authentication with a slight change to work with my version of Nginx Manual authenticator - way to automate the ACME Challenge file creation?

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

For email notifications posted a suggestion at https://github.com/letsencrypt/letsencrypt/issues/741 :slight_smile:


#5

Thanks, much appreciated @eva2000!


Split "Issuance and Renwal" into Policy and Technical categories