Let's Encrypt

Come ottenere un certificato gratuito riconosciuto dalle applicazioni, perciò senza affidarsi alle CA commerciali?
Ci viene in aiuto Let's Encrypt, Autorità di Certificazione creata da ISRG (Internet Security Research Group).
Ricordate sopra quando abbiamo elencato le CA autorizzate nel nostro sistema?
Digitiamo nuovamente:

Stavolta, scorriamo la pagina fino a mozilla/ISRG

E scopriamo che ISRG è una Autorità di Certificazione riconosciuta.

Let's Encrypt offre certificati X509 per il protocollo TLS gratuiti e la lista dei certificati rilasciati è pubblica.
Let's Encrypt usa il protocollo ACME.
Perciò, useremo un client ACME, Cerbot, fornito da uno sponsor di Let's Encrypt, EFF (Electronic Frontier Fondation).

Certbot interagisce con Let's Encrypt nella richiesta dei certificati, nel loro posizionamento all'interno del sistema, nella validazione dei domini e nella configurazione dei web servers.
Se richiesto, Cerbot può anche aggiornare automaticamente la configurazione del vostro web server e modellare la configurazione del vostro sito da HTTP a HTTPS.
Ultimo, ma non meno importante, Cerbot può provvedere automaticamente all'aggiornamento dei certificati. Questi hanno una vita di 90 giorni, ma vengono aggiornati dopo due terzi di vita, cioè 60 giorni.

Come funziona il protocollo ACME e dunque Certbot?
Il nostro mail server , con Cerbot, diventa anche un client ACME ed invia una richiesta per un certificato di un dominio alla Autorità di Certificazione: nel nostro caso Let's Encrypt, che ha il ruolo di server ACME.
Il server ACME invita il client ACME a dimostrare che è il proprietario effettivo del dominio.
Per soddisfare il server ACME, Il client pone un "token", un file specifico, sul server web.
Il server ACME richiede ai server DNS il record "A" del client ACME, ottenuto il quale, il server ACME verifica che all'indirizzo IP enunciato nel record, effettivamente c'è il token posto nel server web.
Convalidato il tutto, il server ACME emette i certificati e Cerbot li posiziona nella directory predisposta.
Perciò, è necessario che sia installato un server web nel nostro sistema e che la porta 80 del nostro router/gateway/firewall sia aperta.
Esiste anche un opzione di Cerbot (- standalone) che dispiega un suo mini web server, utile unicamente per il tempo necessario alla richiesta dei certificati. Ma tralasciamo questa opzione.

Applicazioni da installare per ottenere i certificati Let's Encrypt.

Intanto, è buona regola aggiornare il sistema: Poi, installiamo il web server Apache, Python3 e il client ACME Certbot: Così abbiamo installato cerbot e le dipendenze necessarie al suo funzionamento.

I certificati che andremo a richiedere, ci servirano in Postfix per crittografare le comunicazioni, in Dovecot per criptare le trasmissioni Imap e Pop3 e per negare ogni traffico non cifrato e in Apache2 per autenticare il dominio e salvaguardare le informazioni inviate tramite browser al server, ad esempio, moduli con campi da compilare ed inviare al server, come nelle transazioni bancarie.
Perciò, in questo momento, richiederemo un certificato con il sottodominio 'mail'.
Quando e se svilupperemo un sito web, ad esempio, www.sitoprovaprimo.it, allora richiederemo un certificato per il dominio sitoprovaprimo.it e per il suo alias www.sitoprovaprimo.it
Il nome di dominio sitoprovaprimo.it sarà usato lungo tutto il corso di questi esercizi.

Prepariamo Apache a ricevere il Token per il dominio mail.sitoprovaprimo.it
Creiamo la cartella web per il dominio:

Poi, rendiamo proprietario della cartella l'utente virtuale di Apache ed il suo gruppo di appartenenza, www-data:
Adesso, dobbiamo creare un file di configurazione per un virtual host.
I virtual hosts permettono di avere più domini e sottodomini impostati nello stesso web server.
Ad esempio, potremo avere sitoprovaprimo.it, archivio.sitoprovaprimo.it ed un altro nome di dominio sitoprovasecondo.it, sempre sul nostro web server.
Quando un utente, chiederà al nostro web server di mostrargli la pagina di sitoprovasecondo.it, Apache userà una estensione del protocollo TLS: SNI (Server Name Indication). Come abbiamo visto precedentemente, all'inizio dell'handshaking, il client indica al server il nome del dominio a cui vuole connettersi, questo prima della cifratura.
Il server può avere molti certificati TLS sullo stesso indirizzo IP e grazie a questa procedura, indirizzare la pagina web richiesta dall'utente.

Apache, in Debian, ha una cartella in cui ci sono le configurazioni dei virtual hosts:
/etc/apache2/sites-available/
In essa, ci sono due virtual hosts:
000-default.conf è il virtual host HTTP, non cifrato.
default-ssl.conf è il virtual host HTTPS, cifrato.

Tutti i file di configurazione devono avere estensione .conf

Apache ha un'altra cartella, con dei collegamenti simbolici (symlink) che puntano ai file di configurazione della cartella /etc/apache2/sites-available/ :
/etc/apache2/sites-enabled/
Con all'interno, solo il file (rinvio simbolico) del virtual host 000-default.conf

Perciò, se vogliamo creare, modificare od eliminare configurazioni di hosts virtuali, lo faremo in sites-available.
Per abilitare le modifiche, useremo due utilità di Apache:
a2ensite : apache2 enable site;
a2dissite : apache2 disable site.

Possiamo creare il nostro primo file di configurazione di Virtual Host con nano, ponendo un file con estensione .conf all'interno della cartella /etc/apache2/sites-available/

Ed inseriamo al suo interno:
Salviamo come sempre, premendo i tasti Ctrl+X, seguito da Y ed Invio.
Dobbiamo abilitare il sito, con l'app a2ensite:
Il sistema ci dice di usare un comando, ma prima dobbiamo disabilitare il sito creato dal sistema, 000-default: Adesso possiamo riavviare Apache:

Per fare funzionare il nostro primo virtual host, dobbiamo creare la nostra prima pagina html all'interno della cartella del virtual host.
Nei server web, la prima pagina di un dominio viene nominata "index" seguito dall'estensione del linguaggio usato, ad esempio: index.html, index.php. Noi useremo HTML:

Salviamo il nostro file, come sempre, con tasti Ctrl+X, seguito da Y ed Invio.
Avendo creato il file con Sudo, il proprietario del file è root.
Rendiamo proprietario del file l'utente virtuale di Apache: www-data. Abbiamo usato l'opzione Ricorsiva, così da coinvolgere la cartella e tutto i file contenuti in essa.
Inoltre, il file è stato creato con i permessi di default, cioè 644: il proprietario può leggere e scrivere, il gruppo può leggere, gli altri possono leggere. Visto che non c'è necessità che gli altri leggano il file, modifichiamo il loro permesso: L'asterisco sta a indicare qualsiasi file all'interno della cartella.
Listiamo la cartella, per vedere se effettivamente abbiamo sostituito proprietario e gruppo e se abbiamo impostato i permessi giusti:
Non ci rimane che provare a raggiungere il nostro server web.
Digitiamo nel nostro browser, il sottodominio indicato nel record DNS "A" e di cui abbiamo preparato il virtual host: mail.sitoprovaprimo.it

L'avvertimento "non sicuro" è dovuto al fatto che abbiamo implementato soltanto il protocollo HTTP, non cifrato.
Riuscendo a vedere la nostra prima pagina web, abbiamo verificato effettivamente che la porta 80 è aperta ed il web server è raggiungibile dall'esterno.

Perciò, possiamo passare alla generazione del certificato Let's Encrypt.

Le opzioni indicate a certbot sono:
certonly : richiede il certificato, ma non lo installa in Apache;
-a apache : indica che richiediamo il certificato con il plug-in di Apache, in qualità di autenticatore;
--agree-tos : accettiamo i "termini di servizio";
--staple-ocsp : per sapere se un certificato è stato revocato (anche se non scaduto), il client del certificato interroga il server OCSP ad intervalli regolari, ottendo un "segno temporale punzonato"; quando il browser chiede il certificato, se richiesto viene anche allegato il timestamp OCSP, cosicchè il browser può conoscere lo stato del certificato.

Se il procedimento fila liscio, appare una schermata così:

Otteniamo varie informazioni:
- il certificato è posto in /etc/letsencrypt/live/mail.sitoprovaprimo.it/fullchain.pem
- la chiave privata è salvata in /etc/letsencrypt/live/mail.sitoprovaprimo.it/privkey.pem

Per conoscere quali certificati sono stati ricevuti e il loro termine di scadenza, digitiamo:

Ci indica la data di fine vita del certificato.
La validità dei certificati Let's Encrypt è di 90 giorni. Solo trascorsi 60 giorni si potranno rinnovare. Se proviamo ad aggiornare prima dei 2/3 della scadenza, semplicemente non succede nulla.
Digitiamo: L'opzione -q vale per quiet, cioè rinnovo silenzioso, senza domande.

Certbot, in Debian 12, ha due file che si occupano del rinnovo dei certificati automaticamente:

/lib/systemd/system/cerbot.timer
Digitiamo:

Il file dice che Cerbot viene eseguito due volte al giorno, ad un orario casuale. Casuale per evitare i picchi concomitanti di richieste di rinnovo dei certificati.

/lib/systemd/system/cerbot.service

Ci indica cosa viene eseguito due volte al giorno: cerbot -q renew

Perciò, i certificati si aggiornano automaticamente.
Però, bisogna caricare i nuovi certificati nelle applicazioni che li usano.
Per fare ciò, cerbot in Debian12 ha tre cartelle dove possiamo dare comandi per il prima, per il dopo e per il rinnovo effettuato. Posizioniamoci nella cartella /etc/letsencrypt/renewal-hooks/ e listiamone il contenuto:

Ecco le tre cartelle:
deploy: comandi da eseguire quando il rinnovo è avvenuto effettivamente;
post: comandi da eseguire dopo il comando di rinnovo, ma anche se questo non riesce;
pre: comandi da eseguire prima della richiesta di rinnovo;
A noi, interessa la cartella deploy.

Creiamo un file in essa:

ed inseriamo:
Quando qualsiasi certificato sarà rinnovato, subito dopo, certbot eseguirà il comando indicato, cioè farà riavviare Apache.

Rendiamoci nella cartella Deploy

e diamo i permessi di esecuzione al file creato:
Listiamo il file per un controllo
Il file è eseguibile.

Se vogliamo controllare il funzionamento del file eseguibile appena creato, fermiamo Apache:
Controlliamo lo stato di Apache:
È "inactive".
Diamo esecuzione al file creato:
E ricontrolliamo lo status di Apache:
Apache è ripartito: il file funziona.

Aggiungere HTTPS ad Apache

Abbiamo tutto quanto richiesto per rendere il nostro sito autenticato con il certificato TLS.
Creiamo un nuovo file di configurazione per il web server: È nominato uguale a quello creato per HTTP, eccetto per l'aggiunta di -https , visto che servirà a creare il virtual host certificato. Ed inseriamo al suo interno:
Salviamo come sempre, premendo i tasti Ctrl+X, seguito da Y ed Invio.

Bisogna abilitare il modulo SSL di Apache, affinchè processi le richieste TLS e lo si fa con l'utilità di Apache, a2enmod : apache2 enable module

Abilitiamo anche la configurazione https del virtual host:
E riavviamo Apache, nel modo richiesto da a2enmod (restart, non reload):
Verifichiamo che non ci siano errori di configurazione:

La conferma della sintassi, ci permette l'ultimo passo: la verifica del funzionamento di HTTPS sul nostro sito.
Digitiamo nuovamente nella barra del browser l'indirizzo del dominio: mail.sitoprovaprimo.it

Ci manca solo di deviare le chiamate HTTP verso le HTTPS.
Riapriamo il file di configurazione del virtual host HTTP:

ed aggiungiamo nel file:

Salviamo il file e abilitiamo il modulo apache per riscrivere gli indirizzi:

Riavviamo Apache affinchè carichi il modulo abilitato:

Adesso anche chiamando HTTP, saremo riversati su HTTPS.

Proviamo ad aggiungere un'altro sito con dominio diverso.