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…

Door The Milkman op dinsdag 20 augustus 2019 12:30 - Reacties (19)
Categorie: -, Views: 5.327

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:
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


Door Tweakers user AW_Bos, dinsdag 20 augustus 2019 12:33

Thnx voor de uitleg! :)

Door Tweakers user synoniem, dinsdag 20 augustus 2019 19:08

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?

Door Tweakers user SpoekGTi, dinsdag 20 augustus 2019 21:37

Goeie blog, thanks :)

Door Xzenor, woensdag 21 augustus 2019 09:15

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 :-)

Door Tweakers user The Milkman, woensdag 21 augustus 2019 09:16

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.

Door Tweakers user WeHoDo, woensdag 21 augustus 2019 14:33

Leuke how-to, maar waarom elke dag renewen? Zelf renew ik 1x per maand.

Door Tweakers user ItsNotRudy, woensdag 21 augustus 2019 15:37

Ps: Ik kwam erachter dat --post-hook "systemctl reload nginx"
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 absurd :+ Je kunt ook klappen krijgen van LetsEncrypt als je teveel, te vaak gaat opvragen.

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.

Door Tweakers user The Milkman, woensdag 21 augustus 2019 15:40

ItsNotRudy 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.
Nou, dan zal ik dit gewoon maar even gaan leren :)

Door Tweakers user iTeV, woensdag 21 augustus 2019 17:41

Natuurlijk kwam de klant er net iets eerder achter dan wijzelf en waren alle browsers in rep en roer.
Wellicht tijd om monitoring te implementeren in je omgeving? :)

Door Tweakers user ItsNotRudy, woensdag 21 augustus 2019 18:20

The Milkman schreef op woensdag 21 augustus 2019 @ 15:40:
[...]


Nou, dan zal ik dit gewoon maar even gaan leren :)
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 🙂

Door Tweakers user SA007, woensdag 21 augustus 2019 20:59

WeHoDo schreef op woensdag 21 augustus 2019 @ 14:33:
Leuke how-to, maar waarom elke dag renewen? Zelf renew ik 1x per maand.
Letsencrypt raad zelf aan elke dag het renew script te draaien.

Hij renewd alleen certs die daar ook aan toe zijn (volgens mij als ze over minder dan een maand verlopen)

Door Tweakers user musiman, donderdag 22 augustus 2019 14:07

Binnenkort ga ik zelf ook let's encrypt gebruiken voor een site, dus leuk om te lezen waar ik op moet letten. :)

Door Tweakers user Beunhaas91, donderdag 22 augustus 2019 17:56

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 🙂
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'. 8-)

Door Tweakers user Blokker_1999, donderdag 22 augustus 2019 20:19

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.

Door Tweakers user Kees, vrijdag 23 augustus 2019 08:24

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.

Door Tweakers user Gomez12, vrijdag 23 augustus 2019 13:51

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'. 8-)
Met cron is het ook gewoon '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.

Door Tweakers user Harm_H, zaterdag 24 augustus 2019 13:44

Wat gaf het volgende commando bij de initiële installatie?

"sudo certbot renew --dry-run"

Door Tweakers user The Milkman, zaterdag 24 augustus 2019 19:17

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"
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.

Door Tweakers user k1n9_n01z3, maandag 26 augustus 2019 12:48

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