Cron job pour le cryptage du renouvellement


93

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

6
Comme l’une des réponses ci-dessous, certbot v0.19.0 (et peut-être une version antérieure) crée déjà une entrée de crontab @/etc/cron.d/certbot
xgMz

De plus, le plugin certbot apache avec la validation tls-sni rechargera apache dans le cadre de la procédure de validation une fois le nouveau certificat récupéré.
xgMz

Vous trouverez ci-dessous une réponse très importante pour les nouvelles installations (à partir de janvier 2019): certbot ajoute automatiquement le temporisateur système et la planification des travaux cron afin que la configuration cron ne soit pas nécessaire de votre part.
Cory Robinson

Réponses:


145

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.


3
Quelle fenêtre de temps est "proche de l'expiration"?
André Figueiredo

3
Il peut être préférable d’utiliser un utilisateur --renew-hookplutôt que de --post-hookne redémarrer que si le certificat est renouvelé avec succès.
mwfearnley

6
Pour apache / httpd, certbot renew
ça

1
Je voulais juste ajouter, au lieu de remplacer ExecStart pour recharger nginx, il suffit d' ajouter une ligne de ExecStartPost à certbot.service de recharger votre serveur Web après qu'il a fait: ExecStartPost=/usr/sbin/service nginx reload. Travaillé pour moi!
JD Mallen

1
@JDMallen Utiliser ExecStartPost=est une bonne idée. Pourquoi n'y ai-je pas pensé? Mais sachez que la servicecommande est obsolète; ce ne sera pas pour toujours. Passez aux systemctlcommandes correspondantes .
Michael Hampton

56

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.


1
J'ai vu que je l'avais aussi après avoir exécuté certbot. Très sympa qui permet de chiffrer cela! C'est un très bon projet.
Bjorn

7
Il est utile de savoir que le travail cron ci-dessus ne s'exécutera pascertbot renew s'il /run/systemd/systemest présent - c'est parce qu'un minuteur systemd exécute certbot - pour en savoir plus sur certbot et les timers systemd, cliquez ici .
Hamish Downer

Merci de mentionner qu’une tâche cronjob avait déjà été installée. Je n’étais pas au courant de cela avant de lire votre message.
NilsB

1
Pour quiconque se demande, cela le fait fonctionner toutes les 12 heures. L'autre réponse le 43 6 * * *ferait courir tous les jours à 6h43. Une fois par jour devrait suffire, mais l’un ou l’autre fonctionne bien.
orrd

42

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'

1
J'aime la façon dont cela est expliqué. Il n'est pas nécessaire de détailler le redémarrage du service (cela pourrait créer un désordre si quelqu'un y fait quelque chose, en ayant une chance de se faire prendre deux fois par jour) et mentionner les privilèges nécessaires.
Gusstavv Gil 21/02/2017

4
Ce n'est pas vrai - il est nécessaire de recharger le serveur, du moins avec Nginx - nginx semble mettre en cache le certificat initial et n'enregistre pas de nouveau certificat, même si le fichier est modifié. Voir ce post pour savoir--renew-hook
comment

17

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.


1
"Vous ne devriez pas avoir à configurer quoi que ce soit" mais mon certificat a expiré récemment et j'ai installé certbot il y a environ 3 mois. /etc/cron.d/certbotexiste, systemctl list-timersmontre certbot.timer, mais mes concerts n'ont pas été renouvelés. Courir à la certbotmain a bien fonctionné, alors je ne sais pas ce qui se passe. Nous avons fini par ajouter une crontabentrée ancienne école .
Dan Dascalescu

C'est la réponse la plus à jour et la plus correcte, mais avec une réserve qui dépend de la distribution
olive_tree

"et le travail cron ne sera exécuté que si systemd n’est pas actif". Pouvez-vous nous aider à trouver un document concernant cette "préséance", expliquez-vous s'il vous plaît?
Tite

@titus, l'explication est que le travail cron exécute d'abord une commande testpour 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.
Hamish Downer

5

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.


3

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


1
"Veuillez sélectionner une minute aléatoire dans l'heure pour vos tâches de renouvellement."
Isius

1
Selon la note ci-dessus, il serait préférable de ne --renew-hookredémarrer votre serveur que lorsque le certificat est réellement renouvelé.
Que pouvait

@Isius merci, je l'ai changé pour une minute aléatoire (6).
Tadej

1
@JedatKinports: ne devrait pas le --post-hooket --renew-hookêtre à la service apache2 restartplace de service restart apache2?
Paul Ratazzi

1
La commande est service apache2 restart ! La service restart apache2commande / service n'est pas correcte.
GTodorov

1

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

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"

0

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 .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.