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
Le mensuel n'est pas assez fréquent. Ce script doit s'exécuter au moins une fois par semaine, et de préférence quotidiennement. N'oubliez pas que les certificats ne sont pas renouvelés à moins qu'ils ne soient presque arrivés à expiration, et que mensuellement, vos certificats existants expirent parfois déjà avant d'être renouvelés.
Le nom du programme est certbot
, qui a été renommé à partir de letsencrypt
. Si vous utilisez toujours letsencrypt
, vous devez effectuer la mise à jour vers la version actuelle.
Mis à part ces problèmes, c'est à peu près la même chose que mes tâches cron.
43 6 * * * certbot renew --post-hook "systemctl reload nginx"
Notez que dans 18.04 LTS, le package letsencrypt a été (enfin) renommé certbot. Il inclut désormais une minuterie systemd que vous pouvez activer pour planifier des renouvellements de certbot, avec systemctl enable certbot.timer
et systemctl start certbot.timer
. Cependant, Ubuntu n'a pas fourni de moyen de spécifier les hooks. Vous devrez configurer un remplacement pour certbot.service
pour remplacer ExecStart=
avec la ligne de commande souhaitée, jusqu'à ce qu'Ubuntu corrige cela.
Je n'ai pas assez de réputation pour commenter, alors je vais répondre ici. J'ai récemment (octobre 2017) installé et exécuté certbot sur un serveur Ubuntu 16.04 et une tâche cron de renouvellement a été créée 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 crontab.
documentation 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 seront pas renouvelés ou révoqués, mais l'exécuter régulièrement donnerait à votre site une chance de rester en ligne dans cas où une révocation initiée par Let's Encrypt s'est produite pour une raison quelconque). Veuillez sélectionner une minute aléatoire dans l'heure pour vos tâches de renouvellement.
Comme Michael Hampton le mentionne, le nom a changé pour certbot, mais ils fournissent toujours l'option -auto qui se tient à jour. La commande certbot-auto
A besoin des privilèges root pour s'exécuter, donc la ligne de votre script cron devrait ressembler à ceci:
52 0,12 * * * root /full/path/to/certbot-auto renew --quiet
Dans mon cas, le script certbot-auto
Est placé dans le répertoire personnel de git-user. 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 être déroutant:
./path/to/certbot-auto renew --quiet
Assurez-vous de tester au préalable la commande de renouvellement dans un shell pour tester le chemin, si le certificat n'est pas dû pour le renouvellement, rien ne se passera (exécutez ce test sans l'indicateur --quiet
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 correctement configuré.
Cela est vrai si vous exécutez Apache - pour nginx, pensez à ajouter un crochet de renouvellement, tel que:
52 0,12 * * * root certbot renew --renew-hook 'service nginx reload'
Vous ne devriez rien avoir à configurer. Toute installation récente de certbot dans Debian/Ubuntu doit installer un minuteur systemd et un travail cron (et le travail cron ne s'exécutera que certbot
si systemd n'est pas actif, donc vous ne faites pas fonctionner les deux).
Vous pouvez vérifier vos temporisateurs systemd en utilisant la commande systemctl list-timers
(Ou systemctl list-timers --all
Si vous souhaitez également afficher les temporisateurs 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 minuteur certbot doit être ici /lib/systemd/system/certbot.timer
Et il exécutera la commande spécifiée dans /lib/systemd/system/certbot.service
certbot.timer
Exécutera le `certbot.service à 12 h et 12 h, après un délai aléatoire pouvant aller jusqu'à 12 heures (43200 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.service
exécutera la commande de renouvellement.
# 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
Comme d'autres l'ont mentionné, une tâche cron est également installée 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
Cela fait:
test -x /usr/bin/certbot -a \! -d /run/systemd/system
- vérifiez si /usr/bin/certbot
Est un fichier exécutable et que /run/systemd/system
N'est pas un répertoire. Passez au bit suivant uniquement si cette vérification réussit. Perl -e 'sleep int(Rand(43200))'
- sommeil un nombre aléatoire entre 0 secondes et 12 heures (43200 = 12 x 60 x 60).certbot -q renew
Vérifiez vos certificats et renouvelez-les si nécessaire. Le drapeau -q
Est "silencieux" - ne produit aucune sortie sauf en cas d'erreur.J'étais à l'origine confus par le travail cron car il n'allait pas s'exécuter en raison de systemd, alors comment serait exécuté certbot? J'ai trouvé la réponse dans cet article du forum sur lequel j'ai basé cette réponse.
Pour le renouvellement de certificat LetsEncrypt, j'utilise généralement getssl . Il s'agit d'un wrapper 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 devez 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 seront pas 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 se produirait pour une raison quelconque). Veuillez sélectionner une minute aléatoire dans l'heure pour vos tâches de renouvellement.
Source: https://certbot.eff.org/all-instructions/#debian-8-jessie-Apache
J'ai donc fini par l'utiliser (courir deux fois par jour, à 01h00 et à 13h00 tous les jours):
6 1,13 * * * certbot renew --post-hook "service Apache2 restart"
ou encore mieux:
6 1,13 * * * certbot renew --renew-hook "service Apache2 restart"
Je n'ai pas testé mais cela devrait aussi fonctionner:
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 souhaitez que votre hook ne s'exécute qu'après un renouvellement réussi, utilisez --renew-hook dans une commande comme celle-ci.
D'autres membres ont déjà fourni des réponses beaucoup plus détaillées. Mais il me semble que je devrais le mentionner ici.
Depuis la version 0.21.1 de certbot --renew-hook
le drapeau est changé en --deploy-hook
Assurez-vous que vous n'utilisez pas l'indicateur obsolète.
certbot renew --deploy-hook "systemctl restart myservice"
Voici 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 il est dit qu'Apache est déjà redémarré, donc pas besoin de le refaire. Si je le lance à nouveau:
Cert not yet due for renewal
donc pas de problème pour renouveler le certificat quotidiennement, mon cron c'est alors:
@daily /opt/letsencrypt/cronautorenew.sh
J'utilise un script pour modifier la journalisation dans un fichier séparé, voici donc mon 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
Selon guide certbot EFF
De nombreuses distributions Linux offrent un renouvellement automatisé lorsque vous utilisez les packages installés via leur gestionnaire de packages système.
Si vous ne savez pas si votre système a déjà cela automatisé, vérifiez la crontab de votre système (généralement dans /etc/crontab/
et /etc/cron.*/*
$ crontab -l
et minuteries systemd $ systemctl list-timers
.