My web server is (include version): Domoticz version 4.10430 (beta)
The operating system my web server runs on is (include version): Raspbian Stretch (Linux 4.14.79-v7+)
I can login to a root shell on my machine (yes or no, or I don’t know): yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.31.0
Hi,
Letsecrypt send me a “Let’s Encrypt certificate expiration notice” e-mail to renew my certificate.
I created the certificate a few months ago using the “–preferred-challenges dns” option because i did not want to open port 80 on my main router.
The command I used was: /etc/letsencrypt/letsencrypt-auto certonly --manual --preferred-challenges dns --manual-auth-hook /home/pi/duckdns/auth.sh --manual-cleanup-hook /home/pi/duckdns/cleanup.sh
How do I automatically renew (let’s say every 8 weeks) the certificate using the --preferred-challenges dns option?
You were right!
However when I run/etc/letsencrypt/letsencrypt-auto renew --dry-run
I get the following error:
Encountered exception during recovery:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/error_handler.py", line 108, in _call_registered
self.funcs[-1]()
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py", line 323, in _cleanup_challenges
self.auth.cleanup(achalls)
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/plugins/manual.py", line 242, in cleanup
env = self.env.pop(achall)
KeyError: KeyAuthorizationAnnotatedChallenge(challb=ChallengeBody(chall=DNS01(token='\x9b+\xe3\x1d\x0c~7\xd9\x08\x9ap\x1f\x03\x9d\x86%\xe8\xc73-\xac\xf7fu\x1ev\xc9dJ\xde|8'), status=Status(pending), uri=u'https://acme-staging-v02.api.letsencrypt.org/acme/challenge/fp47MV2DqRJJmR0MTkkYAA0M8F_9AJWORUPVLUjOsJE/254604685', validated=None, _url=u'https://acme-staging-v02.api.letsencrypt.org/acme/challenge/fp47MV2DqRJJmR0MTkkYAA0M8F_9AJWORUPVLUjOsJE/254604685', error=None), domain=u'gschmidt.duckdns.org', account_key=JWKRSA(key=<ComparableRSAKey(<cryptography.hazmat.backends.openssl.rsa._RSAPrivateKey object at 0x76718d30>)>))
Attempting to renew cert (gschmidt.duckdns.org) from /etc/letsencrypt/renewal/gschmidt.duckdns.org.conf produced an unexpected error: Missing command line flag or config entry for this setting:
NOTE: The IP of this machine will be publicly logged as having requested this certificate. If you're running certbot in manual mode on a machine that is not your server, please ensure you're okay with that.
Are you OK with your IP being logged?
(You can set this with the --manual-public-ip-logging-ok flag). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/gschmidt.duckdns.org/fullchain.pem (failure)
Yeah strange because my manual certonly command did work: /etc/letsencrypt/letsencrypt-auto certonly --manual --preferred-challenges dns --manual-auth-hook /home/pi/duckdns/auth.sh --manual-cleanup-hook /home/pi/duckdns/cleanup.sh
Here is the log: https://dpaste.de/3FjU
You also can see I updated manually because the certbot version is updated to: 0.31.0
Ah, I think that log might make more sense. The way I read it, the earlier issue (MissingCommandlineFlag) may be causing the latter error (KeyError: KeyAuthorizationAnnotatedChallenge).
Does a dry run with --manual-public-ip-logging-ok make it succeed?
Apart from the question of whether this will work on other ways, I find this script kind of odd because it doesn't check whether the certificate was renewed or not before replacing the domoticz certificate and restarting the service!
In Certbot's current design, it would make more sense to set this script as a --deploy-hook (although without the /etc/letsencrypt/letsencrypt-auto renew --manual-public-ip-logging-ok line at the beginning), and then use the original cron job.
The difference is mostly about an attempt to add a random delay to each renewal attempt, something which we've asked people to do in order to reduce load spikes at the CA, but which is now also handled in Certbot itself. Also, the cron job that @_az mentioned runs twice a day, rather than once a week.
Yes, that's right. This has the advantage that the deploy-hook-script will only run when the certificate has actually been renewed, as opposed to running once a week. Also, you can then check for renewals twice a day (nothing will happen if the renewals aren't due yet).
(I don't remember whether --manual-public-ip-logging-ok has to be specified during the renewal process, or just once.)
I see what you mean…a cleaner solution…however does it actually matter that the certificate was renewed or not? The script copies either an existing certificate or a new one to the domoticz domain.
bye the way I ran the /etc/letsencrypt/letsencrypt-auto renew --dry-run again without the --manual-public-ip-logging-ok parameter, and it got the same error as i mentioned in a previous reply…does this error has to do with the fact that i use in my conf --preferred-challenges dns to avoid exposing port 80 on my router?
I think this will work. Note that specifying the hook in the renew command isn’t a good thing if you have Certbot managing multiple certificates on the same system (since the deploy-hook script would run for the renewal of any certificate).
These commands might not have the exact effect that you expect. The >> is evaluated by the shell and runs with the privileges of the user running the script, not with sudo privileges. (However, in this case the script might already be run by root!)
Correct, that’s why I was surprised when I received an e-mail from letsencrypt to renew the certificate…lazy as I am, I was trying to find a script for automatic renewal and ended up here
