Lezione: Certificati SSL

9. Certificati SSL

9.1. SSL: premessa

L’avvento di internet avvenne sull’onda di una grande fiducia nell’onesta e bontà di tutti e di tutto. Successivamente ci si è accorti (dolorosamente) che non tutti sono buoni. Inoltre si è preso consapevolezza che le grandi potenzialità offerte dalla rete possono non essere positive.

Da qui è nato il concetto di connessioni sicure e criptate. Più recentemente questo aspetto di sicurezza e di privacy ha fatto un ulteriore passo in avanti introducendo il concetto e la pratica dello “zero trust”.

In merito alle connessioni internet fino al 2014 tutti i siti offrivano la sola connessione HTTP: leggera, fa bene il suo lavoro, ma è totalmente trasparente e di conseguenza pericolosa. Solo i siti di banche, negozi online, ecc… offrivano connessioni HTTPS.

L’HTTPS è la stessa cosa dell’HTTP, ma tutto quello che transita sulla rete viene criptato. Il primo approccio, fatto tramite una tecnica nota come SSL, è stato aggiornato nel 2020, e si usa attualmente un tecnica nota come TLS.

Dal 2020 le connessioni HTTP non sono più accettate per accordo tecnico tra le aziende e per regolamenti di sicurezza ICT. Funzionano e si possono usare solo a scopo didattico e all’interno di reti locali private a scopo di laboratorio.

Da sottolineare, per completezza e per correttezza, che in questa evoluzione non ci sono stati obblighi legali, ma tutto è avvenuto come uno sviluppo per progressive scelte aziendali (anche di concerto tra più aziende) che hanno spinto rendendo di fatto standard l’HTTPS e il TLS. Un’evoluzione decisamente positiva.

Indipendentemente dall’evoluzione il principio e la meccanica non sono cambiati. Questo sistema di sicurezza e criptazione funziona sul seguente meccanismo di principio:

il serve ha al suo interno la metà di una chiave digitale;
il cliente (ovvero il programma di web browsing) ha al suo interno l’altra metà della chiave digitale;
al momento della connessione entra in gioco un terzo attore che sta in internet. Questo attore (detto in gergo CA, Certification Authority) viene interpellato e verifica le chiavi e le credenziali di tutti gli attori;
dopo una invisibile e veloce prima fase di verifica (detta handshake), viene creato un tunnel criptato di comunicazione e si naviga in internet in modo sicuro e confidenziale.
Se qualcosa non collima il browser ci mostra una pagina di allarme e rimette all’utente la decisione di procedere o meno.
Se non collima nulla la navigazione a quell’URL non sarà possibile.

In questo meccanismo per stabile connessioni sicure sono fondamentali tre elementi:

FQDN (Fully Qualified Domain Name): il nome internet del server (ovvero l’URL) deve esistere ed essere pubblica (ovvero registrata sui DNS mondiali);
certificato Server: il server deve avere al suo interno un file di certificato valido e in corso di validità;
certificato client: il browser deve avere al suo interno un file di certificato valido e in corso di validità.

Da questa premessa possiamo capire l’importanza dell’HTTPS e del suo impatto bloccante e di cosa abbiamo bisogno per poter avere un certificato TLS per il nostro server.

9.2. SSL e TLS; cosa sono

Nella premessa sopra abbiamo detto che TLS (Transport Layer Security) è, di fatto, l’evoluzione di SSL.

Si tratta di una tecnologia per creare connessioni criptate , sicure e garantite:

criptate: il traffico viene codificato. Se qualcuno intercetta la comunicazione non può decodificarla;
integrità dei dati: il protocollo prevede un sistema di controllo dei dati individuando e correggendo eventuali errori di trasmissione e impedendo l’interpolazione;
garantite: si tratta di un’estensione del concetto di sicurezza. Tramite la CA l’utente riceve conferma che il server è veramente chi dice di essere.

Inoltre il meccanismo di generazione e gestione dei certificati prevede anche uno storico dei certificati scaduti e/o revocati. Pertanto è possibile verificare a chi apparteneva un certificato scaduto e verificare se un certificato in corso di validità è stato revocato.

Dietro le quinte c’è stato anche un importante avanzamento di unificazione e uniformazione. Lo stesso protocollo che ci permette di navigare sicuri è implementato nelle email, nelle PEC, nelle REM e nelle nostre connessioni SSH.

In pratica, oltre agli aspetti tecnici che ci permettono di usare una sola tecnologia, potremmo dotare il nostro server privato di un unico certificato wildcard che garantirà tutti i servizi.

9.3. SSL: acquisto da un provider

Nel caso di acquisto di un web hosting il pacchetto prevede anche il certificato TLS per la connessione HTTPS.

Se abbiamo comprato anche il servizio email il provider potrebbe emettere un unico certificato che garantisce e securizza sia il web server che il sistema di email.

È importante che durante la creazione dell’account sul provider, al momento della compilazione delle form con i dati dell’identità e i dati fiscali, abbiamo inserito dati esatti e corretti perché alcuni andranno nei certificati indicando chi è il proprietario e chi è il responsabile. Se i dati non sono corretti potremmo avere un errore di attendibilità del certificato anche se è tecnicamente perfetto.

Nel caso di acquisto di un VPS il provider non genera nessun certificato. Dobbiamo provvedere noi ad acquistare uno.

Abbiamo due scelte possibili:

acquistarne un certificato da un provider;
prenderne uno gratuito da Let’s Encrypt.

Nel primo caso, accanto al pagamento, abbiamo l’onere di dover generare un primo certificato che verrà poi firmato e garantito dalla CA. inoltre questa forma di acquisto aggiunge una durata maggiore del certificato e la possibilità di avere certificati più estensivi (quindi soluzioni wildcard, chiavi per i supporti di memoria, chiavi per sistemi di identificazione come le tessere magnetiche e/o con chip, ecc..).

Nel caso di acquisto teniamo presente che esistono provider specializzati in questi servizi o provider generici che offrono certificati, web hosting, cloud, ecc…

La procedura di acquisto è analoga agli acquisti che abbiamo fatto prima:

accediamo al sito del nostro provider e autentichiamoci;
individuiamo la pagina per l’acquisto di un certificato;
comparirà una pagina che chiede una serie di dati o di fornire un certificato non firmato.

NB: ricordiamoci di mettere dati veritieri e corretti perché verranno, in parte, inclusi nel certificato e sarà evidente a tutti se sono fasulli o inesatti;
dopo qualche istante il provider ci offrirà una pagina con la conferma della buona riuscita dell’operazione e la possibilità di scaricare il certificato. Dovremmo ricevere anche un’email che riporta la riuscita (o meno) della creazione del certificato, alcune istruzioni e informazioni veloci e dei link per accedere a manualistica e istruzioni offerte dal provider stesso; in allegato dovremmo trovare il file del certificato che sarà da scaricare, installare nel server e conservare una copia in modo attento e sicuro.

A questo punto dobbiamo mettere il file del certificato in un punto preciso del server e apportare una configurazione al nostro web server Apache.

Passiamo a dare continuità al lavoro che abbiamo fatto all’inizio di questa guida installando e avviando il web server Apache. Quanto abbiamo creato è un server (fisico o virtuale non c’è differenza) ed il nostro provider non fornisce nel pacchetto un certificato. Possiamo scegliere Let’s Encrypt che offre certificati ad uso gratuito.

9.4. SSL: Let’s Encrypt

Let’s Encrypt è una società nata nel 2015 dall’alleanza di alcune aziende del web che hanno voluto sostenere l’adozione universale del protocollo HTTPS per garantire a tutti un servizio internet migliore, più sicuro e più riservato.

A differenza di altre società precedenti, come la StartSSL, la Let’s Encrypt ha stretto accordi con chi sviluppa software internet per inserire, all’atto della creazione dei programmi, il certificato pubblico. Pertanto chi usa i servizi offerti dalla Let’s Encrypt ha la stessa esperienza d’uso che si ha acquistando un certificato a pagamento.

Come accennato sopra i certificati della Let’s Encrypt hanno delle limitazioni che non li rendono adatti in alcuni casi d’uso, oltre ad avere una durata predeterminati di 3 mesi (NB: la breve durata è una vantaggio di sicurezza, anche se una complicazione in più per i gestori).

Accanto a questi interessanti benefici sono nati due script di pubblico dominio che rendono facile e agevole l’adozione di un certificato. Addirittura configurano automaticamente il web server Apache o Nginx.

I due script citati sono ACME ( https://github.com/acmesh-official/acme.sh ) e il più raccomandato CertBot ( https://certbot.eff.org ) .

Torniamo al nostro server che abbiamo abbandonato al capitolo 7, e procediamo aggiungendo un certificato per il nostro dominio example.com .

Prima di procedere dobbiamo avere chiare due idee:

in questo manuale usiamo dati di fantasia e un dominio universalmente bloccato. Pertanto le istruzioni seguenti riportano il processo corretto, ma con dati che non daranno mai un risultato di successo;
prima di iniziare la procedura dobbiamo aver già registrato e attivato il dominio.

Visto che nel nostro server abbiamo creato un’istallazione sfruttando la configurazione default dobbiamo creare le directory e la configurazione specifica per il dominio example.com .

9.4.1. Let’s Encrypt: configuriamo example.com

Allo scopo didattico di questa parte non procederemo a migrare PhpMyAdmin, Joomla e WordPress.

Torniamo a collegarci al nostro server remoto

ssh weadmin@www.example.com

creiamo le directory per il nostro dominio example.com

sudo mkdir -p /var/www/example.com/{html,log}

creiamolo il file index.html per avere una pagina di cortesia

sudo nano /var/www/example.com/html/index.html

e popoliamolo come segue

<!DOCTYPE html>
<html>
<body>
<h1>SITO IN COSTRUZIONE</h1>
<p>Ci scusiamo per disagio. Saremo a breve nuovamente online</p>
</body>
</html>

correggiamo i permessi

sudo chown www-data:www-data -R /var/www/example.com/

creiamo il file di configurazione example.com.conf per Apache

sudo nano /etc/apache2/sites-available/example.com.conf

e popoliamo come segue

<VirtualHost *:80>
    ServerAdmin webmaste@example.com
    ServerName www.example.com
    DocumentRoot /var/www/example.com/html

    ErrorLog /var/www/example.com/log/error.log
    CustomLog /var/www/example.com/log/access.log combined

        <Directory "/var/www/example.com/html">
                Options Indexes FollowSymLinks
                AllowOverride All
                Require all granted
        </Directory>
</VirtualHost>

attiviamo la configurazione

sudo a2ensite example.com

tutto è pronto per procedere alla creazione del certificato con certbot .

9.4.2. Let’s Encrypt: creiamo il certificato con certbot

La prima volta che si usa certbot verrà chiesto l’indirizzo email per identificare l’utente responsabile. Facciamo attenzione a fornire un identificativo reale che verrà inserito nei certificati e servirà per identificare il responsabile. Se certifichiamo più server possiamo sempre usare la stessa email se siamo i responsabili (reali) dei vari domini e server.

Ai fini didattici ipotizziamo che l’email è webmaster@example.com .

Iniziamo la creazione del certificato. Useremo CertBot che installerà automaticamente anche un demone che gestisce automaticamente il rinnovo del certificato sollevandoci anche da questa noia:

dalla nostra console accediamo al nostro web server via SSH;
installiamo lo script (è di default nei repo delle principali distribuzioni Linux)

sudo apt install certbot python3-certbot-apache

creiamo il certificato

sudo certbot --apache --agree-tos --redirect --hsts --staple-ocsp --email webmaster@example.com -d www.example.com

dopo alcuni istanti otterremo un output simile al seguente

  Saving debug log to /var/log/letsencrypt/letsencrypt.log
  Requesting a certificate for www.example.com

  Successfully received certificate.
  Certificate is saved at: /etc/letsencrypt/live/www.example.com/fullchain.pem
  Key is saved at:         /etc/letsencrypt/live/www.example.com/privkey.pem
  This certificate expires on 2024-09-29.
  These files will be updated when the certificate renews.
  Certbot has set up a scheduled task to automatically renew this certificate in the background.

  Deploying certificate
  Some rewrite rules copied from /etc/httpd/sites-enabled/example.com.080.conf were disabled in the VirtualHost for your HTTPS site located at /etc/httpd/sites-available/example.com.080-le-ssl.conf because they have the potential to create redirection loops.
  Successfully deployed certificate for www.example.com to /etc/httpd/sites-available/example.com.080-le-ssl.conf
 Congratulations! You have successfully enabled HTTPS on https://www.example.com

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    If you like Certbot, please consider supporting our work by:
     * Donating to ISRG  Let's Encrypt:   https://letsencrypt.org/donate
     * Donating to EFF:                    https://eff.org/donate-le
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

NB: se sbagliamo qualcosa, ma completiamo l’operazione, possiamo rifare la procedura per un massimo di 3 tentativi sbagliati. Dopo si verrà bloccati per 3 mesi.

A questo punto abbiamo creato il certificato. L’installazione e la creazione del certificato aggiungono un processo automatico di rinnovo. Pertanto non dobbiamo preoccuparci più di nulla. CertBot ha anche installato una regola che automaticamente redirige il traffico HTTP sul HTTPS.

A questo punto ci serve solo far ricaricare le configurazioni ad Apache

sudo systemctl reload apache

Nota finale: certbot è uno script chi viene migliorato rapidamente. È possibile che le sintassi e gli output siano diversi nel momento in cui userete il tool.