Let op: Tweakers stopt per 2023 met Tweakblogs. In
dit artikel
leggen we uit waarom we hiervoor hebben gekozen.
Let’s Encrypt - En waarom het renewen maar niet werkte…
Even een klein verhaaltje over mijn ervaringen met certbot, het automagische tooltje om Let's Encrypt te installeren op je server. Ik heb best prima ervaringen met certbot. Even uitvoeren, en na een seconde of 10 zijn de SSL certificaten volledig automatisch geinstalleerd op je Apache of Nginx installatie. So far so good...
Omdat je certificaten niet eeuwig geldig zijn, wil je ze af en toe verversen. Dit wil je natuurlijk niet met de hand doen. Dus zoals je in vrijwel elke guide terug zal kunnen vinden, is dat je het certbot renew commando eenvoudig als cronjob in kunt stellen.
Crontab instellen
Dus, ik crontab -e gebruiken om in mijn favoriete editor een regel aan te maken:
Zo. Klaar is kees. Iedere nacht, om 3.15u wordt dit commando uitgevoerd, en zal er heel stilletjes een renewal worden uitgevoerd. Nooit meer naar omkijken dacht ik...
Nope nope nope
Helaas kwamen we er op een zekere dag achter dat de certificaten verliepen. Natuurlijk kwam de klant er net iets eerder achter dan wijzelf en waren alle browsers in rep en roer. Snel inloggen met SSH, en even certbot renew uitvoeren. Hoppa. Gefixt. Alles werkte weer. Maar automatisch via de cronjob vernieuwen, ho maar...
Debuggen
Ok, dan maar even wat langer uitzoeken waarom de certificaten niet automatisch werden ververst. Eerst even checken of de cron-regel juist was. Met https://crontab.guru even gekeken, en dat leek in orde.
Vervolgens gecheckt of de cron-regels uitgevoerd werden. Daarvoor heb ik een regel aangemaakt die elke minuut een bestandje 'aanraakt'. Middels de timestamp is dan snel af te leiden of het werkte. En ja, dat werkte wel.
Logboeken
Next step, logs checken. Eerst maar eens in /var/log/cron kijken:
En voila, hij wordt wel uitgevoerd. Maar hij doet het niet?!
Op internet lees ik dat de output van de cronregels niet worden gelogd, maar standaard aan de uitvoerende gebruiker worden 'gemailt'. In de inbox /var/spool/mail/root van de root gebruiker las ik toen:
Het nginx commando kon niet worden gevonden... Nginx is natuurlijk wel geinstalleerd, en wel hier: /usr/sbin/nginx, dus het zou waarschijnlijk iets met het PATH te maken hebben.
Terug naar de crontab
Toen ik in /etc/crontab keek, de algemene system-wide crontab, stonden daar bovenin de file daar wel het juiste pad!
Ik leerde uiteindelijk dat wanneer je via crontab -e een cronjob insteld, je deze als user instelt. Zelfs al ben je root. Dus crontab -e zal alleen voor de ingelogde gebruiker een cronjob instellen.
Het blijkt dat de user cronjobs worden opgeslagen in de /var/spool/cron/ map. Toen ik uiteindelijk er achter kwam dat wanneer er geen settings worden opgegeven, de user-cronjobs een standaard PATH van /usr/bin:/bin hebben, had ik eindelijk mijn antwoord...
Conclusie
Kortom: Stel je cronjobs in via crontab -e check dan ook even of je gewenste commando - of het commando die daaruit voortvloeit, zoals in een script als certbot - wel vanuit het default PATH bereikt kunnen worden. Zo niet, stel dan het gewenste PATH in bovenaan in je user crontab.
Ps: Ik kwam erachter dat --post-hook "systemctl reload nginx" ook wel handig is, zodat je webserver de nieuwe certificaten ook daadwerkelijk reload
Ps2: Bovengenoemde voorbeelden komen van een CentOS 7 distro.
Omdat je certificaten niet eeuwig geldig zijn, wil je ze af en toe verversen. Dit wil je natuurlijk niet met de hand doen. Dus zoals je in vrijwel elke guide terug zal kunnen vinden, is dat je het certbot renew commando eenvoudig als cronjob in kunt stellen.
Crontab instellen
Dus, ik crontab -e gebruiken om in mijn favoriete editor een regel aan te maken:
15 3 * * * /usr/bin/certbot renew --quiet
Zo. Klaar is kees. Iedere nacht, om 3.15u wordt dit commando uitgevoerd, en zal er heel stilletjes een renewal worden uitgevoerd. Nooit meer naar omkijken dacht ik...
Nope nope nope
Helaas kwamen we er op een zekere dag achter dat de certificaten verliepen. Natuurlijk kwam de klant er net iets eerder achter dan wijzelf en waren alle browsers in rep en roer. Snel inloggen met SSH, en even certbot renew uitvoeren. Hoppa. Gefixt. Alles werkte weer. Maar automatisch via de cronjob vernieuwen, ho maar...
Debuggen
Ok, dan maar even wat langer uitzoeken waarom de certificaten niet automatisch werden ververst. Eerst even checken of de cron-regel juist was. Met https://crontab.guru even gekeken, en dat leek in orde.
Vervolgens gecheckt of de cron-regels uitgevoerd werden. Daarvoor heb ik een regel aangemaakt die elke minuut een bestandje 'aanraakt'. Middels de timestamp is dan snel af te leiden of het werkte. En ja, dat werkte wel.
* * * * * touch /root/crony-to-my-pony
Logboeken
Next step, logs checken. Eerst maar eens in /var/log/cron kijken:
Aug 20 03:01:01 lb1 run-parts(/etc/cron.hourly)[2870]: finished 0anacro Aug 20 03:15:01 lb1 CROND[3008]: (root) CMD (/usr/bin/certbot renew --quiet) Aug 20 03:43:01 lb1 anacron[2868]: Job `cron.daily' startedn
En voila, hij wordt wel uitgevoerd. Maar hij doet het niet?!
Op internet lees ik dat de output van de cronregels niet worden gelogd, maar standaard aan de uitvoerende gebruiker worden 'gemailt'. In de inbox /var/spool/mail/root van de root gebruiker las ik toen:
Attempting to renew cert (domein-van-onze-klant.nl) from /etc/letsencrypt/renewal/domein-van-onze-klant.nl.conf produced an unexpected error: The nginx plugin is not working; there may be problems with your existing configuration
The error was: NoInstallationError("Could not find a usable 'nginx' binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.",). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/domein-van-onze-klant.nl/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s).
Het nginx commando kon niet worden gevonden... Nginx is natuurlijk wel geinstalleerd, en wel hier: /usr/sbin/nginx, dus het zou waarschijnlijk iets met het PATH te maken hebben.
Terug naar de crontab
Toen ik in /etc/crontab keek, de algemene system-wide crontab, stonden daar bovenin de file daar wel het juiste pad!
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
Ik leerde uiteindelijk dat wanneer je via crontab -e een cronjob insteld, je deze als user instelt. Zelfs al ben je root. Dus crontab -e zal alleen voor de ingelogde gebruiker een cronjob instellen.
Het blijkt dat de user cronjobs worden opgeslagen in de /var/spool/cron/ map. Toen ik uiteindelijk er achter kwam dat wanneer er geen settings worden opgegeven, de user-cronjobs een standaard PATH van /usr/bin:/bin hebben, had ik eindelijk mijn antwoord...
Conclusie
Kortom: Stel je cronjobs in via crontab -e check dan ook even of je gewenste commando - of het commando die daaruit voortvloeit, zoals in een script als certbot - wel vanuit het default PATH bereikt kunnen worden. Zo niet, stel dan het gewenste PATH in bovenaan in je user crontab.
PATH=/sbin:/bin:/usr/sbin:/usr/bin 15 3 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"
Ps: Ik kwam erachter dat --post-hook "systemctl reload nginx" ook wel handig is, zodat je webserver de nieuwe certificaten ook daadwerkelijk reload
Ps2: Bovengenoemde voorbeelden komen van een CentOS 7 distro.
Reacties
Thnx voor de uitleg! 
Je krijgt het als het goed is wel een mailtje van Let's Encrypt dat een certificaat dreigt te verlopen . Of had je het e-mailadres van de klant opgegeven?
Goeie blog, thanks 
Let's encrypt mailt jou gewoon dat een certificaat gaat verlopen dus dat je had dit kunnen voorkomen door een bestaand email adres op te geven toen je het voor de eerste keer startte.
Goeie leer voor de volgende keer. Je kan die gegevens trouwens achteraf gewoon aanpassen. Lees even de manual van certbot maar even. Dan krijg je voortaan gewoon een mailtje :-)
Goeie leer voor de volgende keer. Je kan die gegevens trouwens achteraf gewoon aanpassen. Lees even de manual van certbot maar even. Dan krijg je voortaan gewoon een mailtje :-)
Dank voor de tip Xzenor en synoniem. Ga ik doen. Los daarvan ging het mij even om het correct instellen van de renewal. Dan dat stukje had meer te maken met cron dan met certbot.
Leuke how-to, maar waarom elke dag renewen? Zelf renew ik 1x per maand.
Doen we wel eerst even een nginx -t om te testen of je config niet naar de klote is? En frequentie van een dag is wel een beetje absurdPs: Ik kwam erachter dat --post-hook "systemctl reload nginx"
Je zou daarnaast ook gewoon een shell-script kunnen schrijven die certs checkt en dit output naar een Prometheus/Influx/NewRelic/Elastic/whatever zodat je ook daadwerkelijk de errors kan inzien zonder diep graven op een VMmetje.
Nou, dan zal ik dit gewoon maar even gaan lerenItsNotRudy schreef op woensdag 21 augustus 2019 @ 15:37:
[...]
Je zou daarnaast ook gewoon een shell-script kunnen schrijven die certs checkt en dit output naar een Prometheus/Influx/NewRelic/Elastic/whatever zodat je ook daadwerkelijk de errors kan inzien zonder diep graven op een VMmetje.
Wellicht tijd om monitoring te implementeren in je omgeving?Natuurlijk kwam de klant er net iets eerder achter dan wijzelf en waren alle browsers in rep en roer.
openssl x509 -enddate -noout -in certificaat.crtThe Milkman schreef op woensdag 21 augustus 2019 @ 15:40:
[...]
Nou, dan zal ik dit gewoon maar even gaan leren
Ik weet niet op welke schaal je opereert en wat je budget is, maar je zou zoiets uit handen kunnen geven bij een hostingpartij 🙂
Letsencrypt raad zelf aan elke dag het renew script te draaien.WeHoDo schreef op woensdag 21 augustus 2019 @ 14:33:
Leuke how-to, maar waarom elke dag renewen? Zelf renew ik 1x per maand.
Hij renewd alleen certs die daar ook aan toe zijn (volgens mij als ze over minder dan een maand verlopen)
Binnenkort ga ik zelf ook let's encrypt gebruiken voor een site, dus leuk om te lezen waar ik op moet letten. 
Dat hoeft geen eens, wanneer je een klein beetje moeite doet installeer je DirectAdmin op een VPS (of je huurt ergens een pre-installed DirectAdmin VPS) en laat je DirectAdmin gewoon alles omtrent Let's Encrypt afhandelen. Zeker met CustomBuild 2.0 (en de bijbehorende plug-in) is het een beetje 'set and forget'.ItsNotRudy schreef op woensdag 21 augustus 2019 @ 18:20:
[...]
openssl x509 -enddate -noout -in certificaat.crt
Ik weet niet op welke schaal je opereert en wat je budget is, maar je zou zoiets uit handen kunnen geven bij een hostingpartij 🙂
Waarom zou je in hemelsnaam zoiets als DA willen installeren als het niet nodig is? Ja, ik kan een vrachtwagen nemen om naar de bakker om de hoek te gaan. Maar dat is een beetje overkill. DA is ook gewoon overkill voor een eenvoudige webserver.
En zorg er ook voor dat de MAILTO goed staat (of dat mail voor root naar jezelf gaat). En dat de server ook daadwerkelijk kan mailen.
Met cron is het ook gewoon 'set and forget'.Beunhaas91 schreef op donderdag 22 augustus 2019 @ 17:56:
[...]
Dat hoeft geen eens, wanneer je een klein beetje moeite doet installeer je DirectAdmin op een VPS (of je huurt ergens een pre-installed DirectAdmin VPS) en laat je DirectAdmin gewoon alles omtrent Let's Encrypt afhandelen. Zeker met CustomBuild 2.0 (en de bijbehorende plug-in) is het een beetje 'set and forget'.
Alleen moet je dan wel die cron goed instellen.
Wat jij zegt is dat men eerst maar een mega-pakket moet installeren wat alsnog niets gaat doen als je het daarop fout instelt.
Wat gaf het volgende commando bij de initiële installatie?
"sudo certbot renew --dry-run"
"sudo certbot renew --dry-run"
Hoi Harm_H, dat ging wel goed, omdat mijn sessie wel met het juiste PATH werd uitgevoerd. Het feit van de cron-runner met andere PATH-variabelen werkte was het probleem.Harm_H schreef op zaterdag 24 augustus 2019 @ 13:44:
Wat gaf het volgende commando bij de initiële installatie?
"sudo certbot renew --dry-run"
tsjah system cronnetjes hoor je idd in /etc/cron.* te gooien. Een andere tip voor debuggen is de output naar een bestandje schrijven met >>.
Reageren is niet meer mogelijk