Come ottenere un certificato HTTPS (SSL/TLS) gratis: la Grande Guida a Let's Encrypt su Linux CentOS/Ubuntu (rating SSL Labs: "A+") [TurboLab.it]

In passato, i gestori di siti web dovevano metter mano al portafogli per adottare HTTPS (protocolli SSL e TLS) e proteggere tramite crittografia le informazioni scambiate fra il webserver ed il browser dei visitatori. Fatte salve rare eccezioni, il certificato digitale necessario per far apparire il "lucchetto" nella barra degli indirizzi veniva infatti rilasciato solo in seguito al pagamento di un corrispettivo e di una procedura burocratica e tecnica piuttosto noiosa. Tutto questo è cambiato grazie a Let's Encrypt, progetto realizzato da un'associazione no-profit che si pone un obbiettivo lodevole: erogare automaticamente, immediatamente e gratuitamente certificati SSL/TLS utilizzabili da chiunque per rendere sicuro lo scambio di dati sul "WWW". Qui su TurboLab.it abbiamo adottato Let's Encrypt con soddisfazione da qualche tempo: questa è la guida rapida, basata sulla nostra esperienza, per ottenere un certificato HTTPS (SSL/TLS) gratuito e configurare tutto al meglio, fino a ricevere il rating "A+" da SSL Labs

Questo articolo fa parte de "La Grande Guida ad Apache, PHP, MySQL" ed è rivolto ai gestori di siti web: l'adozione di HTTPS richiede infatti una configurazione sul server e non c'è nulla che un visitatore possa fare per "attivare" HTTPS su un sito configurato per lavorare solo sul tradizionale HTTP senza crittografia.

La corretta implementazione di HTTPS tramite Let's Encrypt consente di far scomparire la dicitura Non sicuro da Google Chrome:

» Leggi: Chrome segnala sito "Non sicuro": è davvero pericoloso (virus/malware)? Come risolvere "La connessione a questo sito non è protetta"?

Premessa

In questo articolo vedremo come attivare HTTPS (SSL/TLS) gratuitamente su un sito web già operativo e funzionante via HTTP.

Daremo per scontato che sia possibile accedere via SSH al webserver Linux, operazione generalmente concessa ai clienti di servizi VPS (virtual private server) e di server dedicati, ma preclusa ai più economici piani di semplice hosting. Di più: è necessario eseguire molti comandi come utente root: sebbene sia tecnicamente possibile sfruttare Let's Encrypt con privilegi ridotti, non affronteremo qui tale situazione.

Let's Encrypt prevede varie modalità d'uso, tra cui una completamente automatica che dovrebbe configurare automaticamente anche il webserver. Non la tratteremo: vedremo, invece, come ottenere il certificato HTTPS gratuito per poi installarlo manualmente.

La procedura è stata testata con Ubuntu Server, CentOS 6 e CentOS 7, ma dovrebbe funzionare correttamente anche con qualsiasi altra distribuzione Linux relativamente recente.

Passo 1: connessione via SSH

Come primo passo bisogna "entrare" sul server via SSH (tramite PuTTY, ad esempio)

Procederemo ora ad installare Certbot, ovvero il programmino che si interfaccia con Let's Encrypt.

Passo 2A: Installare CertBot via PPA (Ubuntu)

Se il sistema è governato da Ubuntu, possiamo installare Certbot tramite repository. Per essere sicuri di ottenere sempre la versione più recente, aggiungiamo il PPA ufficiale:

sudo add-apt-repository ppa:certbot/certbot

Procediamo quindi con l'installazione:

sudo apt-get update

sudo apt-get install --upgrade certbot -y

Infine, verifichiamo che il pacchetto sia stato installato:

certbot --version

Passo 2b: installare Certbot via EPEL (CentOS 7)

Se il server impiega CentOS 7 o un'altra derivata da Red Hat Enterprise Linux 7 possiamo prelevare Certbot da EPEL. Abilitiamo dunque il repo:

» Leggi: Guida: abilitare il repository "Extra Packages for Enterprise Linux" (EPEL) su CentOS 7

Installiamo quindi il pacchetto:

sudo yum install certbot

Infine, verifichiamo che il pacchetto sia stato installato:

certbot --version

Passo 2C: Installazione manuale

Se state utilizzando CentOS 6 oppure una distribuzione Linux per la quale Certbot non sia disponibile tramite il gestore dei pacchetti, dobbiamo ripiegare sull'installazione manuale.

Installiamo dunque le dipendenze:

per CentOS 6 ed altre derivate Red Hat: sudo yum install git python -y
per derivate Debian: sudo apt-get install git python -y

Possiamo ora usare Git per ottenere il programma. Impartire il seguente comando:

sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

Il software sarà scaricato e "installato" nella cartella /opt/letsencrypt.

Per verificare che sia funzionante, lanciamo:

/opt/letsencrypt/letsencrypt-auto --version

Possiamo dunque seguire la procedura indicata di seguito, ma ricordate di sostituire il comando completo /opt/letsencrypt/letsencrypt-auto ogni volta che leggerete certbot. Ad esempio: per generare il certificato tramite il client installato manualmente, dovremo impartire qualcosa di simile a:

sudo /opt/letsencrypt/letsencrypt-auto --email mioindirizzo@gmail.com --agree-tos certonly --webroot -w /var/www/turbolab.it -d turbolab.it -d www.turbolab.it

Vedi passi successivi per maggiori informazioni.

Passo 3: stabilire il percorso "DocumentRoot"

Per funzionare correttamente, Let's Encrypt ha bisogno di conoscere il percorso su disco nel quale si trovano le pagine del sito (generalmente chiamato DocumentRoot, come l'omonima direttiva di Apache). In condizioni standard si tratterà di una cartella sotto /var/www/, ma il percorso è personalizzabile e dipende da come è configurato il server.

Per scoprirlo dobbiamo consultare i file di configurazione del webserver che si trovano in:

per CentOS: /etc/httpd/conf/
per Ubuntu: /etc/apache2/sites-enabled/

Per aprire tali file ci sono due strade:

lavorando direttamente da console: Guida: modificare i file di configurazione di Linux Ubuntu/CentOS da terminale è facile con "nano" (alternativa a "vi")
lavorando da Windows: Alternativa a "vi": usare Windows e Notepad++ per modificare i file di configurazione di Linux CentOS/Ubuntu

Di seguito useremo a titolo di esempio il percorso di DocumentRoot /var/www/turbolab.it/.

Passo 4: ottenere il certificato HTTPS

Ora non dobbiamo fare altro se non impartire un comando simile a questo:

sudo certbot --email mioindirizzo@gmail.com --agree-tos certonly --webroot -w /var/www/turbolab.it -d turbolab.it -d www.turbolab.it

Dove:

--email mioindirizzo@gmail.com: è l'indirizzo email al quale il servizio remoto invierà varie comunicazioni di servizio, fra le quali l'importantissimo "reminder" relativo all'imminente scadenza del certificato e la conseguente necessità di rinnovarlo
--agree-tos: si accettano i termini del servizio
certonly: si desidera semplicemente creare un certificato HTTPS. L'installazione avverrà manualmente
--webroot: identifica il metodo di verifica dell'identità che prevede la creazione di una cartella chiamata .well-known all'interno del sito web e la successiva consultazione del contenuto da parte del servizio remoto
-w /var/www/turbolab.it: deve essere sostituito con il percorso DocumentRoot che abbiamo ricavato al precedente Passo 3
-d turbolab.it -d www.turbolab.it: indica i domini per i quali si sta richiedendo il certificato. È sempre una buona idea richiedere sia quello con il www iniziale, sia quello senza

Se impiegate molti sotto-domini (esempi inventati: test.turbolab.it, shop.turbolab.it, abbonamenti.turbolab.it ecc.) e volete richiedere un unico certificato valido per tutti senza esplicitarli uno per uno sulla linea di comando, fate riferimento a questo approfondimento:

» Leggi: Guida per ottenere un certificato HTTPS "wildcard" con Let's Encrypt (*.miosito.com)

Passo 5: verifica dei file

Se il comando precedente si conclude senza errori, il certificato HTTPS viene creato con successo in una sottocartella di /etc/letsencrypt/live/ che porta il nome del dominio fornito al programma da linea di comando

I file sono:

privkey.pem: costituisce la chiave privata del server
cert.pem: è il certificato vero e proprio, che sarà inviato al browser dei visitatori
chain.pem: contiene i certificati delle Certification Authority (CA) che hanno rilasciato il certificato
fullchain.pem: è la concatenzione di cert.pem + chain.pem

Trucchetto: potete ispezionare il file cert.pem in modo visivo: dopo averlo scaricato su un PC Windows (via SCP con FileZilla, ad esempio), basta cambiare l'estensione in .crt per poterlo aprire con un doppio click. In alternativa:

» Leggi: Come visualizzare il certificato digitale SSL/TLS (HTTPS) di un sito con Google Chrome nuova versione

Passo 6: Installare le dipendenze per Apache

Dobbiamo ora dotare il nostro webserver dei pacchetti necessari per gestire HTTPS. Si recuperano facilmente con:

per CentOS: sudo yum install openssl mod_ssl -y
per Ubuntu: sudo apt-get install openssl mod_ssl -y

Riavviare il servizio per rendere effettive le modifiche alla configurazione

per CentOS: sudo service httpd restart
per Ubuntu: sudo restart apache2

Passo 7: Test di HTTPS

Dovete ora scoprire l'indirizzo IP del server:

per CentOS: Come visualizzare l'indirizzo IP con Linux CentOS
per Ubuntu: Visualizzare l’indirizzo IP del computer con Ubuntu

Ad esempio, diciamo sia 95.141.35.37 (è quello del server di TurboLab.it).

Aprite quindi con il browser web l'indirizzo https://95.141.35.37 (sostituendo l'indirizzo IP del vostro server): dovrebbe comparire l'avviso che il certificato non è valido e, continuando, una pagina di cortesia

Significa che le funzionalità base sono operative.

Passo 8: Preparare il Virtual Host

Dobbiamo ora configurare un nuovo virtual host (ovvero: un nuovo sito erogato da Apache) per fare in modo che, invece della pagina di cortesia, risponda il nostro sito via HTTPS.

Apriamo di nuovo il file di configurazione usato al Passo 3 per scoprire il percorso di DocumentRoot e duplichiamo l'intero virtual host dedicato al nostro sito. In altre parole: dobbiamo copia-incollare la configurazione compresa fra i tag

<VirtualHost *:80> ... </VirtualHost>

Nella prima riga della copia, sostituiamo la porta 80 con 443. La copia deve quindi diventare

<VirtualHost *:443> ... </VirtualHost>

Alla fine, la configurazione del nostro sito sarà simile alla seguente

Ricaricare la configurazione per rendere effettive le modifiche:

per CentOS: sudo service httpd restart
per Ubuntu: sudo restart apache2

Passo 9: test del virtual host HTTPS

Dobbiamo ora verificare che il nostro sito risponda anche via HTTPS. Da browser, proviamo ad aprirlo esplicitando https:// prima del nome a dominio. Apparirà nuovamente l'avviso che il certificato non è valido ma, continuando, dovremmo poter visualizzare l'home

Passo 10: scoprire la versione di Apache installata

Per completare la configurazione è necessario scoprire quale versione di Apache sia in uso. Impartire il comando appropriato:

per CentOS: sudo httpd -v
per Ubuntu: sudo apachectl -v

Passo 11: caricare il certificato di Let's Encrypt

A questo punto, il servizio funziona correttamente... ma sta usando un certificato non riconosciuto dal browser web che, di conseguenza, genera l'avviso bloccante ed impedisce di visualizzare immediatamente il sito. Per rimuovere l'ostacolo dobbiamo configurare il sistema per usare i file generati da Let's Encrypt al Punto 4 e verificati al Punto 5.

Le direttive da impiegare variano a seconda della versione di Apache in uso e sono riportate di seguito. Naturalmente, bisogna avere l'accortezza di sostituire a turbolab.it il nome a dominio per il quale si è generato il certificato al Punto 4..

Per Apache versioni 2.4.8 e successive:

SSLEngine on

SSLProtocol All -SSLv2 -SSLv3

SSLHonorCipherOrder On

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-CAMELLIA128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA256-SHA384:ECDHE-ECDSA-CAMELLIA256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:DHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA

SSLCertificateKeyFile /etc/letsencrypt/live/turbolab.it/privkey.pem

SSLCertificateFile /etc/letsencrypt/live/turbolab.it/fullchain.pem

Per Apache versioni 2.4.7 e precedenti (comprese quelle del vecchio ramo 2.2):

SSLEngine on

SSLProtocol All -SSLv2 -SSLv3

SSLHonorCipherOrder On

SSLCertificateKeyFile /etc/letsencrypt/live/turbolab.it/privkey.pem

SSLCertificateFile /etc/letsencrypt/live/turbolab.it/cert.pem

SSLCertificateChainFile /etc/letsencrypt/live/turbolab.it/chain.pem

Queste direttive devono essere inserite all'interno del virtual host relativo alla "versione" HTTPS del nostro sito (ovvero: quello creato tramite copia-incolla al Passo 9) come mostrato nell'immagine seguente (l'ordine non è importante: basta che siano all'interno del blocco <VirtualHost *:443>...</VirtualHost> ma fuori da ogni blocco come <Directory>...</Directory> o simili)

Rendere effettive le modifiche ricaricando la configurazione:

per CentOS: sudo service httpd reload
per Ubuntu: sudo reload apache2

Passo 12: test finale di HTTPS

Arrivati a questo punto dovrebbe essere davvero tutto pronto. Via browser, apriamo di nuovo il nostro sito esplicitando https:// prima del dominio. Dovrebbe rispondere immediatamente la pagina iniziale, senza errori di sicurezza e con il tanto agognato "lucchetto verde"

Passo 13: rinnovare il certificato HTTPS di Let's Encrypt

I certificati HTTPS di Let's Encrypt hanno una durata relativamente breve: 90 giorni. Questo significa che, entro 3 mesi al più dalla data di generazione, sarà imperativo procedere con il rinnovo (vedremo al passo successivo come automatizzare).

Il client prevede un apposito parametro che si occupa di controllare tutti i certificati installati sul server e rinnovare automaticamente quelli in scadenza nei 30 giorni (o meno) successivi:

per CentOS: sudo certbot renew && sudo service httpd reload
per Ubuntu: sudo certbot renew && sudo reload apache2

In linea di massima non dovrebbe servire altro, ma assicurarsi ora che non ci saranno problemi al momento opportuno non è semplice, proprio perché, come chiarito poco fa, il rinnovo vero e proprio avviene solo in prossimità della scadenza del certificato corrente.

Per gestire questa problematica ci sono varie soluzioni. La pagina di presentazione del progetto parla dell'opzione --dry-run per eseguire un test, ma la mia prova non ha portato all'esito sperato. Un'alternativa -forse un po' casereccia ma che funziona molto bene- è di attendere almeno 48 ore dalla generazione del certificato originale, quindi forzare un rinnovo aggiungendo il parametro --force-renew. Il comando completo è quindi:

per CentOS: sudo certbot renew --force-renew && sudo service httpd reload
per Ubuntu: sudo certbot renew --force-renew && sudo reload apache2

Se alla fine dell'esecuzione si legge Congratulations, all renewals succeeded., l'operazione è andata a buon fine. Per averne la certezza basta aprire il proprio sito ed ispezionare il certificato in uso: se riporta la data odierna (oppure quella di ieri, a causa del fuso orario, ma comunque successiva a quella della primissima installazione) stiamo effettivamente usando un certificato rinnovato

Se la verifica ha esito positivo, possiamo stare tranquilli: lanciando il comando senza --force-renew al momento appropriato non ci saranno problemi.

Passo 14: rinnovo automatico

È possibile sgravarsi totalmente dall'impegno di rinnovare il certificato pianificando l'esecuzione automatica del comando. Per prima cosa, impartire quanto segue per scrivere il file di configurazione del pianificatore crontab su disco:

sudo crontab -l > /tmp/mio_crontab.txt

Potreste ricevere l'avviso no crontab for root, ma non è un problema.

Ora, apriamo il file /tmp/mio_crontab.txt con l'editor preferito:

lavorando direttamente da console: Guida: modificare i file di configurazione di Linux Ubuntu/CentOS da terminale è facile con "nano" (alternativa a "vi")
lavorando da Windows: Alternativa a "vi": usare Windows e Notepad++ per modificare i file di configurazione di Linux CentOS/Ubuntu

Per fare in modo che la procedura di (eventuale) rinnovo venga eseguita ogni sabato mattina alle ore 08:00, immettere il comando appropriato:

per CentOS: 0 8 * * sat certbot renew && service httpd reload » /var/log/letsencrypt/log_rinnovo_automatico.txt 2>&1
per Ubuntu: 0 8 * * sat certbot renew && reload http2 » /var/log/letsencrypt/log_rinnovo_automatico.txt 2>&1

Ricordiamo brevemente il significato delle varie istruzioni:

0: minuto al quale eseguire il comando, come in 08:00 minuti
8: ora alla quale eseguire il comando, come in ore 8 di mattina
* *: significa "tutti i giorni di tutti i mesi"
sat: ogni sabato - in alternativa possiamo usare mon per lunedì e da lì tue, wed, thu, fri, sat oppure sun per "domenica"

Una volta salvato il file non ci resta che "caricarlo" per attivare concretamente la pianificazione:

sudo crontab /tmp/mio_crontab.txt

Passo 13: Redirect automatico HTTP -> HTTPS

Nella situazione attuale, il nostro sito usa HTTPS solamente quando il visitatore lo richiede espressamente digitando https:// nella barra degli indirizzi. In tutti gli altri casi, viene utilizzata la "vecchia versione" HTTP non-sicuro. È importante "disabilitare" HTTP e fare in modo che qualsiasi richiesta passi per HTTPS.

Per raggiungere l'obbiettivo, fare riferimento a questa guida:

» Leggi: Redirect da HTTP a HTTPS con Apache o Nginx su Ubuntu Server, CentOS o Windows - guida e migliore configurazione webserver pronta all'uso

Una volta terminata la procedura esposta nell'articolo indicato, il redirect HTTP->HTTPS è fatto: provando ad aprire una qualsiasi pagina via HTTP avverrà una redirezione automatica e del tutto invisibile all'utente verso la "versione" HTTPS. Usando gli strumenti di sviluppo del browser web è possibile verificare la presenza del codice 301 che effettua il redirect appena configurato

Passo 14: attivare HSTS

HTTP Strict Transport Security (HSTS) è un'intestazione inviata dal server al browser del visitatore. Se presente, HSTS suggerisce al navigatore web che, da lì in poi, il sito debba essere richiesto e visualizzato sempre e solo via HTTPS ed ogni tentativo di raggiungere la risorsa via HTTP deve essere automaticamente svolta via HTTPS, anche se non richiesto esplicitamente.

È una funzione facile da attivare che aumenta sensibilmente il livello di sicurezza, oltre a far sì che sia il browser stesso ad aprire ogni pagina via HTTPS, senza bisogno di dover attendere il redirect impostato al Passo 13. (che deve comunque essere mantenuto per gestire il primissimo accesso di ogni visitatore).

Per attivare HSTS basta aggiungere quanto segue al nostro virtual host HTTPS (la posizione non è importante: basta che sia all'interno del blocco <VirtualHost *:443>...</VirtualHost> ma fuori da ogni blocco come <Directory>...</Directory> o simili)

<IfModule !headers_module>

LoadModule headers_module modules/mod_headers.so

</IfModule>

Header always set Strict-Transport-Security "max-age=15768000;"

Ricaricare ora la configurazione:

per CentOS: sudo service httpd reload
per Ubuntu: sudo reload apache2

D'ora in poi, dalla seconda volta che un visitatore proverà ad aprire una nostra pagina via HTTP, sarà automaticamente rimandato alla versione HTTPS dal proprio browser, senza bisogno di attendere il redirect implementato al Passo 13. Usando gli strumenti di sviluppo durante l'apertura di una pagina del sito via HTTP si nota la presenza di una "risposta interna" con il codice 307 che rimanda ad HTTPS ed un'ulteriore intestazione Non-Authoritative-Reason: HSTS che conferma la correttezza della configurazione

È bene però ricordare che attivare HSTS ha delle implicazioni molto forti. In caso non fosse possibile stabilire la connessione via HTTPS (per via di un certificato scaduto e non rinnovato in tempo, ad esempio) ogni tentativo di accedere al servizio sarà precluso completamente.

Passo 15: disattivare il virtual host di default

Se provate di nuovo ad aprire l'indirizzo IP del server via browser web (come abbiamo fatto al precedente Passo 7) noterete che la pagina di cortesia risponde esattamente come prima. Questo comportamento causa confusione e preclude il raggiungimento del punteggio massimo con il test di SSL Labs.

È quindi consigliabile disabilitare il virtual host di default. Il file che lo contiene è:

per CentOS: /etc/httpd/ssl.conf
per Ubuntu: /etc/apache2/sites-available/default-ssl

Aprite quindi questo file con il vostro metodo preferito:

lavorando direttamente da console: Guida: modificare i file di configurazione di Linux Ubuntu/CentOS da terminale è facile con "nano" (alternativa a "vi")
lavorando da Windows: Alternativa a "vi": usare Windows e Notepad++ per modificare i file di configurazione di Linux CentOS/Ubuntu

Dobbiamo apportare due modifiche.

Innanzitutto, facciamo in modo che qualsiasi tentativo di aprire un sito non esplicitamente configurato ritorni un messaggio di errore, e non la pagina di cortesia, aggiungendo queste due direttive subito sotto la riga <VirtualHost _default_:443>:

ErrorDocument 404 "Sito non trovato"

Redirect 404 /

A modifica apportata, dovremmo avere qualcosa di simile a questo:

<VirtualHost _default_:443>:

ErrorDocument 404 "Sito non trovato"

Redirect 404 /

....

</VirtualHost>

Localizziamo ora questa direttiva:

SSLProtocol all -SSLv2

Accodiamo in fondo anche -SSLv3, ottenendo quindi:

SSLProtocol all -SSLv2 -SSLv3

Salvare il file e ricaricare la configurazione:

per CentOS: sudo service httpd reload
per Ubuntu: sudo reload apache2

Ora, provando ad aprire l'indirizzo IP del server via browser web (come abbiamo fatto al precedente Passo 7), si riceverà solo un errore 404

Passo 16: verifica con SSL Labs

Ora la nostra configurazione è quasi completa. Possiamo verificarlo tramite il servizio gratuito SSL Server Test di Qualys SSL Labs. Si tratta di una webapp che controlla da remoto la correttezza delle impostazioni HTTPS (SSL/TLS) di un sito Internet, ne evidenzia la compatibilità, eventuali problemi di sicurezza ed, infine, restituisce una valutazione complessiva espressa sottoforma di lettera dell'alfabeto.

Per eseguire il test basta immettere l'indirizzo del proprio sito nel campo di ricerca e premere Submit. Se avete seguito correttamente tutti i suggerimenti proposti ai passi precedenti dovreste ottenere il grado massimo: A+

In caso di problemi

In caso di problemi, la prima cosa da fare è aprire una nuova istanza di PuTTY, connettersi al server ed impartire:

per CentOS: sudo tail -f /var/log/messages /var/log/httpd/error_log
per Ubuntu: sudo tail -f /var/log/syslog /var/log/apache2/error.log

Il comando manterrà aperti i log principali del sistema, auto-aggiornando in tempo reale la visualizzazione mano a mano che appariranno nuovi messaggi (per uscire: Ctrl+C).

Senza chiudere la finestra, aprire il proprio sito via browser web: eventuali problemi di configurazione saranno mostrati nel terminale.

Se tutto sembra essere configurato come da manuale ma il servizio continua a non rispondere, c'è solo una cosa da fare: armarsi di questa "checklist" e... trovare l'inghippo.

» Leggi: "Impossibile connettersi al computer remoto": cosa fare quando i nostri servizi non rispondono ai client

Fonti

Il mondo della crittografia applicata al web è davvero smisurato. Se avete seguito questa guida fino a qui, probabilmente sarete riusciti a configurare Apache per erogare un sito tramite HTTPS utilizzando un certificato SSL/TLS gratuito. Per approfondire l'argomento, segnalo le fonti principali alle quali mi sono appoggiato:

OpenSSL Cookbook: un mini-eBook gratuito dedicato all'argomento a cura di Ivan Ristić di Qualys SSL Labs
Il blog di Qualys SSL Labs: aggiornato periodicamente con approfondimenti tecnici sulle nuove vulnerabilità scoperte nelle tecnologie che abilitano HTTPS
letsencrypt.readthedocs.org: la documentazione ufficiale di Let's Encrypt presenta ogni singolo parametro ed opzione per interagire con il servizio
Apache SSL/TLS Encryption: la documentazione ufficiale di Apache riguardo l'uso di connessioni HTTP crittografate

Un ringraziamento particolare va ai colleghi hashcat per il costante lavoro di affinamento ed analisi della configurazione HTTPS di TurboLab.it ed a developerwinme per aver segnalato Let's Encrypt sul forum.

Segnalazioni, precisazioni suggerimenti

Se hai trovato un errore o credi sia possibile migliorare la guida in qualsiasi altro modo, lascia un commento di seguito: tornerà sicuramente utile a qualcuno! grazie per la partecipazione!