Problem with Certificate Auto Renew


I had follow this tutorial: to install letsencrypt on my server and ssl was installed perfectly but, the problem is that cron job to renew certificate is not working correctly since I issued certificate May 8 and it expires on August 8 and it should renew 30 days before expiration and is not doing it so, I check command “cat /etc/letsencrypt/renewal/” to see renewal configuration and I am getting error “No such file or folder” so, can you let me know how to fix this so, cronjob works correctly since, I had done this command: “0 1 1 */2 * cd /usr/local/letsencrypt && ./letsencrypt-auto certonly --apache --renew-by-default --apache -d domain.tld >> /var/log/domain.tld-renew.log 2>&1” and I dont get why is not working.

Thanks again everyone!


Hi @codeman1234,

Ugh, that tutorial has a number of problems!

The approach that the tutorial’s author took to renewal is not what we recommend. That crontab entry runs (only) at 1:00 a.m. on the 1st day of even-numbered months and tries to force a renewal at that time regardless of the age of the certificate. (That’s what’s meant by 0 1 1 */2 *, and also by --renew-by-default, which is an obsolete name for the option now called --force-renewal.)

According to this tutorial’s design, your renewal will be attempted only on August 1, because that is the first day of the next even-numbered month. There is actually nothing in the tutorial’s advice that ever checks the age of the certificate.

We don’t prefer this approach because if the renewal fails for some reason, you’ll have very little opportunity to notice and correct the problem. Indeed, there is some indication that it might already have failed since it should also have run on June 1 and performed a renewal at that time (if it was working). If it did run and fail then, which you might be able to confirm from logs in /var/log/letsencrypt, it might also fail again on August 1.

The documented and recommended way to perform renewals is to run certbot-auto renew (e.g. cd /usr/local/letsencrypt && ./certbot-auto renew). This does generally need to run as root. We recommend running this command twice per day. Unlike the certonly --renew-by-default form, it does look at the age of each certificate, and only attempt to renew those that are less than 30 days from expiry.

If you want to renew your certificate right now, you can try the certbot-auto renew form on the command line, and then you can see what’s wrong, if anything.

The renewal configuration file name does not necessarily match the name of a particular domain name if there are multiple domain names that the certificate covers. You can see which ones exist by running ls /etc/letsencrypt/renewal or more detailed summaries of each certificate that you have by running certbot-auto certificates.

Hello @schoen,

Can you tell me the precise commands for me to run for cronjob to do this automatically my server uses Apache + Ubuntu Server

Thanks again!

I am asking since you say the procedure on tutorial is wrong, so, I can setup correctly, thanks!

An adapted example form to run once per day at 1:26 a.m. would be

26 1 * * * cd /usr/local/letsencrypt && ./certbot-auto renew -q

It would be good for you to run this command yourself once from the command line to make sure that the renew currently works. Once you’ve seen it work (since, as you pointed out, your certificate is already due to be renewed), you can then put it in root’s crontab and be relatively confident that it will work automatically in the future.

Hello schoen,

Thanks a lot for helping me out!

So, just to confirm!

I run command: “sudo crontab -e”

then I remove with editor this command “0 1 1 */2 * cd /usr/local/letsencrypt && ./letsencrypt-auto certonly --apache --renew-by-default --apache -d domain.tld >> /var/log/domain.tld-renew.log 2>&1”

and replace it with “26 1 * * * cd /usr/local/letsencrypt && ./certbot-auto renew -q”

Is that correct?

Thanks again!

That’s correct, but you should also first try to run cd /usr/local/letsencrypt && ./certbot-auto renew yourself to see if there is a problem that caused a previously-attempted renewal to fail on June 1.

Ok perfect, let me check and I let you know what happens.


Hello @schoen

it seems I added to many subdomains on certificate and because of that I am getting the error bellow

Attempting to renew cert from /etc/letsencrypt/renewal/ produced an unexpected error: Failed authorization procedure. (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 406481b42f2d9b4e1a206767bb517594.032cf5b714d7bcd830a3587d7fcb63ac.acme.invalid from Received 2 certificate(s), first certificate had names “*, *,,”. Skipping.

What is the command to get this 2 subdomains deleted since it seem they are giving the error.

Thanks again!

This error means that when the certificate authority connects to your server on port 443, it doesn’t find an Apache instance that was configured by Certbot to perform the renewal, but rather something else. There are many things that can cause this problem, like running Certbot on a machine other than the web server for that domain name, or being behind a CDN or proxy.

I don’t think it makes sense to say that this problem is a result of adding too many subdomains on a single certificate. You’re allowed to have up to 100 subdomains on a certificate and many sites get that to work just fine.

However, this error could be caused if you added a subdomain that was previously hosted by an Apache virtual host on your web server but that is no longer hosted that way.

To remove names, you can prepare a list of all of the names that you want to be covered and then run

./certbot-auto certonly -a apache --cert-name -d one-name -d another-name -d third-name

and so on for all of the domain names that you want to be covered and none of the names that you don’t want to be covered.

Hello @schoen

I tried your command and I get this output:

bash: ./certbot-auto: No such file or directory

What do I do?


Sorry, I was assuming that you would first cd to the directory where certbot-auto is installed, like you had to do other times.

Hello @schoen

My bad! Sorry, you are completely right I forgot doing cd command. I have done it and it seems certificate got renew with, and

It has been updated correctly, now to fix error what should I do since I tried to run again command " ./certbot-auto renew" and I get this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/

Cert not yet due for renewal

Processing /etc/letsencrypt/renewal/

Cert not yet due for renewal

The following certs are not due for renewal yet:
/etc/letsencrypt/live/ (skipped)
/etc/letsencrypt/live/ (skipped)
No renewals were attempted.

So, I am not sure if error remains now since I removed the suddomain “media.mysite” which was causing the error, what should I do?


You could run ./certbot-auto certificates to see what domain name coverage you currently have in those two certificates and whether it is right.

“Cert not yet due for renewal” isn’t exactly an error condition because it just means that your certificate is not yet due for renewal. :slight_smile:

If you want to test whether the renewal process is going to work in the future, you can force renewal (even though it’s still “too early”) with ./certbot-auto renew --force-renewal. Before doing that, you should check


to make sure that you’re not going to run into the certificates per registered domain or duplicate certificate rate limits when performing the test renewal. If you would, then maybe wait a few days before trying this experiment.

Hello @schoen

Ok perfect, I will wait a few days and I will get back to you, will be back in 3 days or so, thanks again schoen, your support is amazing.

Sorry to post off-topic, but why attempt certificate renewal twice a day? When I first started using Let’s Encrypt, the recommendation was once a day (and I thought that was unnecessary!)

I’ve got a cron job attempting renewal once a week. That means I receive one email a week (saying no renewal needed, renewal completed, or providing the output of any error). That way I’m not flooded with useless noise in my root inbox, and I still have almost a month to fix any issues that arise.

So far the only issues I’ve had have been due to Certbot dependencies being out of date, and they’re rare and quickly fixed.

What is the reasoning behind attempting renewal twice a day?

(Oh, and good luck @codeman1234! Stick with it, it’s a really nice feeling to get those little epiphanies as these problems are solved :wink: )

1 Like

why not start a new topic?

Because this is the first time I’ve ever heard the “twice a day” mentioned, and it was mentioned in this topic.

Also, if the reasoning is given in this thread, it might flesh-out codeman’s understanding of why schoen is telling him to update cron the way he is, and further reinforce why the initial guide codeman followed was wrong.

1 Like

Hi @DarkSteve,

The reason for once a day is to find out sooner if there’s a problem, and also to spread out renewals for sites with a medium number of certificates so that they don’t all occur on the same day (potentially creating rate limit problems). Sites with a very large number of certificates may need to request an exemption or else plan more carefully exactly when each certificate should be reviewed.

The reason for twice a day is a future Certbot (and maybe other clients) feature to try to check whether a certificate has been revoked and use that as a separate reason for renewal. @pde has speculated that there may be means of reducing or eliminating downtime in this case. However, this feature does not exist yet and it will probably benefit a relatively small user population. But the twice a day suggestion was inspired by the idea of responding rapidly to revocations, if possible, with reissuance.

Thanks for asking!

That’s actually so obvious I’m almost embarrassed I asked!

I have a single SAN certificate containing three domains. That’s it. I forgot not everybody has a small number of domains through Let’s Encrypt, and I forgot you need to think about maintaining your issuance back-end rather than the needs of each individual user.

That’s interesting. I doubt that revoking will apply to me (I’m securing a personal mail and Nextcloud server, not part of a business), but again I can see how I’m thinking solely about my own situation. You need to recommend the best option for the most people.

Careful, I’m a bit on the autistic spectrum, so don’t encourage me :wink: