Differences

This shows you the differences between two versions of the page.

--- acme.sh [2025/09/20 12:51] – created - external edit 127.0.0.1
+++ acme.sh [2025/09/21 15:10] (current) – kurgan
@@ Line 8: / Line 8: @@
 Il client acme.sh non e` il client ufficiale di Let's Encrypt, e` un client di terza parte che non richiede altro che bash e wget per girare. Puo` essere eseguito anche se non si e` root, pero` dovete ricordarvi che lo script deve poter scrivere dentro la vostra webroot (o accedere alle config del vostro dns) per funzionare.
-  * Scaricare lo zip per l'installazione da  https://github.com/acmesh-official/acme.sh (o usare la copia locale qui allegata, pero` ovviamente questa e` vecchia [[attachment:acme.sh-master.zip]])
+  * Scaricare lo zip per l'installazione da  https://github.com/acmesh-official/acme.sh (o usare la copia locale qui allegata, pero` ovviamente questa e` vecchia {{ :acme.sh:acme.sh-master.zip |}})
   * Unzippare il pacchetto master.zip e portarsi dentro la directory dove avete appena unzippato la roba
   * eseguire l' installazione con il comando ''./acme.sh install''. Il risultato sara` che avete il vostro script dentro alla vostra home, sotto la directory .acme.sh/ e che in cron dell'utente dal quale avete installato verra` messa una chiamata a acme.sh per il rinnovo automatico dei certificati.
@@ Line 32: / Line 32: @@
 ===== Aggiormamento del client acme.sh =====
-Il client, una volta installato, puo` essere aggiornato col comando {{{acme.sh --upgrade}}}. Puo` anche essere messo in auto-aggiornamento con il comando ''acme.sh --upgrade --auto-upgrade''. Io pero` l'auto-aggiornamento lo eviterei.
+Il client, una volta installato, puo` essere aggiornato col comando ''acme.sh --upgrade''. Puo` anche essere messo in auto-aggiornamento con il comando ''acme.sh --upgrade --auto-upgrade''. Io pero` l'auto-aggiornamento lo eviterei.
 **Anno 2020 - 2021**: Un aggiornamento da una versione molto vecchia di Acme.sh ad una molto recente potrebbe non funzionare: il client si aggiorna correttamente senza problemi ma i certificati potrebbero avere nelle loro configurazioni dei riferimenti alle API v1 di Let's Encrypt che non sono più in uso, quindi di fatto l'aggiornamento dei certificati potrebbe fallire. Del resto aggiornare acme.sh e usare le API v2 ora è necessario, quindi non potete evitare il problema semplicemente non aggiornando nulla. La soluzione è aggiornare il client, e poi è possibile modificare la configurazione dei singoli cert eliminando i riferimenti agli URL di Let's Encrypt e poi rinnovare, oppure più semplicemente ri-emettere da capo i certificati.
@@ Line 44: / Line 44: @@
-  * Creare il certificato (anche piu` di uno, ovviamente) Ricorda che la webroot deve coincidere con l'hostname (named virtual, nel caso), altrimenti la verifica automatica fallisce. In questo esempio l'hostname mater.kurgan.org non e` un named virtual, e non ha una webroot personale, ma usa il default /var/www (/var/www/html in certe installazioni di Apache, come ad esempio centos o debian 8)
+  * Creare il certificato (anche piu` di uno, ovviamente) Ricorda che la webroot deve coincidere con l'hostname (named virtual, nel caso), altrimenti la verifica automatica fallisce. In questo esempio l'hostname mater.kurgan.org non e` un named virtual, e non ha una webroot personale, ma usa il default /var/www (/var/www/html in certe installazioni di Apache, come ad esempio centos o debian 8)<code>
-<code>
  # acme.sh --issue  -d <hostname per il cert> -w <path webroot>
  acme.sh --issue  -d mater.kurgan.org -w /var/www/
@@ Line 53: / Line 52: @@
   * verificare in cron che ci sia il renew automatico (crontab -e)
   * creare la directory /etc/letsencrypt (o quella che volete voi, per metterci i certificati che poi vanno letto dai vari demoni che li usano)
-  * eseguire il comando per mettere le chiavi dentro a /etc/letsencypt. Notare che questo comando salva i certificati dell'host e della CA concatenati (fullchain) e non il singolo certificato nel file "cer", per poter costruire la chain of trust corretta. Questo comando fra l'altro riavvia i demoni che usano i certificati. Una volta eseguito questo comando, al momento del rinnovo lo script in cron automaticamente eseguira` nuovamente questo comando, copiando i certificati e riavviando i demoni. All'atto pratico i parametri che passiamo a questo comando vengono salvati  nella configurazione di acme.sh relativa all'hostname per questo certificato, ed eseguiti automaticamente ad ogni rinnovo.
+  * eseguire il comando per mettere le chiavi dentro a /etc/letsencypt. Notare che questo comando salva i certificati dell'host e della CA concatenati (fullchain) e non il singolo certificato nel file "cer", per poter costruire la chain of trust corretta. Questo comando fra l'altro riavvia i demoni che usano i certificati. Una volta eseguito questo comando, al momento del rinnovo lo script in cron automaticamente eseguira` nuovamente questo comando, copiando i certificati e riavviando i demoni. All'atto pratico i parametri che passiamo a questo comando vengono salvati  nella configurazione di acme.sh relativa all'hostname per questo certificato, ed eseguiti automaticamente ad ogni rinnovo.<code>
-<code>
 acme.sh --installcert -d mater.kurgan.org --keypath /etc/letsencrypt/mater.kurgan.org.key --fullchainpath /etc/letsencrypt/mater.kurgan.org.cert --reloadcmd "systemctl reload apache2; systemctl reload exim4; systemctl reload dovecot"
 </code>
   * modificare le config dei vari demoni (apache, exim, dovecot nell'esempio) per leggere i certificati dai files giusti.
   * ricaricare i vari demoni
@@ Line 68: / Line 64: @@
 Questi sono alcuni dei mille comandi di acme.sh. Non garantisco che la sintassi non cambi nel tempo, acme.sh è stato oggetto di una evoluzione abbastanza veloce.
-  * Per vedere una lista dei certificati attualmente in uso:
+  * Per vedere una lista dei certificati attualmente in uso:<code>
-<code>
 acme.sh list
 </code>
-  * Per auto-aggiornare acme.sh
+  * Per auto-aggiornare acme.sh<code>
-<code>
 acme.sh upgrade
 </code>
-  * Per disattivare un certificato che non vogliamo più usare (non verra` piu` rinnovato):
+  * Per disattivare un certificato che non vogliamo più usare (non verra` piu` rinnovato):<code>
-<code>
 acme.sh --remove <nome del certificato come mostrato nella prima colonna della lista dei certificati>
 </code>
@@ Line 90: / Line 83: @@
 Il client acme.sh supporta diversi metodi, e vi consiglio di leggere la documentazione per vedere come funzionano. Ne cito tuttavia alcuni:
-  * Standalone: se non abbiamo un web server, ma possiamo tenere la 80 o la 443) aperta, possiamo dire allo script di fare lui da web server, temporaneamente, per il tempo necessario a generare il certificato (e ad ogni rinnovo)
+  * Standalone: se non abbiamo un web server, ma possiamo tenere la 80 o la 443) aperta, possiamo dire allo script di fare lui da web server, temporaneamente, per il tempo necessario a generare il certificato (e ad ogni rinnovo)<code>
-<code>
 acme.sh --issue  -d dominio.tld  --standalone
 </code>
-  * Apache: se abbiamo apache2, possiamo dire allo script di modificare la config di apache, fare la verifica, e rimetterla a posto. Questo crea ovviamente un piccolo disservizio e, potenzialmente, un disservizio lungo se lo script si incarta a meta` operazione e non rimette a posto la config di apache. (Esiste un modo equivalente per nginx)
+  * Apache: se abbiamo apache2, possiamo dire allo script di modificare la config di apache, fare la verifica, e rimetterla a posto. Questo crea ovviamente un piccolo disservizio e, potenzialmente, un disservizio lungo se lo script si incarta a meta` operazione e non rimette a posto la config di apache. (Esiste un modo equivalente per nginx)<code>
-<code>
 acme.sh --issue  -d dominio.tld --apache
 </code>
-  * DNS: Se abbiamo accesso al DNS, possiamo creare dei record TXT nella zona DNS del nostro dominio e usare quelli come verifica. E` piu` scomodo, ma una volta fatto ce ne possiamo dimenticare, e non abbiamo problemi di interferenza con Apache, Nginx, la porta 80, eccetera. Ci sono tre passaggi: creare una chiave, metterla nel dns (a mano) e poi fare l'effettiva emissione del certificato. I record TXT devono rimanere nel DNS per i futuri rinnovi.
+  * DNS: Se abbiamo accesso al DNS, possiamo creare dei record TXT nella zona DNS del nostro dominio e usare quelli come verifica. E` piu` scomodo, ma una volta fatto ce ne possiamo dimenticare, e non abbiamo problemi di interferenza con Apache, Nginx, la porta 80, eccetera. Ci sono tre passaggi: creare una chiave, metterla nel dns (a mano) e poi fare l'effettiva emissione del certificato. I record TXT devono rimanere nel DNS per i futuri rinnovi.<code>
-<code>
 acme.sh --issue --dns -d dominio.tld
 # metti nel dns i record che vengono indicati