Trabalho Cron para criptografar a renovação

Esta é a maneira correta de definir o cron para a renovação do certificado Let's Encrypt no Apache2? Eu uso o Ubuntu 16.04.

@monthly letsencrypt renew && service apache2 reload

Mensalmente não é frequente o suficiente. Esse 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 perto do vencimento, e mensalmente causaria que seus certificados existentes ocasionalmente expirem antes de serem renovados.

O nome do programa é certbotrenomeado de letsencrypt. Se você ainda estiver usando letsencrypt, 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"

Note que no 18.04 LTS o pacote letsencrypt foi (finalmente) renomeado para certbot. Agora inclui um timer do sistema que você pode ativar para agendar renovações de certbot, 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é o Ubuntu corrigir isso.

Como não tenho reputação suficiente para comentar, responderei aqui. 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 trabalho cron 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 esse arquivo já existe antes de criar uma entrada crontab.

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

Nota:

se você estiver configurando um trabalho cron ou systemd, recomendamos executá-lo duas vezes por dia (ele não fará nada até que seus certificados devam ser renovados ou revogados, mas a execução regularmente daria ao seu site a chance de ficar on-line em caso uma revogação iniciada com Let's Encrypt tenha ocorrido por algum motivo). Selecione um minuto aleatório dentro de uma 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; portanto, a linha no seu script cron deve se parecer com isso:

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

No meu caso, o certbot-autoscript é colocado no diretório inicial do usuário do git. 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 executar previamente o comando de renovação em um shell para testar o caminho, se o certificado não estiver sendo renovado, nada acontecerá (execute esse teste sem o --quietsinalizador para ver o que está acontecendo).

Não é estritamente necessário recarregar o servidor quando o certificado for 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 o nginx, considere adicionar um gancho de renovação, como:

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

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

temporizador systemd

Você pode verificar os temporizadores do sistema usando o comando systemctl list-timers(ou systemctl list-timers --allse também deseja mostrar os 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 cronômetro do certbot deve estar aqui /lib/systemd/system/certbot.timere ele executará o comando especificado em/lib/systemd/system/certbot.service

certbot.timer executará o `certbot.service às 12 e às 12 horas, 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 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

trabalho cron

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

Isto 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. Continue no próximo bit se essa 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 da tarefa cron - deixe isso para o cronômetro.
• perl -e 'sleep int(rand(43200))' - durma 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 é "silencioso" - não produza saída, a menos que haja um erro.

Eu estava originalmente confuso com o trabalho cron, pois ele não seria executado devido ao systemd, então como o certbot seria executado? Encontrei a resposta nesta postagem do fórum, na qual baseei essa resposta.

Para a renovação do certificado LetsEncrypt, geralmente uso o getsl . É um invólucro muito útil que pode até instalar o certificado 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 por dia.

Como já mencionado pelo glaux:

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

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

Então acabei usando isso (a execução é 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"

Não testei, mas isso também deve 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"

- os ganchos pré-gancho e - pós-gancho são executados antes e depois de cada tentativa de renovação. Se você deseja 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

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, portanto, não é necessário fazer isso novamente. Se eu executá-lo novamente:

Cert not yet due for renewal

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

@daily /opt/letsencrypt/cronautorenew.sh

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

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

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

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

De acordo com o guia EFF certbot

Muitas distribuições Linux fornecem renovação automatizada quando você usa os pacotes instalados por meio do gerenciador de pacotes do sistema.

Se você não tem certeza se deve ou não o seu sistema tem isso já automatizado, verifique do seu sistema crontab (normalmente em /etc/crontab/e /etc/cron.*/* $ crontab -le temporizadores Systemd $ systemctl list-timers .