Cron job successfully ran for two month without problem
Now i am in production, on the first of this month the cron job failed so i tried to run the command manually i got
Failed authorization procedure
Then i modified the command and didn’t include the sub domains an it was successful but the generated certificates got in 0001 folder so it didn’t replace the current certificate
I tried renaming the folders the old ones with 0002 and the new without 000 i restarted Nginx but i got error
Dear sirs , for my setup it is enough to get the main domain certificates i dont need the old sub domain
so pleas help fixing the Failed authorization procedure or replacing the new certificates from folder 0001 so taht they will be active certificates
You shouldn't do that manually. What is the error?.
You don't say what is the client you are using to get your certificates but certbot client has the option --cert-name (since certbot 10.0.0) to issue a cert and replace the old one (to avoid the problem you get about the -000x directory). Anyway, there is no problem if you have a new dir yourdomain-0001, all you need to do is configure your web server to use the new path to the certificate.
To resolve the failed authorization procedure, the first thing you should do is to create the dirs .well-known/acme-challenge/ on your site Document Root. For example, if the document root (the dir that you have configured on your web server) for your domain is /var/www/public_html/yourdomain/ add the dirs to that path so you get /var/www/public_html/yourdomain/.well-known/acme-challenge/.
Once you have the dirs created put a simple test file there:
echo "this is a test" > /var/www/public_html/yourdomain/.well-known/acme-challenge/test
and try to reach it using your browser:
http://yourdomain/.well-known/acme-challenge/test
You should see the text "this is a test", if you get another thing then there is an issue with your conf that should be reviewed. Till you can't see the text, Let's Encrypt couldn't too so you will get the failed authorization message.
Anyway, you said that you were able to issue the cert (no failed authorization error) but then you rename the dirs and now you get this error... are you sure that your web server starts when you renamed the dirs?.
Anyway, you should provide more info about the commands you used, the errors, your web server conf... if you want some help from the community ;).
Should i remove the subdomains form the current active certificate then generate new certificate? will it replace the current one in the root directory?
How can i reconfigure the server to use the new dir 0001 instead ? i use Apache with nginx
In order to avoid making a completely new certificate with -0001, -0002, etc., you need to either
specify all the existing names, plus any new ones (not leaving out or removing any names), or
specify the cert name of the certificate lineage you wish to modify, using --cert-name
The first option is not really applicable because you do, in fact, want to remove some names from an existing cert. This can only be done by specifying a --cert-name.
You can find out the cert names by running certbot certificates.
You might also want to delete any unwanted certificates with certbot delete.
If your letsencrypt-auto version is 10.0.0 or above ( you can check the version with command ./letsencrypt/letsencrypt-auto --version ) you could use the following command to replace your current certificate.
Ok, finaly i got this working using that command, but now when i wanted to update the cron job to only include -d DOMAIN.com -d www.DOMAIN.com, i tried this
i got this error :
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains
I guess that this is normal ? will this remedy it self after few days ?
You should not use that command in any cron job or every time it executes the command, a new cert will be issued and that is not what you want, instead you should use letsencrypt-auto renew. This command will check your cert and if the current cert will expire in less than 30 days it will try to renew it with the same options you used to get it. If your cert is not expiring in less than 30 days it will do nothing.
The error you are receiving is because you issued 20 certs in last 7 days. You should wait a few days to issue again a cert for your domain/subdomain.
Keep in mind that every time your cert is renewed you should restart/reload your web server so the new certificate is used by them. You can automate this restart/reload on your letsencrypt-auto renew command using --pre-hook and --post-hook option. Take a look to the doc.
You don't need to stop nginx, indeed if you do that you won't renew your cert because Let's Encrypt boulder won't be able to reach your domain so in your case, you should run the command daily and just reload nginx using post-hook.
Note: I don't know if the correct way in your system to execute the cron job daily is @daily. Also, keep in mind that letsencrypt-auto should be in the path used by cron, if it isn't you should specify the full path to letsencrypt-auto.
Ok, i will use this command @daily ./letsencrypt/letsencrypt-auto renew --post-hook "service nginx reload"
I will post my result for future reference
thank you
Just one more thing, I don’t know how your cron works but it usually sends a mail, if you don’t want to receive a mail every day you could use the --quiet option.
As I don’t use cron and it would be good for understanding of the community, can you clarify your suggestion above please.
According to certbot docs
How does this stop cron sending emails. I have had a look at a few articles on how to stop sending emails with cron but usually they do something extra to send errors only.
@danb35 is correct, cron send mails if the executed command has an output, in this case the --quiet parameter doesn’t allow to certbot to produce an output if the command has no errors.
By default, cron sends the mail to the owner of the cron job, if the owner is root it will send a mail to root… you can override this using in the cron job the variable MAILTO=whatever@domain.tld and it will send the mail to whatever@domain.tld.
The problem using the certbot --quiet option is that it produces no output… even when it renews the certs. It should be good to have an option like --almost-quiet to inform only on errors and when the certs are renewed, till that option is available you could use this approach to simulate this behavior using --renew-hook option and redirecting its output to the stderr, something like:
17 */6 * * * /path/to/certbot renew --quiet --no-self-upgrade --renew-hook 'echo "\nI have renewed the cert located in ${RENEWED_LINEAGE} and this cert contains the following domains ${RENEWED_DOMAINS}\n\n" >&2' --post-hook "service apache2 reload; service stunnel reload; service dovecot reload"
With the above command you will receive an email only if the command has an error and when your certs have been renewed, not twice everyday that is the schedule of that cron job. The command also will reload several services when the certs are renewed.
If you’re correctly referencing the live/… cert files + you’re using latest certbot-auto (from git) + you’re renewing a cert (rather than generating a new one from scratch), all should work correctly.
Older clients, especially the v0.8.x series seem to sometimes fail incorrectly or they fail + produce incorrect messages, like the inability to write to some directly… when the client is run as root.
Be sure you’re running latest certbot-auto code (v0.14.0 as of today).
v0.14.0 adds locking to only allow a single certbot client to run at one time. This may resolve your problem, if your renewal process is somehow spawning multiple certbot instances.
to inform only on errors and when the certs are renewed, till that option is available you could use this approach to simulate this behavior using