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

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

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.

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.

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'

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.

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.

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

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

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"

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 .