Zadanie Crona do zaszyfrowania odnowienia

Czy to poprawny sposób ustawienia crona na odnowienie certyfikatu Let's Encrypt w Apache2? Używam Ubuntu 16.04.

@monthly letsencrypt renew && service apache2 reload

Miesięcznik nie jest wystarczająco częsty. Ten skrypt powinien być uruchamiany co najmniej raz w tygodniu, a najlepiej codziennie. Pamiętaj, że certyfikaty nie są odnawiane, chyba że zbliżają się do wygaśnięcia, a co miesiąc spowodowałoby to, że twoje istniejące certyfikaty czasami wygasają przed ich odnowieniem.

Nazwa programu to nazwa, od certbotktórej zmieniono nazwę letsencrypt. Jeśli nadal używasz letsencrypt, musisz zaktualizować do bieżącej wersji.

Oprócz tych problemów, to mniej więcej tyle samo, co moich zadań crona.

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

Zauważ, że w 18.04 LTS pakiet letsencrypt został (w końcu) przemianowany na certbot. Zawiera teraz systemowy zegar, który można włączyć do planowania odnawiania certyfikatów przez, systemctl enable certbot.timeri systemctl start certbot.timer. Jednak Ubuntu nie podał sposobu określania haków. Musisz ustawić przesłonięcie, certbot.serviceaby przesłonić ExecStart=żądanym wierszem poleceń, dopóki Ubuntu nie naprawi tego.

Nie mam wystarczającej reputacji, aby komentować, więc odpowiem tutaj. Niedawno (październik 2017 r.) Zainstalowałem i uruchomiłem certbot na serwerze Ubuntu 16.04, a zadanie CRON odnowienia zostało utworzone automatycznie w /etc/cron.d/certbot.

Oto zadanie cron, które zostało utworzone:

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

Dobrym pomysłem byłoby sprawdzenie, czy ten plik już istnieje przed utworzeniem pozycji crontab.

Dokumentacja certbota zaleca uruchamianie skryptu dwa razy dziennie:

Uwaga:

jeśli konfigurujesz cron lub zadanie systemowe, zalecamy uruchamianie go dwa razy dziennie (nie zrobi nic, dopóki twoje certyfikaty nie zostaną przedłużone lub unieważnione, ale regularne uruchamianie dałoby twojej stronie szansę na pozostanie online przypadek z jakiegoś powodu nastąpiło odwołanie zainicjowane przez Let's Encrypt). Wybierz losową minutę w ciągu godziny dla zadań odnowienia.

Jak wspomina Michael Hampton, nazwa zmieniła się na certbot, ale nadal zapewniają opcję -auto, która aktualizuje się. certbot-autoPolecenia potrzebne przywileje roota do uruchomienia, więc linia w skrypcie cron powinien wyglądać mniej więcej tak:

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

W moim przypadku certbot-autoskrypt jest umieszczony w katalogu domowym użytkownika git. Dokładne polecenie jest wtedy

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

Zauważ, że przykład w dokumentacji odpowiada ścieżce względnej, wskazanej kropką, która może być myląca:

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

Pamiętaj, aby wcześniej przetestować komendę odnawiania w powłoce, aby przetestować ścieżkę, jeśli certyfikat nie jest przeznaczony do odnowienia, nic się nie wydarzy (uruchom ten test bez --quietflagi, aby zobaczyć, co się dzieje).

Ponowne załadowanie serwera nie jest absolutnie konieczne, gdy certyfikat jest odnawiany w ten sposób, ponieważ ścieżka do certyfikatu na żywo nie zmienia się, jeśli jest poprawnie skonfigurowana.

Dzieje się tak, jeśli korzystasz z Apache - w przypadku Nginx rozważ dodanie haka odnawiania, takiego jak:

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

Nie powinieneś niczego konfigurować. Każda ostatnia instalacja certbota w Debianie / Ubuntu powinna zainstalować systemowy zegar i zadanie cron (a zadanie cron uruchomi się tylko certbotwtedy, gdy systemd nie jest aktywny, więc nie uruchomisz obu).

systemowy zegar

Możesz sprawdzić systemowe liczniki czasu za pomocą polecenia systemctl list-timers(lub systemctl list-timers --alljeśli chcesz również pokazać nieaktywne liczniki czasu). Coś takiego:

% 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

Timer certbota powinien tu być /lib/systemd/system/certbot.timeri wykona polecenie określone w/lib/systemd/system/certbot.service

certbot.timer wykona usługę `certbot.service o godzinie 12 i 12 po losowym opóźnieniu do 12 godzin (43200 sekund).

# 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

i certbot.servicewykona polecenie odnowienia.

# 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

praca crona

Jak wspomnieli inni, istnieje również zadanie cron zainstalowane w /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

To robi:

• test -x /usr/bin/certbot -a \! -d /run/systemd/system- sprawdzić, czy /usr/bin/certbotjest to plik wykonywalny i że /run/systemd/systemto nie katalogiem. Przejdź do następnego bitu tylko wtedy, gdy sprawdzenie się powiedzie.
  • Część systemowa sprawdzania skutecznie oznacza, że ​​jeśli systemd jest uruchomiony, nie uruchamiaj certbota z zadania cron - pozostaw to licznikowi czasu.
• perl -e 'sleep int(rand(43200))' - spać losowo od 0 sekund do 12 godzin (43200 = 12 x 60 x 60).
• certbot -q renewsprawdź swoje certyfikaty i w razie potrzeby odnów je. -qFlaga jest „cichy” - nie wytwarzają żadnego wyjścia, chyba że jest to błąd.

Początkowo byłem zdezorientowany zadaniem crona, ponieważ nie miał on działać z powodu systemd, więc jak uruchomić certbota? Znalazłem odpowiedź w tym poście na forum, na którym oparłem tę odpowiedź.

W przypadku odnawiania certyfikatu LetsEncrypt zwykle używam getssl . Jest to bardzo poręczne opakowanie powłoki, które może nawet instalować certyfikat na innych komputerach za pośrednictwem połączenia SSH.

Wpis crona jest następujący:

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

Jak już zasugerowano, należy go uruchamiać codziennie, a nawet lepiej dwa razy dziennie.

Jak już wspomniano przez glaux:

Uwaga: jeśli konfigurujesz zadanie CRON lub systemowe, zalecamy uruchamianie go dwa razy dziennie (nie zrobi nic, dopóki twoje certyfikaty nie zostaną przedłużone lub unieważnione, ale regularne uruchamianie dałoby twojej stronie szansę na pozostanie online na wypadek, gdyby z jakiegoś powodu nastąpiło odwołanie zainicjowane przez Let's Encrypt). Wybierz losową minutę w ciągu godziny dla zadań odnowienia.

Źródło: https://certbot.eff.org/all-instructions/#debian-8-jessie-apache

Skończyło się na tym (bieganie jest dwa razy dziennie, o 01:00 i codziennie o 13:00):

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

lub nawet lepiej:

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

Nie testowałem, ale powinno to również działać:

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

- haki przedhakowe i --hakowe są uruchamiane przed każdą próbą odnowienia i po niej. Jeśli chcesz, aby hak działał tylko po pomyślnym odnowieniu, użyj --renew-hook w takim poleceniu.

Źródło: https://certbot.eff.org/docs/using.html

Oto, czego używam:

/opt/letsencrypt/letsencrypt-auto renew

daje wynik jako:

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)

Mówi też, że apache jest już zrestartowany, więc nie trzeba tego robić od nowa. Jeśli uruchomię go ponownie:

Cert not yet due for renewal

dlatego codzienne odnawianie certyfikatu nie stanowi problemu, mój cron to:

@daily /opt/letsencrypt/cronautorenew.sh

Używam skryptu, aby dostosować logowanie do oddzielnego pliku, więc oto mój plik 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

Inni członkowie już udzielili dużo bardziej szczegółowych odpowiedzi. Ale wygląda na to, że powinienem o tym wspomnieć.

W wersji certbot --renew-hookflaga 0.21.1 została zmieniona na --deploy-hook Upewnij się, że nie używasz przestarzałej flagi.

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

Według przewodnika po certyfikacie EFF

Wiele dystrybucji Linuksa zapewnia automatyczne odnawianie, gdy używasz pakietów zainstalowanych za pośrednictwem ich menedżera pakietów systemowych.

Jeśli nie masz pewności, czy Twój system ma to już zautomatyzowane, sprawdź crontab systemu (zwykle w timery/etc/crontab/ i /etc/cron.*/* $ crontab -li systemowe $ systemctl list-timers .