Завдання Cron - давайте шифруємо оновлення

Це правильний спосіб встановити cron для оновлення cert шифрувати cert в Apache2? Я використовую Ubuntu 16.04.

@monthly letsencrypt renew && service apache2 reload

Щомісяця недостатньо часто. Цей сценарій повинен працювати щонайменше щотижня, а краще щодня. Пам’ятайте, що серти не оновлюються, якщо вони не закінчуються, а щомісяця може призвести до того, що періодично закінчується термін дії ваших існуючих сертифікатів вже до їх поновлення.

Назва програми - це certbot, з якої було перейменовано letsencrypt. Якщо ви все ще використовуєте letsencrypt, вам потрібно оновити до поточної версії.

Окрім цих питань, це приблизно те саме, що і у моїх робочих місцях.

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

Зауважте, що в 18.04 LTS пакет letsencrypt був (нарешті) перейменований на certbot. Тепер він включає системний таймер, за допомогою якого ви можете дозволити планувати оновлення certbot, за допомогою systemctl enable certbot.timerта systemctl start certbot.timer. Однак Ubuntu не запропонував спосіб вказати гачки. Вам потрібно буде встановити переопределення, certbot.serviceщоб перекрити ExecStart=потрібний командний рядок, поки Ubuntu не виправить це.

У мене недостатньо репутації для коментарів, тому я відповім тут. Нещодавно (жовтень 2017 року) я встановив і запустив certbot на сервері Ubuntu 16.04, і завдання Cron для оновлення було створено автоматично в /etc/cron.d/certbot.

Ось робота зі cron, яка була створена:

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

Було б непогано перевірити, чи цей файл вже існує, перш ніж створювати запис на кроні.

Документація certbot рекомендує запускати сценарій двічі на день:

Примітка:

якщо ви налаштовуєте роботу із системою cron або systemd, радимо запускати її двічі на день (вона нічого не зробить, поки ваші сертифікати не будуть відновлені або відкликані, але запуск її регулярно надасть вашому сайту можливість залишатися в Інтернеті у випадку скасування давальницького шифрування відбулося з якихось причин). Будь ласка, виберіть випадкову хвилину протягом години для ваших завдань із поновлення.

Як згадує Майкл Хемптон, ім'я змінилося на certbot, але вони все ще надають опцію -auto, яка постійно оновлюється. certbot-autoКоманді потрібна кореневі привілейованості працювати, так як у вашому Хроні сценарії повинні виглядати наступним чином :

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

У моєму випадку certbot-autoсценарій розміщується в домашній довідці користувача git. Точна команда тоді

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

Зауважте, що приклад в документації відповідає відносному шляху, який позначений крапкою, який може заплутати:

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

Не забудьте заздалегідь заздалегідь випробувати команду оновлення в оболонці, щоб перевірити шлях, якщо сертифікат не належить до поновлення, нічого не відбудеться (запустіть цей тест без --quietпрапора, щоб побачити, що відбувається).

Не обов'язково перезавантажувати сервер, коли сертифікат поновлюється таким чином, оскільки шлях до живого сертифіката не змінюється при правильному налаштуванні.

Це справедливо, якщо ви запускаєте apache - для nginx, розгляньте можливість додавання гачка оновлення, наприклад:

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

Вам не потрібно було нічого встановлювати. Будь-яка недавня установка Debian / Ubuntu certbot повинна встановити системний таймер та роботу cron (а завдання cron буде виконуватися лише в тому certbotвипадку, якщо systemd не активний, тому ви не працюєте обома).

системний таймер

Ви можете перевірити свої системні таймери за допомогою команди systemctl list-timers(або systemctl list-timers --allякщо ви також хочете показати неактивні таймери). Щось на зразок цього:

% 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

Тут повинен бути таймер certbot, /lib/systemd/system/certbot.timerі він виконає команду, вказану в/lib/systemd/system/certbot.service

certbot.timer виконає службу `certbot.service о 12 ранку та 12 вечора, після випадкової затримки до 12 годин (43200 секунд).

# 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

і certbot.serviceвиконає команду оновлення.

# 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

робота з крон

Як уже згадували інші, є також завдання, що встановлюється в /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

Це робиться:

• test -x /usr/bin/certbot -a \! -d /run/systemd/system- перевірте, чи /usr/bin/certbotє виконавчим файлом, а /run/systemd/systemце не каталог. Перейдіть до наступного біту, лише якщо ця перевірка буде успішною.
  • Системна частина перевірки фактично означає, що якщо systemd запущений, не запускайте certbot від завдання cron - залиште це таймеру.
• perl -e 'sleep int(rand(43200))' - сплять випадкову кількість від 0 секунд до 12 годин (43200 = 12 x 60 x 60).
• certbot -q renewперевірити свої сертифікати та поновити будь-які, якщо потрібно. -qПрапор «тихий» - не справляють ніякого виведення , якщо немає помилки.

Мене спочатку збентежила робота cron, оскільки вона не збиралася запускатися через systemd, то як би запускався certbot? У цій публікації на форумі я знайшов відповідь, на чому я грунтувався на цій відповіді.

Для відновлення сертифікату LetsEncrypt я зазвичай використовую getssl . Це дуже зручна оболонка, яка навіть може встановити сертифікат на інші машини через SSH-з'єднання.

Запис крона такий:

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

Як уже було запропоновано, слід запускати його щодня або, ще краще, двічі на день.

Як вже згадував glaux:

Примітка: якщо ви налаштовуєте роботу з хроном або системою, радимо запускати її двічі на день (вона не буде робити нічого, поки ваші сертифікати не будуть відновлені або відкликані, але запуск її регулярно дасть можливість вашому сайту залишитися в Інтернеті, якщо скасування "Давайте зашифруємо" відбудеться з якихось причин). Будь ласка, виберіть випадкову хвилину протягом години для ваших завдань із поновлення.

Джерело: https://certbot.eff.org/all-instructions/#debian-8-jessie-apache

Тож я закінчила користуватися цим (працює два рази на день, о 01:00 та 13:00 щодня):

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

а ще краще:

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

Я не тестував, але це також має працювати:

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

- гачки попереднього підключення та - гачки для поштового зв'язку запускаються до та після кожної спроби відновлення. Якщо ви хочете, щоб ваш гак запускався лише після успішного оновлення, використовуйте --renew-hock у такій команді.

Джерело: https://certbot.eff.org/docs/using.html

Це те, що я використовую:

/opt/letsencrypt/letsencrypt-auto renew

дає вихід у вигляді:

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)

І його приказка, що апаш вже перезапущений, тому не потрібно робити це заново. Якщо я запускаю його ще раз:

Cert not yet due for renewal

тому щодня не поновлюйте сертифікат, мій cron тоді:

@daily /opt/letsencrypt/cronautorenew.sh

Я використовую скрипт для налаштування журналу для окремого файлу, тому ось мій 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

Інші учасники вже надали набагато детальніші відповіді. Але схоже, я мушу тут згадати.

Станом на версію certbot версії 0.21.1 змінено --renew-hookпрапор --deploy-hook Переконайтесь, що ви не використовуєте застарілий прапор.

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

Згідно з посібником з certbot EFF

Багато дистрибутивів Linux забезпечують автоматичне оновлення під час використання пакетів, встановлених через їх системний менеджер пакетів.

Якщо ви не впевнені , є ваша система це вже автоматизована, перевірте вашу систему кронтаб ( як правило , в /etc/crontab/і /etc/cron.*/* $ crontab -lі Systemd таймерів $ systemctl list-timers .