Cron job pour le cryptage du renouvellement

Est-ce la bonne façon de définir cron pour le renouvellement du certificat Let's Encrypt dans Apache2? J'utilise Ubuntu 16.04.

@monthly letsencrypt renew && service apache2 reload

Tous les mois n'est pas assez fréquent. Ce script doit être exécuté au moins une fois par semaine, et de préférence tous les jours. N'oubliez pas que les certificats ne sont pas renouvelés sauf s'ils sont proches de l'expiration. Tous les mois, vos certificats existants sont parfois expirés avant leur renouvellement.

Le nom du programme est certbot, qui a été renommé à partir de letsencrypt. Si vous utilisez encore letsencrypt, vous devez mettre à jour la version actuelle.

Mis à part ces problèmes, c'est à peu près la même chose que mes emplois cron.

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

Notez que dans 18.04 LTS, le paquet letsencrypt a été (enfin) renommé en certbot. Il inclut maintenant un minuteur systemd que vous pouvez activer pour planifier les renouvellements de certbot, avec systemctl enable certbot.timeret systemctl start certbot.timer. Cependant, Ubuntu n’a pas fourni de moyen de spécifier les hooks. Vous aurez besoin de configurer un remplacement pour certbot.servicepouvoir remplacer ExecStart=par la ligne de commande souhaitée, jusqu'à ce que Ubuntu répare cela.

Je n'ai pas assez de réputation pour commenter, alors je vais répondre ici. Récemment (octobre 2017), j'ai installé et exécuté certbot sur un serveur Ubuntu 16.04 et un travail cron de renouvellement a été créé automatiquement dans /etc/cron.d/certbot.

Voici le travail cron qui a été créé:

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

Ce serait une bonne idée de vérifier si ce fichier existe déjà avant de créer une entrée dans la crontab.

La documentation de certbot recommande d'exécuter le script deux fois par jour:

Remarque:

si vous configurez un travail cron ou systemd, nous vous recommandons de l'exécuter deux fois par jour (il ne fera rien tant que vos certificats ne doivent pas être renouvelés ou révoqués, mais leur utilisation régulière donnerait à votre site une chance de rester en ligne. une révocation initiée par Let's Encrypt s’est produite pour une raison quelconque). Veuillez sélectionner une minute au hasard dans l'heure pour vos tâches de renouvellement.

Comme Michael Hampton le mentionne, le nom a été changé en certbot, mais ils fournissent toujours l'option -auto qui se met à jour. La certbot-autocommande nécessite des privilèges root pour être exécutée. La ligne de votre script cron doit donc ressembler à ceci:

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

Dans mon cas, le certbot-autoscript est placé dans le répertoire personnel de l'utilisateur git. La commande exacte est alors

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

Notez que l'exemple dans la documentation correspond à un chemin relatif, comme indiqué par le point qui peut prêter à confusion:

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

Assurez-vous de tester préalablement la commande renew dans un shell pour tester le chemin. Si le certificat n'est pas censé être renouvelé, rien ne se passera (exécutez ce test sans l' --quietindicateur pour voir ce qui se passe).

Il n'est pas strictement nécessaire de recharger le serveur lorsque le certificat est renouvelé de cette manière, car le chemin d'accès au certificat actif ne change pas s'il est configuré correctement.

Ceci est vrai si vous utilisez apache - pour nginx, pensez à ajouter un hook renouvelé, tel que:

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

Vous ne devriez pas avoir à configurer quoi que ce soit. Toute installation récente de certbot dans Debian / Ubuntu doit installer un temporisateur systemd et un travail cron (et le travail cron ne sera exécuté que certbotsi systemd n’est pas actif, de sorte que les deux ne sont pas en cours d’exécution).

minuterie systemd

Vous pouvez vérifier vos timers systemd en utilisant la commande systemctl list-timers(ou systemctl list-timers --allsi vous voulez aussi afficher les timers inactifs). Quelque chose comme ça:

% 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

Le temporisateur certbot devrait être ici /lib/systemd/system/certbot.timeret il exécutera la commande spécifiée dans/lib/systemd/system/certbot.service

certbot.timer exécutera le service `certbot.service à midi et à midi, après un délai aléatoire maximum de 12 heures (43 200 secondes).

# 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

et certbot.serviceexécutera la commande renew.

# 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

Comme d’autres l’ont mentionné, un travail cron est également installé dans /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

C'est faire:

• test -x /usr/bin/certbot -a \! -d /run/systemd/system- vérifie s'il /usr/bin/certbots'agit d'un fichier exécutable et qu'il ne/run/systemd/system s'agit pas d' un répertoire. Continuez au bit suivant uniquement si cette vérification aboutit.
  • La partie systemd de la vérification signifie effectivement que si systemd est en cours d'exécution, n'exécutez pas certbot à partir du travail cron - laissez cela à la minuterie.
• perl -e 'sleep int(rand(43200))' - dormir une quantité aléatoire entre 0 secondes et 12 heures (43200 = 12 x 60 x 60).
• certbot -q renewvérifiez vos certificats et renouvelez-en si nécessaire. Le -qdrapeau est "silencieux" - ne produit aucune sortie sauf s’il ya une erreur.

À l'origine, le travail cron m'avait dérouté car il ne s'exécutait pas à cause de systemd, comment exécuter certbot? J'ai trouvé la réponse dans ce post sur le forum et c'est ce sur quoi j'ai basé cette réponse.

Pour le renouvellement du certificat LetsEncrypt, j'utilise généralement getssl . C'est un wrapper de shell très pratique qui peut même installer un certificat sur d'autres machines via une connexion SSH.

L'entrée cron est la suivante:

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

Comme déjà suggéré, vous devriez l'exécuter quotidiennement ou, mieux encore, deux fois par jour.

Comme déjà mentionné par glaux:

Remarque: si vous configurez un travail cron ou systemd, nous vous recommandons de l'exécuter deux fois par jour (il ne fera rien tant que vos certificats ne doivent pas être renouvelés ou révoqués, mais l'exécuter régulièrement donnerait à votre site une chance de rester. en ligne au cas où une révocation initiée par Let's Encrypt s’est produite pour une raison quelconque). Veuillez sélectionner une minute au hasard dans l'heure pour vos tâches de renouvellement.

Source: https://certbot.eff.org/all-instructions/#debian-8-jessie-apache

Donc, j'ai fini par l'utiliser (la course a lieu deux fois par jour, à 01h00 et à 13h00 tous les jours):

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

ou même mieux:

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

Je n'ai pas testé mais cela devrait marcher aussi:

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

Les crochets - pre-hook et --post-hook fonctionnent avant et après chaque tentative de renouvellement. Si vous voulez que votre hook ne fonctionne qu'après un renouvellement réussi, utilisez --renew-hook dans une commande comme celle-ci.

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

C'est ce que j'utilise:

/opt/letsencrypt/letsencrypt-auto renew

donne la sortie comme:

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)

Et c'est en disant que Apache est déjà redémarré, donc pas besoin de le refaire. Si je le lance à nouveau:

Cert not yet due for renewal

donc ce n'est pas un problème de renouveler le certificat quotidiennement, mon cron est alors:

@daily /opt/letsencrypt/cronautorenew.sh

J'utilise un script pour modifier la journalisation en fichier séparé, voici donc mon fichier 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

D'autres membres ont déjà fourni des réponses beaucoup plus détaillées. Mais on dirait que je devrais le mentionner ici.

A partir de la version 0.21.1 de certbot, l' --renew-hookindicateur est remplacé par --deploy-hook Assurez-vous que vous n'utilisez pas l'indicateur obsolète.

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

Selon le guide certbot EFF

De nombreuses distributions Linux fournissent un renouvellement automatique lorsque vous utilisez les packages installés via leur gestionnaire de packages système.

Si vous ne savez pas si cela est déjà automatisé sur votre système, vérifiez la crontab de votre système (généralement, in /etc/crontab/et /etc/cron.*/* $ crontab -land systemd timers $ systemctl list-timers .