Cron-Job für die Verschlüsselung der Erneuerung


93

Ist dies die richtige Methode, um cron für die Erneuerung des Let's Encrypt-Zertifikats in Apache2 festzulegen? Ich benutze Ubuntu 16.04.

@monthly letsencrypt renew && service apache2 reload

6
Wie eine der folgenden Antworten angibt, erstellt certbot v0.19.0 (und möglicherweise einige frühere) bereits einen crontab-Eintrag @/etc/cron.d/certbot
xgMz

Außerdem lädt das certbot apache-Plugin mit der tls-sni-Überprüfung Apache im Rahmen des Überprüfungsverfahrens neu, nachdem das neue Zertifikat abgerufen wurde.
xgMz

Nachfolgend finden Sie eine Antwort, die für Neuinstallationen (ab JAN 2019) sehr wichtig ist. Certbot fügt automatisch den System-Timer und den Zeitplan für Cron-Jobs hinzu, sodass Sie das Cron-Setup nicht benötigen.
Cory Robinson

Antworten:


145

Monatlich ist nicht häufig genug. Dieses Skript sollte mindestens wöchentlich und vorzugsweise täglich ausgeführt werden. Denken Sie daran, dass Zertifikate erst erneuert werden, wenn sie kurz vor dem Ablauf stehen, und dass Ihre vorhandenen Zertifikate monatlich gelegentlich bereits verfallen, bevor sie erneuert werden.

Der Name des Programms ist certbot, von dem aus umbenannt wurde letsencrypt. Wenn Sie immer noch verwenden letsencrypt, müssen Sie auf die aktuelle Version aktualisieren.

Abgesehen von diesen Problemen ist es ungefähr dasselbe wie meine Cronjobs.

43 6 * * * certbot renew --post-hook "systemctl reload nginx"

Beachten Sie, dass in 18.04 LTS das letsencrypt-Paket (endgültig) in certbot umbenannt wurde. Es enthält jetzt einen System-Timer, mit dem Sie Certbot-Erneuerungen mit systemctl enable certbot.timerund planen können systemctl start certbot.timer. Ubuntu bot jedoch keine Möglichkeit, Hooks anzugeben. Sie müssen eine Außerkraftsetzung für einrichten certbot.service, um ExecStart=die gewünschte Befehlszeile außer Kraft zu setzen , bis Ubuntu dies behebt.


3
Welches Zeitfenster steht kurz vor dem Ablauf?
Andre Figueiredo

3
Es ist möglicherweise besser, den Benutzer --renew-hookanstelle von neu --post-hookzu starten, wenn das Zertifikat erfolgreich erneuert wurde.
Mwfearnley

6
Für Apache / httpd, certbot renewwird nur funktionieren ™
Airey

1
Ich wollte nur hinzufügen, anstatt zwingende ExecStart nginx neu zu laden, fügen Sie einfach eine ExecStartPost Linie certbot.service Ihr Webserver zu laden , nachdem es fertig ist: ExecStartPost=/usr/sbin/service nginx reload. Arbeitete für mich!
JD Mallen

1
@ JDMallen Using ExecStartPost=ist eine gute Idee. Warum habe ich nicht daran gedacht? Beachten Sie jedoch, dass der serviceBefehl veraltet ist. es wird nicht für immer da sein. Wechseln Sie zu den entsprechenden systemctlBefehlen.
Michael Hampton

56

Ich habe nicht genug Reputation, um einen Kommentar abzugeben, also werde ich hier antworten. Ich habe kürzlich (Oktober 2017) certbot auf einem Ubuntu 16.04-Server installiert und ausgeführt, und in wurde automatisch ein Erneuerungs-Cron-Job erstellt /etc/cron.d/certbot.

Hier ist der Cron-Job, der erstellt wurde:

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Es ist ratsam, vor dem Erstellen eines crontab-Eintrags zu prüfen, ob diese Datei bereits vorhanden ist.


1
Ich sah, dass ich das auch hatte, nachdem ich certbot ausgeführt hatte. Sehr schön, dass sich das verschlüsseln lässt! Es ist ein großartiges Projekt.
Bjorn

7
Es ist zu beachten, dass der obige Cron-Job nicht ausgeführt wird, certbot renewwenn er /run/systemd/systemvorhanden ist. Dies liegt daran, dass ein System-Timer Certbot ausführt. Weitere Informationen zu Certbot- und System-Timern finden Sie hier .
Hamish Downer

Vielen Dank für die Erwähnung, dass bereits ein Cronjob installiert wurde. Das war mir erst bewusst, als ich Ihren Beitrag gelesen habe.
NilsB

1
Für alle, die sich fragen, läuft es alle 12 Stunden. Die andere Antwort ließ 43 6 * * *es jeden Tag um 6:43 Uhr laufen. Einmal am Tag sollte ausreichen, aber beides funktioniert einwandfrei.
22.

42

In der certbot-Dokumentation wird empfohlen, das Skript zweimal täglich auszuführen :

Hinweis:

Wenn Sie einen Cron- oder System-Job einrichten, empfehlen wir, ihn zweimal täglich auszuführen (er wird erst ausgeführt, wenn Ihre Zertifikate erneuert oder widerrufen werden müssen. Durch die regelmäßige Ausführung kann Ihre Website jedoch online bleiben (In diesem Fall ist aus irgendeinem Grund ein von Let's Encrypt initiierter Widerruf aufgetreten.) Bitte wählen Sie eine zufällige Minute innerhalb der Stunde für Ihre Erneuerungsaufgaben.

Wie Michael Hampton erwähnt, wurde der Name in certbot geändert, sie bieten jedoch weiterhin die Option -auto, die sich selbst auf dem neuesten Stand hält. Der certbot-autoBefehl benötigt root-Berechtigungen, damit er ausgeführt werden kann. Die Zeile in Ihrem Cron-Skript sollte also ungefähr so ​​aussehen:

52 0,12 * * * root /full/path/to/certbot-auto renew --quiet

In meinem Fall wird das certbot-autoSkript im Home-Verzeichnis des Git-Benutzers abgelegt. Der genaue Befehl lautet dann

52 0,12 * * * root /home/git/certbot-auto renew --quiet

Beachten Sie, dass das Beispiel in der Dokumentation einem relativen Pfad entspricht, wie durch den Punkt angegeben, der verwirrend sein kann:

./path/to/certbot-auto renew --quiet

Stellen Sie sicher, dass Sie den Befehl renew zuvor in einer Shell testen, um den Pfad zu testen. Wenn das Zertifikat nicht erneuert werden muss, passiert nichts (führen Sie diesen Test ohne --quietFlag aus, um zu sehen, was passiert).

Es ist nicht unbedingt erforderlich, den Server neu zu laden, wenn das Zertifikat auf diese Weise erneuert wird, da sich der Pfad zum Live-Zertifikat bei korrekter Einrichtung nicht ändert.

Dies ist der Fall, wenn Sie Apache ausführen. Fügen Sie für Nginx einen Erneuerungs-Hook hinzu, z.

52 0,12 * * * root certbot renew --renew-hook 'service nginx reload'

1
Mir gefällt, wie dies erklärt wird, es ist kein detaillierter Neustart des Dienstes erforderlich (es könnte zu Problemen führen, wenn jemand etwas unternimmt und zweimal am Tag die Chance hat, erwischt zu werden) und die erforderlichen Berechtigungen zu erwähnen.
Gusstavv Gil

4
Das ist nicht wahr - es ist notwendig , den Server neu zu laden, zumindest mit Nginx - nginx erscheint die anfängliche Zertifikat zwischenzuspeichern und nicht registriert ein neues Zertifikat , selbst wenn die Datei ändert. In diesem Beitrag erfahren--renew-hook
Sie

17

Sie sollten nichts einrichten müssen. Jede neuere Debian / Ubuntu-Installation von certbot sollte einen systemd-Timer und einen cron-Job installieren (und der cron-Job wird nur ausgeführt, certbotwenn systemd nicht aktiv ist, damit nicht beide ausgeführt werden).

System-Timer

Sie können Ihre System-Timer mit dem Befehl überprüfen systemctl list-timers(oder systemctl list-timers --allwenn Sie auch inaktive Timer anzeigen möchten). Etwas wie das:

% sudo systemctl list-timers
NEXT                         LEFT        LAST                         PASSED      UNIT                         ACTIVATES
Fri 2018-08-03 06:17:25 UTC  10h left    Thu 2018-08-02 06:27:13 UTC  13h ago     apt-daily-upgrade.timer      apt-daily-upgrade.service
Fri 2018-08-03 11:43:29 UTC  15h left    Thu 2018-08-02 16:54:52 UTC  3h 7min ago certbot.timer                certbot.service
Fri 2018-08-03 12:44:58 UTC  16h left    Thu 2018-08-02 19:14:58 UTC  47min ago   apt-daily.timer              apt-daily.service
Fri 2018-08-03 19:43:44 UTC  23h left    Thu 2018-08-02 19:43:44 UTC  18min ago   systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2018-08-06 00:00:00 UTC  3 days left Mon 2018-07-30 00:00:09 UTC  3 days ago  fstrim.timer                 fstrim.service

Der Certbot-Timer sollte hier sein /lib/systemd/system/certbot.timerund führt den in angegebenen Befehl aus/lib/systemd/system/certbot.service

certbot.timer wird den certbot.service um 12 und 12 Uhr nach einer zufälligen Verzögerung von bis zu 12 Stunden (43200 Sekunden) ausführen.

# cat /lib/systemd/system/certbot.timer
[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

und certbot.serviceführt den Erneuerungsbefehl aus.

# cat /lib/systemd/system/certbot.service
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

Cron-Job

Wie bereits erwähnt, ist auch ein Cron-Job installiert in /etc/cron.d/certbot:

# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

Das macht:

  • test -x /usr/bin/certbot -a \! -d /run/systemd/system- Überprüfen Sie, ob /usr/bin/certbotes sich um eine ausführbare Datei handelt und ob /run/systemd/systemes sich nicht um ein Verzeichnis handelt. Fahren Sie erst mit dem nächsten Bit fort, wenn diese Prüfung erfolgreich ist.
    • Der systemd-Teil der Prüfung bedeutet effektiv, dass, wenn systemd ausgeführt wird, certbot nicht über den Cron-Job ausgeführt wird - überlassen Sie dies dem Timer.
  • perl -e 'sleep int(rand(43200))' - Schlaf eine zufällige Menge zwischen 0 Sekunden und 12 Stunden (43200 = 12 x 60 x 60).
  • certbot -q renewÜberprüfen Sie Ihre Zertifikate und erneuern Sie sie gegebenenfalls. Das -qFlag ist "leise" - es wird nur ausgegeben, wenn ein Fehler vorliegt.

Ich war ursprünglich durch den Cron-Job verwirrt, da er aufgrund von systemd nicht ausgeführt werden würde. Wie würde Certbot ausgeführt werden? Ich habe die Antwort in diesem Forumsbeitrag gefunden, auf die ich diese Antwort gestützt habe.


1
"Sie sollten nichts einrichten müssen", aber mein Zertifikat ist vor kurzem abgelaufen und ich habe certbot vor ungefähr 3 Monaten installiert. /etc/cron.d/certbotexistiert, systemctl list-timerszeigt certbot.timer, aber meine Zertifikate wurden nicht erneuert. Das certbotmanuelle Laufen hat gut funktioniert, ich weiß also nicht, was los ist. Fügte am Ende einen crontabEintrag der alten Schule hinzu .
Dan Dascalescu

Dies ist die aktuellste und korrekteste Antwort, aber mit einer Einschränkung, die davon abhängt, welche Entfernung Sie verwenden: certbot.eff.org/docs/using.html#id8
olive_tree

msgstr "und der Cron - Job wird nur ausgeführt, wenn systemd nicht aktiv ist". Können Sie uns helfen, ein Dokument zu diesem "Präzedenzfall" zu finden?
Titus

@titus die Erklärung ist, dass der Cron-Job zuerst eine ausführt test, um zu überprüfen, ob systemd aktiv ist, und wenn dies der Fall ist, wird der Cron-Job sofort beendet, ohne ausgeführt zu werden certbot- siehe den Text über den Cron-Job. Ich werde den Text genauer bearbeiten.
Hamish Downer

5

Für die Erneuerung des LetsEncrypt-Zertifikats verwende ich im Allgemeinen getssl . Es ist ein sehr praktischer Shell-Wrapper, der sogar Zertifikate über eine SSH-Verbindung auf anderen Computern installieren kann.

Der Cron-Eintrag lautet wie folgt:

01 23 * * * root /root/scripts/getssl/getssl -u -a -q >>/var/log/getssl.log 2>&1 ; /usr/sbin/apache2ctl graceful

Wie bereits empfohlen, sollten Sie es täglich oder sogar zweimal täglich ausführen.


3

Wie schon von glaux erwähnt:

Hinweis: Wenn Sie einen Cron- oder System-Job einrichten, empfehlen wir, ihn zweimal täglich auszuführen (er wird erst ausgeführt, wenn Ihre Zertifikate erneuert oder widerrufen werden müssen. Wenn er jedoch regelmäßig ausgeführt wird, hat Ihre Site die Möglichkeit zu bleiben online für den Fall, dass aus irgendeinem Grund ein von Let's Encrypt initiierter Widerruf stattgefunden hat). Bitte wählen Sie eine zufällige Minute innerhalb der Stunde für Ihre Erneuerungsaufgaben.

Quelle: https://certbot.eff.org/all-instructions/#debian-8-jessie-apache

Also habe ich das letztendlich benutzt (Laufen ist zweimal am Tag, um 01:00 und um 13:00 jeden Tag):

6 1,13 * * * certbot renew --post-hook "service apache2 restart"

oder noch besser:

6 1,13 * * * certbot renew --renew-hook "service apache2 restart"

Ich habe nicht getestet, aber das sollte auch funktionieren:

6 1,13 * * * certbot renew --post-hook "/etc/init.d/apache2 restart"
6 1,13 * * * certbot renew --renew-hook "/etc/init.d/apache2 restart"

--Pre-Hook- und --Post-Hook-Haken laufen vor und nach jedem Erneuerungsversuch. Wenn Ihr Hook erst nach einer erfolgreichen Erneuerung ausgeführt werden soll, verwenden Sie --renew-hook in einem Befehl wie diesem.

Quelle: https://certbot.eff.org/docs/using.html


1
"Bitte wählen Sie eine zufällige Minute innerhalb der Stunde für Ihre Erneuerungsaufgaben aus."
Isius

1
Nach meinem obigen Hinweis ist es besser --renew-hook, wenn Ihr Server erst neu gestartet wird, wenn das Zertifikat tatsächlich erneuert wird.
Was könnte

@Isius danke, ich habe es in eine zufällige Minute geändert (6).
Tadej

1
@JedatKinports: sollte nicht --post-hookund --renew-hooksein service apache2 restartstatt service restart apache2?
Paul Ratazzi

1
Der Befehl lautet service apache2 restart ! Der service restart apache2Befehl / Dienst ist nicht korrekt.
GTodorov

1

Das benutze ich:

/opt/letsencrypt/letsencrypt-auto renew

gibt aus als:

Upgrading certbot-auto 0.8.1 to 0.9.1...
Replacing certbot-auto...
Creating virtual environment...
...
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/host.simplecoin.cz/fullchain.pem
-------------------------------------------------------------------------------

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/host.simplecoin.cz/fullchain.pem (success)

Und es besagt, dass Apache bereits neu gestartet wurde, so dass es nicht nötig ist, es noch einmal zu wiederholen. Wenn ich es erneut ausführe:

Cert not yet due for renewal

Daher ist es kein Problem, das Zertifikat täglich zu erneuern. Mein Cron lautet dann:

@daily /opt/letsencrypt/cronautorenew.sh

Ich verwende ein Skript, um die Protokollierung in einer separaten Datei zu optimieren. Hier ist meine cronautorenew.sh:

#!/usr/bin/env bash
printf "\nattempt to renew certificates" >>/var/log/letsencrypt_cron.log 2>&1
date >>/var/log/letsencrypt_cron.log 2>&1
/opt/letsencrypt/letsencrypt-auto renew >>/var/log/letsencrypt_cron.log 2>&1
printf "renew finished\n" >>/var/log/letsencrypt_cron.log 2>&1

1

Andere Mitglieder gaben bereits detailliertere Antworten. Aber anscheinend sollte ich es hier erwähnen.

Ab certbot Version 0.21.1 wurde das --renew-hookFlag in --deploy-hook Vergewissern Sie sich, dass Sie kein veraltetes Flag verwenden.

certbot renew --deploy-hook "systemctl restart myservice"

0

Laut EFF Certbot Guide

Viele Linux-Distributionen bieten eine automatische Erneuerung, wenn Sie die Pakete verwenden, die über ihren Systempaket-Manager installiert wurden.

Wenn Sie nicht sicher sind, ob Ihr System dies bereits automatisiert hat, überprüfen Sie die crontab Ihres Systems (normalerweise in /etc/crontab/und /etc/cron.*/* $ crontab -lund systemd-Timern) $ systemctl list-timers .

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.