Please fill out the fields below so we can help you better.
My domain is: hopefully not relevant. If it turns out it’s needed, I’ll provide it (yes, I’m paranoid, I know)
I ran this command:
certbot-auto renew --pre-hook “service apache2 stop” --post-hook “service apache2 start” --dry-run
It produced this output:
Requesting root privileges to run certbot...
/home/username/.local/share/letsencrypt/bin/letsencrypt renew --pre-hook service apache2 stop --post-hook service apache2 start --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/subdomain.domainname.conf
-------------------------------------------------------------------------------
Running pre-hook command: service apache2 stop
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for subdomain.domain
Waiting for verification...
Cleaning up challenges
Generating key (4096 bits): /etc/letsencrypt/keys/0011_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0011_csr-certbot.pem
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/subdomain.domain/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
My operating system is (include version):
raspbian
My web server is (include version):
apache2
My hosting provider, if applicable, is:
n/a
I can login to a root shell on my machine (yes or no, or I don’t know):
yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no
Now for my problem: I’m glad I came across certbot-auto. For once in my life I managed to have an SSL secure server. But: Everytime certbot-auto renew runs, the certificate get’s renewed. For one, that’s not how I understand it is supposed to work (it should check the existing certificates expiry date and only actually renew at 30 days or under, right?) and b) it’s a bit annoying to have to accept a new certificate twice a week.
I read and read, but I can’t find what’s wrong with my setup. Can someone help me out here?
Well, if that’s the exact command you ran… --dry-run makes it test what would happen if the cert was close to expiry, but doesn’t actually renew it even if it really is. You should remove that flag from the actual renewal command that you run from cron.
What do you need to "accept"? Renewals should be completely transparant to the end-user.
And I would suggest removing the --quiet flag for a few times to check the renewal output of cron. Cron should mail its output to the server maintainer, if appropriate set up of course.
I removed --quiet, but there is no mail transport installed on the machine, so I’m not likely to get an email. Would adding
>> /var/log/letsencrypt/LE.log
do the trick?
What I meant was, every time the certificate renews (which to me means: there is a new one), Thunderbird (or, Lightning and Card Book respectively), DavDroid, Nextcloud all complain about the certificate and I have to accept permanent exceptions. That works fine, untii certbot runs again a few days later, and the same thing happens.
That’s, by the way, how I know that the cron job ran.
You shouldn’t have to make an exception for Let’s Encrypt certificates. Otherwise a self-signed certificate would suffice and there’s no need for LE Sounds like a configuration issue, do you use fullchain.pem or chain.pem anywhere or just cert.pem?
And of course the certbot log file would give more useful information, yes
If it wasn’t obvious yet: I don’t truly know what I’m doing, so everything is possible
I initially installed the certificate using the --apache flag, that’s all I remember, so I honestly can’t say what’s being used. I’ll post the exact popup messages I get from Thunderbird & co after the next run of the cronjob, as well as the log.
Ok, so today I ran: certbot-auto renew --pre-hook "service apache2 stop" --post-hook "service apache2 start" > /home/username/logs/certbot.log
and got this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log Running pre-hook command: service apache2 stop Renewing an existing certificate Performing the following challenges: tls-sni-01 challenge for domainname Waiting for verification... Cleaning up challenges Generating key (4096 bits): /etc/letsencrypt/keys/0014_key-certbot.pem Creating CSR: /etc/letsencrypt/csr/0014_csr-certbot.pem Running post-hook command: service apache2 start
As soon as this ran, I got a pop-up from my NextCloud-client.
Cannot connect securely to 192.xxx.xxx.xxx:
The host name did not match any of the valid hosts for this certificate
with Certificate domainname
Organization:
Unit:
Country:
Fingerprint (MD5): XXX
Fingerprint (SHA1): XXX
I can tick "Trust this certificate anyway" and that will make this window disappear.
The log created reads:
Requesting root privileges to run certbot...
/home/username/.local/share/letsencrypt/bin/letsencrypt renew --pre-hook service apache2 stop --post-hook service apache2 start
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/domainname
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/domainname/fullchain.pem
-------------------------------------------------------------------------------
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/domainname/fullchain.pem (success)
I think that error means the nextcloud client is configured to connect directly to the server’s IP address rather than the domain which the cert is valid for.
That's actually true. Since the NC-client is running on a local machine, I figured I go the direct route. Ok, so let's say I fix that in NC and Thunderbird and whereever else.... the initial problem, that every run of certbot-auto creates a new certificate, is not affected by this.You can even see today's date in the popup from NC.. how do I fix that?
I don’t know if that’s indeed a certbot-auto bug, because I don’t use that. It seems so and that should be fixed.
But as a workaround, I can suggest you to create a script that checks the certificate lifetime using openssl and only starts certbot afterwards.
Here is what you could use:
#!/bin/bash
openssl x509 -checkend 950400 -in /etc/letsencrypt/live/your.tld/fullchain.pem > /dev/null
if [ $? != 0 ]; then
# certificate will be invalid in 11 days, renew it
certbot-auto renew --pre-hook "service apache2 stop" --post-hook "service apache2 start" > /home/username/logs/certbot.log
fi
Save this as update_cert.sh, make it executable and run that in cron.
It checks if the given certificate is still valid in 11 days and runs certbot-auto only if it isn’t.
Yeah, that seems to work, thanks. But, I can hardly be the only one suffering from this, can I? Or has everyone else correctly configured their applications to point at the URL and thusly never noticed the issue?
Sounds like a configuration issue, do you use 