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


Ist das richtig einzustellen? Cron zur Erneuerung von Let's Encrypt cert in Apache2? Ich benutze Ubuntu 16.04.

@monthly letsencrypt renew && service apache2 reload

67
2017-07-19 19:07


Ursprung


Wie einer der Antworten unten besagt, erstellen certbot v0.19.0 (und vielleicht einige früher) bereits einen crontab-Eintrag @ /etc/cron.d/certbot - xgMz
Außerdem wird das Apache-Plugin certbot mit der tls-sni-Validierung Apache als Teil des Validierungsverfahrens erneut laden, nachdem das neue Zertifikat abgerufen wurde. - xgMz


Antworten:


Monatlich ist nicht häufig genug. Dieses Skript sollte mindestens wöchentlich und vorzugsweise täglich ausgeführt werden. Denken Sie daran, dass Zertifikate nicht erneuert werden, es sei denn, sie sind kurz vor dem Ablaufdatum, und monatlich würden Ihre bestehenden Zertifikate gelegentlich bereits abgelaufen sein, bevor sie erneuert werden.

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

Abgesehen von diesen Problemen, ist es ungefähr das gleiche wie meine Cron-Jobs.

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

Beachten Sie, dass in 18.04 LTS das letsencrypt-Paket (endlich) in certbot umbenannt wurde. Es enthält jetzt einen System-Timer, mit dem Sie die Verlängerung von Zertifikaten planen können, mit systemctl enable certbot.timer und systemctl start certbot.timer. Ubuntu bot jedoch keine Möglichkeit, Hooks zu spezifizieren. Sie müssen eine Überschreibung für einrichten certbot.service überschreiben ExecStart= mit der gewünschten Befehlszeile, bis Ubuntu das behebt.


102
2017-07-19 19:33



Ich kann einfach rennen crontab -e und einfügen @daily certbot renew && systemctl reload apache2 und es wird funktionieren, oder? Ich bin nicht so erfahren mit Linux. Ich weiß nicht, wie ich diese Cron-Jobs testen soll. - user3448600
@ user3448600 Vielleicht möchten Sie lesen serverfault.com/q/449651/126632 - Michael Hampton♦
Welches Zeitfenster ist "kurz vor Ablauf"? - Andre Figueiredo
@AndreFigueiredo Bei meinen Tests erneuert sich das Zertifikat automatisch etwa einen Monat vor Ablauf des Zertifikats. Ich konnte nicht sagen, ob es genau 30 Tage ist (ich vermute es ist). - glaux
Für Apache / httpd, certbot renew wird nur funktionieren - aairey


Ich habe nicht genug Reputation, um zu kommentieren, also werde ich hier antworten. Ich habe vor kurzem (Oktober 2017) certbot auf einem Ubuntu 16.04 Server installiert und ausgeführt und einen Cron Job wurde automatisch 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 wäre eine gute Idee zu überprüfen, ob diese Datei bereits existiert, bevor ein crontab-Eintrag erstellt wird.


42
2017-10-22 15:34



Gleiche Situation für mich. Danke für die Köpfe hoch! - Osborne Cox
Ich sah, dass ich das auch hatte, nachdem ich certbot ausgeführt hatte. Sehr schön das das verschlüsseln konnte! Es ist ein großartiges Projekt. - Bjorn Tipling
Es ist wert, dass der obige Cron-Job bekannt ist Gewohnheit Lauf certbot renew ob /run/systemd/system ist vorhanden - dies ist, weil stattdessen ein Systemd-Timer certbot läuft - Lesen Sie hier mehr über certbot und systemd Timer. - Hamish Downer


Das Zertifikat-Dokumentation empfiehlt, das Skript zweimal täglich auszuführen:

Hinweis:

Wenn Sie einen Cron- oder Systemd-Job einrichten, empfehlen wir, ihn zweimal pro Tag auszuführen (er wird nichts tun, bis Ihre Zertifikate erneuert oder widerrufen werden, aber wenn Sie sie regelmäßig ausführen, besteht für Ihre Website die Möglichkeit, online zu bleiben Fall ein Let's Encrypt-initiierter Widerruf aus irgendeinem Grund passiert ist). Bitte wählen Sie innerhalb von einer Stunde eine zufällige Minute für Ihre Erneuerungsaufgaben.

Wie Michael Hampton erwähnt, hat sich der Name in certbot geändert, aber sie bieten immer noch die Option -auto, die sich selbst aktualisiert. Das certbot-auto Befehl muss root priviledges ausführen, daher sollte die Zeile in Ihrem Cron-Skript in etwa so aussehen:

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

In meinem Fall die certbot-auto Das Skript befindet sich im Home-Verzeichnis des Git-Benutzers. Der genaue Befehl ist 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 angezeigt, der verwirrend sein kann:

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

Stellen Sie sicher, dass Sie den Verlängerungsbefehl in einer Shell vorher testen, um den Pfad zu testen. Wenn das Zertifikat nicht zur Erneuerung ansteht, wird nichts passieren (führen Sie diesen Test ohne --quiet um zu sehen, was gerade 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ür nginx sollten Sie einen neuen Hook hinzufügen, z.

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

35
2018-01-09 09:07



Ich mag es, wie das erklärt wird, ein Neustart des Dienstes ist nicht nötig (es könnte ein Durcheinander verursachen, wenn jemand etwas daran tut, zweimal täglich eine Chance hat, erwischt zu werden) und erwünschte Privilegien erwähnt. - Gusstavv Gil
Das ist nicht wahr - es ist notwendig, um den Server zumindest mit Nginx neu zu laden - nginx scheint das ursprüngliche Zertifikat zwischenzuspeichern und registriert kein neues Zertifikat, selbst wenn sich die Datei ändert. In diesem Beitrag finden Sie Informationen zur Verwendung --renew-hook nur nach einer erfolgreichen Verlängerung neu starten: guyrutenberg.com/2017/01/01/ ... - Whatcould


Für die LetsEncrypt-Zertifikatserneuerung verwende ich im Allgemeinen getssl. Es ist ein sehr nützlicher Shell-Wrapper, der sogar Zertifikate auf anderen Rechnern per SSH-Verbindung installieren kann.

Der Cron-Eintrag ist der folgende:

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

Wie bereits vorgeschlagen, sollten Sie es täglich oder noch besser zweimal am Tag ausführen.


4
2018-01-09 09:46





Wie bereits von glaux erwähnt:

Hinweis: Wenn Sie einen Cron- oder Systemd-Job einrichten, empfehlen wir die Ausführung   es zweimal pro Tag (es wird nichts tun, bis Ihre Zertifikate fällig sind   für die Verlängerung oder widerrufen, aber regelmäßig ausgeführt würde Ihre Website geben   eine Chance, online zu bleiben, falls Let's Encrypt initiiert wurde   Widerruf geschah aus irgendeinem Grund). 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 benutzt (Laufen ist zweimal am Tag, um 01:00 und jeden Tag um 13:00):

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 Hooks laufen vor und nach jedem Verlängerungsversuch. Wenn Sie möchten, dass Ihr Hook erst nach einer erfolgreichen Erneuerung ausgeführt wird,   Verwenden Sie --renew-hook in einem Befehl wie diesem.

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


3
2017-07-05 09:49



Msgstr "Bitte wähle eine zufällige Minute innerhalb der Stunde für deine Erneuerungsaufgaben." - Isius
Wie oben erwähnt, wäre es besser für Sie --renew-hook, die den Server nur neu startet, wenn das Zertifikat tatsächlich erneuert wird. - Whatcould
@Isius danke, ich habe es in eine zufällige Minute (6) geändert. - JedatKinports
@JedatKinports: sollte nicht die --post-hook und --renew-hook Sein service apache2 restart anstatt service restart apache2? - Paul Ratazzi
Der Befehl ist Service Apache2 neu starten! Das service restart apache2 ist nicht korrekt Befehl / Service. - GTodorov


Das ist was ich benutze:

/opt/letsencrypt/letsencrypt-auto renew

gibt Ausgabe 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 sagt, dass Apache bereits neu gestartet wurde, also muss man es nicht noch einmal machen. Wenn ich es nochmal ausführe:

Cert not yet due for renewal

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

@daily /opt/letsencrypt/cronautorenew.sh

Ich verwende Skript, um die Protokollierung zu einer separaten Datei zu optimieren, also hier ist mein 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
2017-10-10 11:50





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, wenn Systemd nicht aktiv ist, so dass beide nicht ausgeführt werden).

Systemzeitgeber

Sie können Ihre System-Timer mit dem Befehl überprüfen systemctl list-timers (oder systemctl list-timers --all wenn 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 Zertifikatstimer sollte hier sein /lib/systemd/system/certbot.timer und es wird den in angegebenen Befehl ausführen /lib/systemd/system/certbot.service

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

# 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.service fü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 andere bereits erwähnt haben, ist auch ein Cron-Job installiert /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/certbot ist eine ausführbare Datei und das /run/systemd/system ist nicht ein Verzeichnis. Fahren Sie nur 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 vom Cron-Job aus ausgeführt wird - überlassen Sie das 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 bei Bedarf. Das -q Flag ist "ruhig" - keine Ausgabe erzeugen, außer es liegt ein Fehler vor.

Ich war ursprünglich durch den Cron-Job verwirrt, da es aufgrund von Systemd nicht ausgeführt werden würde, also wie würde certbot ausgeführt werden? Ich habe die Antwort gefunden dieser Forenbeitrag Darauf habe ich diese Antwort aufgebaut.


1
2017-08-02 20:14



"Du solltest nichts einrichten müssen", aber mein Zertifikat ist kürzlich abgelaufen und ich habe certbot vor ungefähr 3 Monaten installiert. /etc/cron.d/certbot existiert, systemctl list-timers zeigt an certbot.timer, aber meine certs wurden nicht erneuert. Laufen certbot manuell funktionierte gut, so dass ich nicht weiß, was los ist. Hat eine alte Schule hinzugefügt crontab Eintrag. - Dan Dascalescu