Cron job para vamos criptografar a renovação

Mensal não é frequente o suficiente.

Este script deve ser executado pelo menos semanalmente e, de preferência, diariamente. Lembre-se de que os certificados não são renovados a menos que estejam próximos do vencimento, e mensalmente pode fazer com que seus certificados existentes expirem ocasionalmente antes de serem renovados.

O nome do programa é certbot, que foi renomeado de letsencrypt. Se você ainda estiver usando letsencrypto , precisará atualizar para a versão atual.

Além desses problemas, é quase o mesmo que meus trabalhos cron.

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

Nota: em 18.04 LTS, o letsencryptpacote foi (finalmente) renomeado para certbot. Agora inclui um systemdcronômetro que você pode habilitar para agendar certbotrenovações, com systemctl enable certbot.timere systemctl start certbot.timer. No entanto, o Ubuntu não forneceu uma maneira de especificar ganchos. Você precisará configurar uma substituição para certbot.servicesubstituir ExecStart=com a linha de comando desejada, até que a Canonical corrija isso.

Recentemente (outubro de 2017) instalei e executei o certbot em um servidor Ubuntu 16.04 e um trabalho cron de renovação foi criado automaticamente no /etc/cron.d/certbot.

Aqui está o cron job que foi criado:

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

Seria uma boa ideia verificar se este arquivo já existe antes de criar uma entrada crontab.

A documentação do certbot recomenda executar o script duas vezes por dia:

Observação:

se você estiver configurando um trabalho cron ou systemd, recomendamos executá-lo duas vezes por dia (não fará nada até que seus certificados sejam renovados ou revogados, mas executá-lo regularmente daria ao seu site a chance de permanecer online em caso uma revogação iniciada pelo Let's Encrypt tenha acontecido por algum motivo). Selecione um minuto aleatório dentro da hora para suas tarefas de renovação.

Como Michael Hampton menciona, o nome mudou para certbot, mas eles ainda fornecem a opção -auto que se mantém atualizada. O certbot-autocomando precisa de privilégios de root para ser executado, então a linha em seu script cron deve ser algo assim:

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

No meu caso, o certbot-autoscript é colocado no diretório inicial do git-user. O comando exato é então

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

Observe que o exemplo na documentação corresponde a um caminho relativo, conforme indicado pelo ponto que pode ser confuso:

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

Certifique-se de testar o comando de renovação em um shell com antecedência para testar o caminho, se o certificado não estiver para renovação, nada acontecerá (execute este teste sem o --quietsinalizador para ver o que está acontecendo).

Não é estritamente necessário recarregar o servidor quando o certificado é renovado dessa maneira, pois o caminho para o certificado ativo não muda se configurado corretamente.

Isso é verdade se você estiver executando o apache - para nginx, considere adicionar um gancho de renovação, como:

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

Em um ambiente docker (editar 2020-09-18)

Embora o acima ainda seja verdadeiro até onde eu sei, se seu aplicativo estiver sendo executado em um ambiente docker, você poderá deixar que essa rede proxy cuide de todos os seus certificados - localmente e em um ambiente ativo. Não sou afiliado ao projeto, mas o uso felizmente há alguns anos e não toquei em cron (para esta tarefa) ou scripts de certbot desde então.

Ele tem o benefício adicional de forçar o tráfego através da porta 443 automaticamente (se você habilitá-lo) para que você não precise mexer na configuração do apache ou do nginx - o contêiner que atende o aplicativo da Web só precisa servir a porta 80 e o proxy cuida de o resto.

Você não deveria ter que configurar nada. Qualquer instalação recente do certbot no Debian/Ubuntu deve instalar um timer systemd e um cron job (e o cron job só será executado certbotse o systemd não estiver ativo, para que você não execute os dois).

temporizador do sistema

Você pode verificar seus cronômetros do systemd usando o comando systemctl list-timers(ou systemctl list-timers --allse também deseja mostrar cronômetros inativos). Algo assim:

% 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

O temporizador do certbot deve estar aqui /lib/systemd/system/certbot.timere executará o comando especificado em/lib/systemd/system/certbot.service

certbot.timerexecutará o `certbot.service às 12h e 12h, após um atraso aleatório de até 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

e certbot.serviceexecutará o comando de renovação.

# 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 job

Como outros já mencionaram, também há um cron job instalado em /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

Isso está fazendo:

• test -x /usr/bin/certbot -a \! -d /run/systemd/system- verifique se /usr/bin/certboté um arquivo executável e /run/systemd/systemse não é um diretório. Apenas continue para o próximo bit se esta verificação for bem-sucedida.
  • A parte systemd da verificação significa efetivamente que, se o systemd estiver em execução, não execute o certbot a partir do cron job - deixe isso para o cronômetro.
• perl -e 'sleep int(rand(43200))'- dormir uma quantidade aleatória entre 0 segundos e 12 horas (43200 = 12 x 60 x 60).
• certbot -q renewverifique seus certificados e renove-os, se necessário. O -qsinalizador é "quieto" - não produz nenhuma saída a menos que haja um erro.

Eu estava originalmente confuso com o cron job, pois ele não seria executado devido ao systemd, então como o certbot seria executado? Encontrei a resposta neste post do fórum, que é o que me baseei nesta resposta.

Outros membros já forneceram respostas muito mais detalhadas. Mas parece que eu deveria mencioná-lo aqui.

A partir da versão 0.21.1 do certbot, o --renew-hooksinalizador foi alterado para --deploy-hook Certifique-se de que não está usando o sinalizador obsoleto.

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

Para a renovação do certificado LetsEncrypt, geralmente uso getssl . É um invólucro de shell muito útil que pode até instalar certificados em outras máquinas via conexão SSH.

A entrada cron é a seguinte:

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

Como já sugerido, você deve executá-lo diariamente ou, melhor ainda, duas vezes ao dia.

Como já mencionado por gaux:

Observação: se você estiver configurando um trabalho cron ou systemd, recomendamos executá-lo duas vezes por dia (não fará nada até que seus certificados sejam renovados ou revogados, mas executá-lo regularmente daria ao seu site a chance de permanecer online caso uma revogação iniciada pelo Let's Encrypt tenha acontecido por algum motivo). Selecione um minuto aleatório dentro da hora para suas tarefas de renovação.

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

Então acabei usando isso (executar é duas vezes por dia, às 01:00 e às 13:00 todos os dias):

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

ou melhor ainda:

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

Eu não testei, mas isso deve funcionar também:

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

Os ganchos --pre-hook e --post-hook são executados antes e depois de cada tentativa de renovação. Se você quiser que seu gancho seja executado somente após uma renovação bem-sucedida, use --renew-hook em um comando como este.

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

Como o método de instalação preferencial do certbot foi modificado para snap, o caminho para o cronômetro agora é /etc/systemd/system/snap.certbot.renew.timer.

Você também pode verificar a configuração executandosystemctl show certbot.timer

Isto é o que eu uso:

/opt/letsencrypt/letsencrypt-auto renew

dá saída 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)

E está dizendo que o apache já foi reiniciado, então não há necessidade de fazê-lo novamente. Se eu executar novamente:

Cert not yet due for renewal

portanto não é problema renovar o certificado diariamente, meu cron é então:

@daily /opt/letsencrypt/cronautorenew.sh

Eu uso script para ajustar o log para separar o arquivo, então aqui está meu 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

Se o seu certificado Certbot foi obtido usando o standaloneplug-in, talvez seja necessário interromper o servidor da Web para que a renovação seja bem-sucedida. Isso pode ser feito no cron usando os operadores --pre-hooke : Documentação do Certbot .--post-hook