Cron trabajo para vamos a cifrar la renovación

¿Es esta la forma correcta de configurar cron para la renovación del certificado Let's Encrypt en Apache2? Yo uso Ubuntu 16.04.

@monthly letsencrypt renew && service apache2 reload

Mensualmente no es lo suficientemente frecuente. Este script debe ejecutarse al menos semanalmente, y preferiblemente diariamente. Recuerde que los certificados no se renuevan a menos que estén a punto de caducar, y mensualmente ocasionaría que sus certificados existentes ya vencen ocasionalmente antes de que se renueven.

El nombre del programa es certbot, cuyo nombre se cambió letsencrypt. Si todavía está usando letsencrypt, debe actualizar a la versión actual.

Aparte de esos problemas, es casi lo mismo que mis trabajos cron.

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

Tenga en cuenta que en 18.04 LTS el paquete letsencrypt ha sido (finalmente) renombrado a certbot. Ahora incluye un temporizador systemd que puede habilitar para programar renovaciones de certbot, con systemctl enable certbot.timery systemctl start certbot.timer. Sin embargo, Ubuntu no proporcionó una forma de especificar ganchos. Tendrá que configurar una anulación para certbot.serviceanular ExecStart=con su línea de comando deseada, hasta que Ubuntu solucione esto.

No tengo suficiente reputación para comentar, así que responderé aquí. Recientemente (octubre de 2017) instalé y ejecuté certbot en un servidor Ubuntu 16.04 y se creó automáticamente un trabajo cron de renovación /etc/cron.d/certbot.

Aquí está el trabajo cron que se creó:

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

Sería una buena idea verificar si este archivo ya existe antes de crear una entrada crontab.

La documentación de certbot recomienda ejecutar el script dos veces al día:

Nota:

si está configurando un trabajo cron o systemd, le recomendamos ejecutarlo dos veces al día (no hará nada hasta que sus certificados se renueven o se revoquen, pero ejecutarlo regularmente le daría a su sitio la oportunidad de permanecer en línea en caso, por alguna razón, se produjo una revocación iniciada por Let's Encrypt). Seleccione un minuto aleatorio dentro de la hora para sus tareas de renovación.

Como Michael Hampton menciona, el nombre ha cambiado a certbot, pero aún proporcionan la opción -auto que se mantiene actualizada. El certbot-autocomando necesita privilegios de root para ejecutarse, por lo que la línea en su secuencia de comandos cron debería verse así:

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

En mi propio caso, el certbot-autoscript se coloca en el directorio de inicio del usuario git. El comando exacto es entonces

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

Tenga en cuenta que el ejemplo en la documentación corresponde a una ruta relativa, como lo indica el punto que puede ser confuso:

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

Asegúrese de probar el comando de renovación en un shell de antemano para probar la ruta, si el certificado no se debe renovar, no sucederá nada (ejecute esta prueba sin la --quietbandera para ver qué está sucediendo).

No es estrictamente necesario recargar el servidor cuando el certificado se renueva de esta manera, ya que la ruta al certificado en vivo no cambia si se configura correctamente.

Esto es cierto si está ejecutando apache: para nginx, considere agregar un gancho de renovación, como:

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

No deberías tener que configurar nada. Cualquier instalación reciente de Debbot / Ubuntu de certbot debe instalar un temporizador systemd y un trabajo cron (y el trabajo cron solo se ejecutará certbotsi systemd no está activo, por lo que no puede ejecutar ambos).

temporizador systemd

Puede verificar sus temporizadores systemd usando el comando systemctl list-timers(o systemctl list-timers --allsi también desea mostrar temporizadores inactivos). Algo como esto:

% 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

El temporizador certbot debe estar aquí /lib/systemd/system/certbot.timery ejecutará el comando especificado en/lib/systemd/system/certbot.service

certbot.timer ejecutará el `certbot.service a las 12 a.m. y a las 12 p.m., después de un retraso aleatorio de hasta 12 horas (43200 segundos).

# 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

y certbot.serviceejecutará el comando de renovación.

# 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

trabajo cron

Como otros han mencionado, también hay un trabajo cron instalado en /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

Esto esta haciendo:

• test -x /usr/bin/certbot -a \! -d /run/systemd/system- compruebe si /usr/bin/certbotes un archivo ejecutable y que no/run/systemd/system es un directorio. Solo continúe al siguiente bit si esta verificación tiene éxito.
  • La parte systemd de la verificación efectivamente significa que si systemd se está ejecutando, no ejecute certbot desde el trabajo cron, déjelo al temporizador.
• perl -e 'sleep int(rand(43200))' - Dormir una cantidad aleatoria entre 0 segundos y 12 horas (43200 = 12 x 60 x 60).
• certbot -q renewrevise sus certificados y renueve cualquiera si es necesario. El -qindicador es "silencioso": no produzca ningún resultado a menos que haya un error.

Originalmente estaba confundido por el trabajo cron, ya que no se iba a ejecutar debido a systemd, entonces, ¿cómo se ejecutaría certbot? Encontré la respuesta en esta publicación del foro, en la que basé esta respuesta.

Para la renovación del certificado LetsEncrypt, generalmente uso getssl . Es un envoltorio de shell muy útil que incluso puede instalar certificados en otras máquinas a través de una conexión SSH.

La entrada cron es la siguiente:

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

Como ya se sugirió, debe ejecutarlo diariamente o, mejor aún, dos veces al día.

Como ya lo mencionó glaux:

Nota: si está configurando un trabajo cron o systemd, le recomendamos que lo ejecute dos veces al día (no hará nada hasta que se renueven o revoquen sus certificados, pero ejecutarlo regularmente le daría a su sitio la oportunidad de quedarse en línea en caso de que se produzca una revocación iniciada por Let's Encrypt por alguna razón). Seleccione un minuto aleatorio dentro de la hora para sus tareas de renovación.

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

Así que terminé usando esto (correr dos veces al día, a la 01:00 y a las 13:00 todos los días):

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

o mejor:

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

No probé pero esto también debería funcionar:

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

Los ganchos de preenganche y de enganche se ejecutan antes y después de cada intento de renovación. Si desea que su enlace se ejecute solo después de una renovación exitosa, use --renew-hook en un comando como este.

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

Esto es lo que uso:

/opt/letsencrypt/letsencrypt-auto renew

da salida como:

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)

Y dice que apache ya se ha reiniciado, por lo que no es necesario volver a hacerlo. Si lo ejecuto nuevamente:

Cert not yet due for renewal

por lo tanto, no es problema renovar el certificado diariamente, mi cron es entonces:

@daily /opt/letsencrypt/cronautorenew.sh

Utilizo script para ajustar el registro para separar el archivo, así que aquí está mi 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

Otros miembros ya proporcionaron respuestas mucho más detalladas. Pero parece que debería mencionarlo aquí.

A partir de la versión 0.21.1 de certbot, el --renew-hookindicador se cambia a --deploy-hook Asegúrese de que no está utilizando un indicador obsoleto.

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

De acuerdo con la guía EFF certbot

Muchas distribuciones de Linux proporcionan una renovación automática cuando utiliza los paquetes instalados a través de su administrador de paquetes del sistema.

Si no está seguro de si o no su sistema ha esto ya automatizado, el cheque de su sistema crontab (típicamente en /etc/crontab/y /etc/cron.*/* $ crontab -ly temporizadores systemd $ systemctl list-timers .