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
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
Réponses:
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.timer
et 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.service
pouvoir remplacer ExecStart=
par la ligne de commande souhaitée, jusqu'à ce que Ubuntu répare cela.
--renew-hook
plutôt que de --post-hook
ne redémarrer que si le certificat est renouvelé avec succès.
certbot renew
ExecStartPost=/usr/sbin/service nginx reload
. Travaillé pour moi!
ExecStartPost=
est une bonne idée. Pourquoi n'y ai-je pas pensé? Mais sachez que la service
commande est obsolète; ce ne sera pas pour toujours. Passez aux systemctl
commandes correspondantes .
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.
certbot renew
s'il /run/systemd/system
est présent - c'est parce qu'un minuteur systemd exécute certbot - pour en savoir plus sur certbot et les timers systemd, cliquez ici .
43 6 * * *
ferait courir tous les jours à 6h43. Une fois par jour devrait suffire, mais l’un ou l’autre fonctionne bien.
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-auto
commande 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-auto
script 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' --quiet
indicateur 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 certbot
si systemd n’est pas actif, de sorte que les deux ne sont pas en cours d’exécution).
Vous pouvez vérifier vos timers systemd en utilisant la commande systemctl list-timers
(ou systemctl list-timers --all
si 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.timer
et 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.service
exé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
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/certbot
s'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.
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 renew
vérifiez vos certificats et renouvelez-en si nécessaire. Le -q
drapeau 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.
/etc/cron.d/certbot
existe, systemctl list-timers
montre certbot.timer
, mais mes concerts n'ont pas été renouvelés. Courir à la certbot
main a bien fonctionné, alors je ne sais pas ce qui se passe. Nous avons fini par ajouter une crontab
entrée ancienne école .
test
pour vérifier si systemd est actif et si c'est le cas, le travail cron se ferme immédiatement sans s'exécuter certbot
- voir le texte relatif à ce travail. Je vais éditer le texte pour être plus précis.
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.
--renew-hook
redémarrer votre serveur que lorsque le certificat est réellement renouvelé.
--post-hook
et --renew-hook
être à la service apache2 restart
place de service restart apache2
?
service restart apache2
commande / service n'est pas correcte.
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-hook
indicateur 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 -l
and systemd timers $ systemctl list-timers
.
/etc/cron.d/certbot