Zadanie Crona do zaszyfrowania odnowienia

93

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
użytkownik3448600
źródło
6
Jak podaje jedna z odpowiedzi poniżej, certbot v0.19.0 (i może niektóre wcześniej) już tworzą wpis crontab @/etc/cron.d/certbot
xgMz
Ponadto wtyczka apache certbot z walidacją tls-sni przeładuje apache w ramach procedury sprawdzania poprawności po odzyskaniu nowego certyfikatu.
xgMz
Poniżej znajduje się odpowiedź, która jest bardzo ważna dla nowych instalacji (od JAN 2019), certbot automatycznie dodaje zegar systemowy i harmonogram zadań cron, więc konfiguracja cron nie jest potrzebna z twojej strony.
Cory Robinson

Odpowiedzi:

144

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.

Michael Hampton
źródło
3
Które okno czasowe jest „bliskie wygaśnięcia”?
Andre Figueiredo
3
Lepiej jest użyć --renew-hookzamiast tego --post-hookzrestartować komputer tylko wtedy, gdy certyfikat zostanie pomyślnie odnowiony.
mwfearnley
6
W przypadku apache / httpd certbot renewpo prostu zadziała ™
aairey,
1
Chciałem tylko dodać, zamiast przesłanianie ExecStart przeładować nginx, po prostu dodaj linię ExecStartPost do certbot.service aby przeładować serwer WWW po to się robi: ExecStartPost=/usr/sbin/service nginx reload. Pracował dla mnie!
JD Mallen,
1
@JDMallen Korzystanie ExecStartPost=to dobry pomysł. Dlaczego o tym nie pomyślałem? Ale pamiętaj, że servicepolecenie jest przestarzałe; nie będzie na zawsze. Przejdź do odpowiednich systemctlpoleceń.
Michael Hampton
56

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.

ishigoya
źródło
1
Zauważyłem, że też to mam po uruchomieniu certbota. Bardzo dobrze, że pozwala to zaszyfrować! To świetny projekt.
Bjorn,
7
Warto mieć świadomość, że powyższe zadanie cron nie uruchomi się, certbot renewjeśli /run/systemd/systemjest obecne - dzieje się tak, ponieważ zamiast tego systemb działa z uruchomionym programem certbot - przeczytaj więcej o tym programie i tutaj .
Hamish Downer,
Dziękujemy za informację, że cronjob został już zainstalowany. Nie wiedziałem o tym, dopóki nie przeczytałem twojego postu.
NilsB,
1
Dla każdego, kto się zastanawia, działa to co 12 godzin. Druga odpowiedź 43 6 * * *sprawi, że będzie działać codziennie o 06:43. Raz dziennie powinno wystarczyć, ale jedno z nich działa dobrze.
orrd
42

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'
glaux
źródło
1
Podoba mi się, jak to wyjaśniono, nie jest konieczne szczegółowe opisywanie restartu usługi (może to zepsuć, jeśli ktoś coś na tym zrobi, mając szansę dwa razy dziennie na złapanie) i wspominanie o wymaganych uprawnieniach.
Gusstavv Gil
4
To nie jest prawda - to jest konieczne, aby przeładować serwer, przynajmniej z Nginx - nginx wydaje się buforować początkowe świadectwo i nie zarejestrować nowe cert nawet jeśli zmiany plików. Zobacz ten post, aby uzyskać informacje o używaniu --renew-hookdo restartowania tylko po udanym odnowieniu: guyrutenberg.com/2017/01/01/…
Whatcould
17

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

Hamish Downer
źródło
1
„Nie powinieneś niczego konfigurować”, ale mój certyfikat wygasł niedawno i zainstalowałem certbota około 3 miesiące temu. /etc/cron.d/certbotistnieje, systemctl list-timerspokazuje certbot.timer, ale moje certyfikaty nie zostały odnowione. Uruchamianie certbotręczne działało dobrze, więc nie wiem, co się dzieje. Skończyło się dodawanie crontabwpisu starej szkoły .
Dan Dascalescu
To jest najbardziej aktualna i prawidłowa odpowiedź, ale z zastrzeżeniem, że zależy to od tego, jaką dystrybucję
olive_tree
msgstr "a zadanie cron będzie działać tylko wtedy, gdy systemd nie jest aktywny". Czy możesz pomóc w znalezieniu jakiegoś dokumentu na temat tego „pierwszeństwa” wyjaśnionego, proszę?
Tytus
@titus wyjaśnienie jest takie, że zadanie cron najpierw uruchamia polecenie a, testaby sprawdzić, czy systemd jest aktywne, a jeśli tak, zadanie cron natychmiast kończy pracę bez uruchamiania certbot- zobacz tekst o zadaniu cron. Będę bardziej precyzyjnie edytować tekst.
Hamish Downer
5

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.

Shodanshok
źródło
3

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

Tadej
źródło
1
„Wybierz losową minutę w ciągu godziny dla swoich zadań odnowienia”.
Isius
1
Zgodnie z moją notatką lepiej byłoby, gdybyś --renew-hookzrestartował serwer tylko wtedy, gdy certyfikat zostanie faktycznie odnowiony.
Whatcould
@Isius dzięki, zmieniłem go na losową minutę (6).
Tadej
1
@JedatKinports: --post-hookczy zamiast tego nie powinno --renew-hookbyć ? service apache2 restartservice restart apache2
Paul Ratazzi
1
Poleceniem jest restart usługi Apache2 ! service restart apache2Nie jest poprawna komenda / usługa.
GTodorov
1

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
Pavel Niedoba
źródło
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"
Shinebayar G.
źródło
0

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 .

Suhayb
źródło