Autorenew: Not renewing a day before expriation date - SOLVED


#1

How long before the actual expiration date does autorenew renew the cert?

I thought it was 10 days, but can’t find any reference to it. My cert is one away from expiring, and this morning got:

“Certificate not yet due for renewal; no action taken.”

Is this normal?
Is there a way to change that? I’d like to change it to something like 10 days, so if it fails to renew (system is down, internet is down, etc…) it still has 9 more chances before it expires.


#2

It’s 30 days, so if you’re one day from expiring, something went wrong.

What’s the output of openssl x509 -enddate -noout -in /etc/letsencrypt/live/example.com/cert.pem? Did you make any manual modifications to files in /etc/letsencrypt by any chance?


#3

notAfter=Jul 27 12:05:00 2016 GMT


#4

I have two “domains” entry in my cli.ini. Could it be that it is trying to renew one cert but not the other?

This is the command I use in my script:
/usr/bin/letsencrypt certonly --standalone


#5

Hmm. Two thoughts.

Is the local clock wrong on the server? if It thinks this is May 2016 then obviously it won’t realise the certificate is almost expired now.

What are the two certificates for? Do they (or did they in the past) share some names ?


#6

The /usr/bin/letsencrypt certonly --standalone command is what you’re using to renew the certs? In that case, take a look at the renew subcommand. This will renew all certificates that are close to expiring, by looking at the certificates that you already have and re-using the settings you used to get the certificates in the first place.


#7

One is for a mail server the other is for a webserver hosting a bunch of small sites.

I might have used the second cert for the mail server at some point (not 100% sure).


#8

It errors out, I’m wondering if I have something wrong in my cli.ini:

Redirecting to /bin/systemctl start httpd.service
2016-07-26 08:55:15,913:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2016-07-26 08:55:15,928:INFO:certbot.hooks:No renewals attempted, so not running post-hook
Currently, the renew verb is only capable of renewing all installed certificates that are due to be renewed; individual domains cannot be specified with this action. If you would like to renew specific certificates, use the certonly command. The renew verb may provide other options for selecting certificates to renew in the future.

2016-07-26 14:55:15,908:DEBUG:certbot.main:Root logging level set at 20
2016-07-26 14:55:15,913:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2016-07-26 14:55:15,919:DEBUG:certbot.main:certbot version: 0.8.1
2016-07-26 14:55:15,920:DEBUG:certbot.main:Arguments: [’–pre-hook’, ‘/usr/sbin/service httpd stop’, ‘–post-hook’, ‘/usr/sbin/service httpd start’]
2016-07-26 14:55:15,925:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2016-07-26 14:55:15,928:INFO:certbot.hooks:No renewals attempted, so not running post-hook
2016-07-26 14:55:15,934:DEBUG:certbot.main:Exiting abnormally:
Traceback (most recent call last):
File “/usr/bin/certbot”, line 9, in
load_entry_point(‘certbot==0.8.1’, ‘console_scripts’, ‘certbot’)()
File “/usr/lib/python2.7/site-packages/certbot/main.py”, line 744, in main
return config.func(config, plugins)
File “/usr/lib/python2.7/site-packages/certbot/main.py”, line 584, in renew
renewal.renew_all_lineages(config)
File “/usr/lib/python2.7/site-packages/certbot/renewal.py”, line 309, in renew_all_lineages
raise errors.Error("Currently, the renew verb is only capable of "
Error: Currently, the renew verb is only capable of renewing all installed certificates that are due to be renewed; individual domains cannot be specified with this action. If you would like to renew specific certificates, use the certonly command. The renew verb may provide other options for selecting certificates to renew in the future.


#9

Getting rid of the domains in /etc/letsencrypt/cli.ini probably makes sense, as that .ini file will be used for all invocations of the client. If you’d like to keep your configuration in a file (as opposed to command-line arguments) for future certificate requests, you might want to consider creating one .ini file per domain (or rather certificate lineage) and telling the client to use that via -c /path/to/domain.ini explicitly whenever you need it (i.e. not for renew).


#10

Indeed, removing the “domains” lines from cli.ini did it. I followed your suggestion of splitting the domains in their own files.

Thanks!


#11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.