Cron job per crittografare il rinnovo

È questo il modo corretto di impostare cron per il rinnovo di Let's Encrypt cert in Apache2? Uso Ubuntu 16.04.

@monthly letsencrypt renew && service apache2 reload

Il mensile non è abbastanza frequente. Questo script dovrebbe essere eseguito almeno settimanalmente e preferibilmente ogni giorno. Ricorda che i certificati non vengono rinnovati a meno che non siano prossimi alla scadenza, e mensilmente farebbero scadere occasionalmente i certificati esistenti prima che vengano rinnovati.

Il nome del programma è certbot, da cui è stato rinominato letsencrypt. Se stai ancora utilizzando letsencrypt, devi eseguire l'aggiornamento alla versione corrente.

A parte questi problemi, è quasi lo stesso dei miei lavori cron.

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

Si noti che in 18.04 LTS il pacchetto letsencrypt è stato (finalmente) rinominato in certbot. Ora include un timer di sistema che è possibile abilitare per pianificare i rinnovi di certbot, con systemctl enable certbot.timere systemctl start certbot.timer. Tuttavia, Ubuntu non ha fornito un modo per specificare gli hook. Dovrai impostare un override per certbot.serviceeseguire l'override ExecStart=con la riga di comando desiderata, fino a quando Ubuntu non lo risolverà.

Non ho abbastanza reputazione per commentare, quindi risponderò qui. Di recente (ottobre 2017) ho installato ed eseguito certbot su un server Ubuntu 16.04 e un processo cron di rinnovo è stato creato automaticamente in /etc/cron.d/certbot.

Ecco il cron job che è stato creato:

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

Sarebbe una buona idea verificare se questo file esiste già prima di creare una voce crontab.

La documentazione di certbot consiglia di eseguire lo script due volte al giorno:

Nota:

se stai impostando un lavoro cron o systemd, ti consigliamo di eseguirlo due volte al giorno (non farà nulla fino a quando i tuoi certificati non sono dovuti per il rinnovo o la revoca, ma eseguirlo regolarmente darebbe al tuo sito la possibilità di rimanere online in caso una revoca avviata da Let's Encrypt è avvenuta per qualche motivo). Seleziona un minuto casuale entro un'ora per le tue attività di rinnovo.

Come menziona Michael Hampton, il nome è stato cambiato in certbot, ma forniscono comunque l'opzione -auto che si mantiene aggiornata. Il certbot-autocomando necessita dei privilegi di root per essere eseguito, quindi la riga nel tuo script cron dovrebbe assomigliare a questa:

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

Nel mio caso lo certbot-autoscript viene inserito nella home directory dell'utente git. Il comando esatto è quindi

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

Si noti che l'esempio nella documentazione corrisponde a un percorso relativo, come indicato dal punto che può essere fonte di confusione:

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

Assicurati di eseguire nuovamente il comando rinnovo in una shell per testare il percorso, se il certificato non è dovuto per il rinnovo non accadrà nulla (esegui questo test senza il --quietflag per vedere cosa sta succedendo).

Non è strettamente necessario ricaricare il server quando il certificato viene rinnovato in questo modo, poiché il percorso del certificato live non cambia se impostato correttamente.

Questo è vero se stai eseguendo apache - per nginx, considera l'aggiunta di un hook di rinnovo, come:

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

Non dovresti impostare nulla. Qualsiasi recente installazione Debian / Ubuntu di certbot dovrebbe installare un timer systemd e un processo cron (e il processo cron verrà eseguito solo certbotse systemd non è attivo, quindi non si ottiene entrambi in esecuzione).

timer di sistema

Puoi controllare i tuoi timer di sistema usando il comando systemctl list-timers(o systemctl list-timers --allse vuoi anche mostrare timer inattivi). Qualcosa come questo:

% 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

Il timer certbot dovrebbe essere qui /lib/systemd/system/certbot.timered eseguirà il comando specificato in/lib/systemd/system/certbot.service

certbot.timer eseguirà `certbot.service alle 12:00 e alle 12:00, dopo un ritardo casuale fino a 12 ore (43200 secondi).

# 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

ed certbot.serviceeseguirà il comando rinnova.

# 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

Come altri hanno già detto, c'è anche un cron job installato in /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

Questo sta facendo:

• test -x /usr/bin/certbot -a \! -d /run/systemd/system- controlla se /usr/bin/certbotè un file eseguibile e che non/run/systemd/system è una directory. Continuare al bit successivo solo se questo controllo ha esito positivo.
  • La parte del controllo di systemd significa effettivamente che se systemd è in esecuzione, non eseguire certbot dal processo cron, ma lasciarlo al timer.
• perl -e 'sleep int(rand(43200))' - dormire una quantità casuale tra 0 secondi e 12 ore (43200 = 12 x 60 x 60).
• certbot -q renewcontrolla i tuoi certificati e rinnovali se necessario. Il -qflag è "silenzioso" - non produce alcun output se non si verifica un errore.

Inizialmente ero un po 'confuso dal cron job poiché non sarebbe stato eseguito a causa di systemd, quindi come sarebbe stato eseguito il certbot? Ho trovato la risposta in questo post del forum su cui ho basato questa risposta.

Per il rinnovo del certificato LetsEncrypt, generalmente utilizzo getsl . È un involucro shell molto utile che può anche installare il certificato su altre macchine tramite connessione SSH.

La voce cron è la seguente:

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

Come già suggerito, dovresti eseguirlo ogni giorno o, ancora meglio, due volte al giorno.

Come già accennato da glaux:

Nota: se stai impostando un lavoro cron o systemd, ti consigliamo di eseguirlo due volte al giorno (non farà nulla fino a quando i tuoi certificati non sono dovuti per il rinnovo o la revoca, ma eseguirlo regolarmente darebbe al tuo sito la possibilità di rimanere online nel caso in cui una revoca avviata da Let's Encrypt sia avvenuta per qualche motivo). Seleziona un minuto casuale entro un'ora per le tue attività di rinnovo.

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

Quindi ho finito per usarlo (la corsa è due volte al giorno, alle 01:00 e alle 13:00 tutti i giorni):

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

o anche meglio:

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

Non ho testato, ma dovrebbe funzionare anche:

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

I ganci --pre-hook e --post-hook funzionano prima e dopo ogni tentativo di rinnovo. Se vuoi che il tuo hook venga eseguito solo dopo un rinnovo riuscito, usa --renew-hook in un comando come questo.

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

Questo è quello che uso:

/opt/letsencrypt/letsencrypt-auto renew

dà output come:

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 sta dicendo che Apache è già stato riavviato, quindi non è necessario rifarlo di nuovo. Se lo eseguo di nuovo:

Cert not yet due for renewal

quindi non è un problema rinnovare il certificato quotidianamente, il mio cron è quindi:

@daily /opt/letsencrypt/cronautorenew.sh

Uso lo script per modificare la registrazione per separare il file, quindi ecco il mio 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

Altri membri hanno già fornito risposte molto più dettagliate. Ma sembra che dovrei menzionarlo qui.

A partire dalla versione certbot il --renew-hookflag 0.21.1 è stato modificato in --deploy-hook Assicurarsi che non si stia utilizzando il flag deprecato.

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

Secondo la guida EFF certbot

Molte distribuzioni Linux forniscono il rinnovo automatico quando si utilizzano i pacchetti installati tramite il loro gestore di pacchetti di sistema.

Se non siete sicuri se il vostro sistema è già presente automatizzato, controllare il sistema di crontab (tipicamente in /etc/crontab/e /etc/cron.*/* $ crontab -le timer systemd $ systemctl list-timers .