• Articles
• admin

Introduzione

TLS, o transport layer security, e il suo predecessore SSL, che è l’acronimo di secure sockets layer, sono i protocolli web utilizzato per avvolgere il traffico normale in una protetta e cifrata wrapper.

Utilizzando questa tecnologia, i server possono inviare traffico in modo sicuro tra il server e i client senza la possibilità che i messaggi vengano intercettati da parti esterne. Il sistema di certificati aiuta anche gli utenti a verificare l’identità dei siti con cui si connettono.

In questa guida, vi mostreremo come impostare un certificato SSL autofirmato per l’utilizzo con un server web Apache su un server Ubuntu 16.04.

Nota: un certificato autofirmato crittograferà la comunicazione tra il server e qualsiasi client. Tuttavia, poiché non è firmato da nessuna delle autorità di certificazione attendibili incluse nei browser Web, gli utenti non possono utilizzare il certificato per convalidare automaticamente l’identità del server.

Un certificato autofirmato può essere appropriato se non si dispone di un nome di dominio associato al server e per i casi in cui l’interfaccia Web crittografata non è rivolta all’utente. Se si dispone di un nome di dominio, in molti casi è meglio utilizzare un certificato firmato da CA. Puoi scoprire come impostare un certificato di fiducia gratuito con il progetto Let’s Encrypt qui.

Prerequisiti

Prima di iniziare, è necessario che un utente non root sia configurato con privilegi sudo. Puoi imparare come impostare un account utente seguendo la nostra configurazione iniziale del server per Ubuntu 16.04.

Sarà inoltre necessario avere installato il server web Apache. Se desideri installare un intero stack LAMP (Linux, Apache, MySQL, PHP) sul tuo server, puoi seguire la nostra guida sull’impostazione di LAMP su Ubuntu 16.04. Se si desidera solo il server web Apache, saltare i passaggi relativi a PHP e MySQL nella guida.

Dopo aver completato i prerequisiti, continuare di seguito.

Fase 1: Creare il certificato SSL

TLS / SSL funziona utilizzando una combinazione di un certificato pubblico e una chiave privata. La chiave SSL è tenuta segreta sul server. Viene utilizzato per crittografare i contenuti inviati ai client. Il certificato SSL viene condiviso pubblicamente con chiunque richieda il contenuto. Può essere utilizzato per decifrare il contenuto firmato dalla chiave SSL associata.

Possiamo creare una coppia di chiavi e certificati autofirmati con OpenSSL in un singolo comando:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

Ti verrà posta una serie di domande. Prima di andare oltre, diamo un’occhiata a ciò che sta accadendo nel comando che stiamo emettendo:

• openssl: Questo è lo strumento da riga di comando di base per la creazione e la gestione di certificati OpenSSL, chiavi e altri file.
• req: Questo sottocomando specifica che si desidera utilizzare la gestione X. 509 Certificate Signing Request (CSR). “X. 509” è uno standard di infrastruttura a chiave pubblica a cui SSL e TLS aderiscono per la gestione delle chiavi e dei certificati. Vogliamo creare un nuovo cert X. 509, quindi stiamo usando questo sottocomando.
• – x509: Questo modifica ulteriormente il sottocomando precedente dicendo all’utilità che vogliamo creare un certificato autofirmato invece di generare una richiesta di firma del certificato, come normalmente accadrebbe.
• – nodi: questo dice a OpenSSL di saltare l’opzione per proteggere il nostro certificato con una passphrase. Abbiamo bisogno di Apache per essere in grado di leggere il file, senza l’intervento dell’utente, quando il server si avvia. Una passphrase impedirebbe che ciò accada perché dovremmo inserirla dopo ogni riavvio.
• -giorni 365: Questa opzione imposta il periodo di tempo in cui il certificato sarà considerato valido. Abbiamo fissato per un anno qui.
• – newkey rsa: 2048: Specifica che vogliamo generare un nuovo certificato e una nuova chiave allo stesso tempo. Non abbiamo creato la chiave necessaria per firmare il certificato in un passaggio precedente, quindi dobbiamo crearla insieme al certificato. La porzione rsa:2048 indica di creare una chiave RSA lunga 2048 bit.
• -keyout: questa riga indica a OpenSSL dove posizionare il file di chiave privata generato che stiamo creando.
• – fuori: Questo indica a OpenSSL dove posizionare il certificato che stiamo creando.

Come abbiamo detto sopra, queste opzioni creeranno sia un file chiave che un certificato. Ci verranno poste alcune domande sul nostro server per incorporare correttamente le informazioni nel certificato.

Compila le istruzioni in modo appropriato. La linea più importante è quella che richiede Common Name (e.g. server FQDN or YOUR name). È necessario inserire il nome di dominio associato al server o, più probabilmente, l’indirizzo IP pubblico del server.

La totalità dei prompt sarà simile a questa:

Output
Country Name (2 letter code) :USState or Province Name (full name) :New YorkLocality Name (eg, city) :New York CityOrganization Name (eg, company) :Bouncy Castles, Inc.Organizational Unit Name (eg, section) :Ministry of Water SlidesCommon Name (e.g. server FQDN or YOUR name) :server_IP_addressEmail Address :admin@your_domain.com

Entrambi i file creati verranno inseriti nelle sottodirectory appropriate della directory /etc/ssl.

Mentre stiamo usando OpenSSL, dovremmo anche creare un forte gruppo Diffie-Hellman, che viene utilizzato per negoziare la perfetta segretezza in avanti con i clienti.

Possiamo farlo digitando:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Questo può richiedere alcuni minuti, ma quando è fatto si avrà un forte gruppo DH a /etc/ssl/certs/dhparam.pem che possiamo usare nella nostra configurazione.

Passo 2: Configura Apache per usare SSL

Abbiamo creato i nostri file di chiavi e certificati nella directory /etc/ssl. Ora abbiamo solo bisogno di modificare la nostra configurazione di Apache per approfittare di questi.

Faremo alcune modifiche alla nostra configurazione:

1. Creeremo un frammento di configurazione per specificare forti impostazioni SSL predefinite.
2. Modificheremo il file SSL Apache Virtual Host incluso per puntare ai nostri certificati SSL generati.
3. (Consigliato) Modificheremo il file dell’host virtuale non crittografato per reindirizzare automaticamente le richieste all’host virtuale crittografato.

Quando abbiamo finito, dovremmo avere una configurazione SSL sicura.

Creare uno snippet di configurazione Apache con impostazioni di crittografia avanzate

In primo luogo, creeremo uno snippet di configurazione Apache per definire alcune impostazioni SSL. Questo imposterà Apache con una forte suite di crittografia SSL e abiliterà alcune funzionalità avanzate che aiuteranno a mantenere il nostro server sicuro. I parametri che imposteremo possono essere utilizzati da qualsiasi host virtuale che abiliti SSL.

Crea un nuovo frammento nella directory /etc/apache2/conf-available. Nomineremo il file ssl-params.conf per chiarire il suo scopo:

sudo nano /etc/apache2/conf-available/ssl-params.conf

Per configurare Apache SSL in modo sicuro, utilizzeremo le raccomandazioni di Remy van Elst sul Cipherli.st sito. Questo sito è progettato per fornire impostazioni di crittografia facili da utilizzare per i software più diffusi. Puoi leggere di più sulle sue decisioni riguardanti le scelte di Apache qui.

Le impostazioni suggerite sul sito collegate a sopra offrono una forte sicurezza. A volte, questo viene a costo di una maggiore compatibilità client. Se hai bisogno di supportare i clienti più anziani, c’è un elenco alternativo a cui puoi accedere facendo clic sul link nella pagina etichettato “Sì, dammi una ciphersuite che funziona con software legacy / vecchio.”Tale elenco può essere sostituito per gli elementi copiati di seguito.

La scelta di quale configurazione si utilizza dipenderà in gran parte da ciò che è necessario supportare. Entrambi forniranno grande sicurezza.

Per i nostri scopi, possiamo copiare le impostazioni fornite nella loro interezza. Faremo solo due piccole modifiche.

Imposta la direttiva SSLOpenSSLConfCmd DHParameters per puntare al file Diffie-Hellman che abbiamo generato in precedenza. Inoltre, prenditi un momento per leggere su HTTP Strict Transport Security, o HSTS, e in particolare sulla funzionalità “precarico”. Il precaricamento di HSTS fornisce una maggiore sicurezza, ma può avere conseguenze di vasta portata se attivato accidentalmente o abilitato in modo errato. In questa guida, non precaricheremo le impostazioni, ma puoi modificarle se sei sicuro di aver compreso le implicazioni:

# from https://cipherli.st/# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.htmlSSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDHSSLProtocol All -SSLv2 -SSLv3SSLHonorCipherOrder On# Disable preloading HSTS for now. You can use the commented out header line that includes# the "preload" directive if you understand the implications.#Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"Header always set X-Frame-Options DENYHeader always set X-Content-Type-Options nosniff# Requires Apache >= 2.4SSLCompression off SSLSessionTickets OffSSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)"SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

Salva e chiudi il file quando hai finito.

Modifica il file host virtuale Apache SSL predefinito

Quindi, modifichiamo /etc/apache2/sites-available/default-ssl.conf, il file host virtuale Apache SSL predefinito. Se si utilizza un file di blocco server diverso, sostituire il suo nome nei comandi seguenti.

Prima di andare avanti, torniamo indietro l’originale Virtuale SSL file Host:

sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

Ora, aprire il SSL Virtual Host file per effettuare le regolazioni:

sudo nano /etc/apache2/sites-available/default-ssl.conf

all’Interno, con la maggior parte dei commenti rimossi, il Virtual Host file dovrebbe essere qualcosa di simile a questo di default:

<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # BrowserMatch "MSIE " \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 </VirtualHost></IfModule>

Faremo alcune piccole modifiche al file. Imposteremo le cose normali che vorremmo regolare in un file host virtuale (indirizzo e-mail ServerAdmin, NomeseRver, ecc.), regolare le direttive SSL per puntare al nostro certificato e ai file chiave e rimuovere il commento di una sezione che fornisce compatibilità per i browser meno recenti.

Dopo aver apportato queste modifiche, il blocco server dovrebbe essere simile a questo:

<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin [email protected] ServerName server_domain_or_IP DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE " \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost></IfModule>

Salva e chiudi il file quando hai finito.

(Consigliato) Modificare il file host virtuale non crittografato per reindirizzare a HTTPS

Allo stato attuale, il server fornirà sia il traffico HTTP non crittografato che il traffico HTTPS crittografato. Per una maggiore sicurezza, nella maggior parte dei casi si consiglia di reindirizzare automaticamente HTTP a HTTPS. Se non vuoi o hai bisogno di questa funzionalità, puoi tranquillamente saltare questa sezione.

Per regolare il file Host virtuale non crittografato per reindirizzare tutto il traffico per essere crittografato SSL, possiamo aprire il file /etc/apache2/sites-available/000-default.conf :

sudo nano /etc/apache2/sites-available/000-default.conf

All’interno, all’interno dei blocchi di configurazione VirtualHost, abbiamo solo bisogno di aggiungere una direttiva Redirect, che punta tutto il traffico alla versione SSL del sito:

<VirtualHost *:80> . . . Redirect "/" "https://your_domain_or_IP/" . . .</VirtualHost>

Salva e chiudi il file quando hai finito.

Passaggio 3: Regolare il firewall

Se il firewall ufw è abilitato, come raccomandato dalle guide ai prerequisiti, potrebbe essere necessario regolare le impostazioni per consentire il traffico SSL. Fortunatamente, Apache registra alcuni profili con ufw al momento dell’installazione.

Siamo in grado di vedere i profili disponibili digitando:

sudo ufw app list

Si dovrebbe vedere un elenco come questo:

Output
Available applications: Apache Apache Full Apache Secure OpenSSH

È possibile visualizzare l’impostazione corrente digitando:

sudo ufw status

Se è consentito solo regolare il traffico HTTP in precedenza, il risultato potrebbe essere simile a questo:

Output
Status: activeTo Action From-- ------ ----OpenSSH ALLOW AnywhereApache ALLOW AnywhereOpenSSH (v6) ALLOW Anywhere (v6)Apache (v6) ALLOW Anywhere (v6)

inoltre lasciare il traffico HTTPS, siamo in grado di permettere l’Apache “Pieno” di profilo e quindi eliminare la ridondanza di “Apache” profilo di indennità di:

 
sudo ufw allow 'Apache Full'
 
sudo ufw delete allow 'Apache'
 

lo stato dovrebbe assomigliare a questa ora:

sudo ufw status

Output
Status: activeTo Action From-- ------ ----OpenSSH ALLOW AnywhereApache Full ALLOW AnywhereOpenSSH (v6) ALLOW Anywhere (v6)Apache Full (v6) ALLOW Anywhere (v6)

Passo 4: Abilitare le modifiche in Apache

Ora che abbiamo apportato le nostre modifiche e regolato il nostro firewall, possiamo abilitare i moduli SSL e header in Apache, abilitare il nostro host virtuale SSL-ready e riavviare Apache.

Possiamo abilitare mod_ssl, il modulo SSL Apache e mod_headers, necessari per alcune delle impostazioni nel nostro snippet SSL, con il comando a2enmod :

 
sudo a2enmod ssl
 
sudo a2enmod headers
 

Successivamente, possiamo abilitare il nostro host virtuale SSL con il comando a2ensite :

sudo a2ensite default-ssl

Avremo anche bisogno di abilitare il nostro file ssl-params.conf, per leggere i valori che abbiamo impostato:

sudo a2enconf ssl-params

A questo punto, il nostro sito e i moduli necessari sono abilitati. Dovremmo verificare che non ci siano errori di sintassi nei nostri file. Possiamo farlo digitando:

sudo apache2ctl configtest

Se tutto ha successo, otterrai un risultato simile a questo:

Output
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this messageSyntax OK

La prima riga è solo un messaggio che ti dice che la direttiva ServerName non è impostata globalmente. Se si desidera eliminare tale messaggio, è possibile impostare ServerNamesul nome di dominio o sull’indirizzo IP del server in /etc/apache2/apache2.conf. Questo è facoltativo in quanto il messaggio non danneggerà.

Se l’output contiene Syntax OK, il file di configurazione non presenta errori di sintassi. Possiamo tranquillamente riavviare Apache per implementare le nostre modifiche:

sudo systemctl restart apache2

Passo 5: Test di crittografia

Ora, siamo pronti a testare il nostro server SSL.

Aprire il browser Web e digitare https:// seguito dal nome di dominio o dall’IP del server nella barra degli indirizzi:

https://server_domain_or_IP

Poiché il certificato che abbiamo creato non è firmato da una delle autorità di certificazione attendibili del tuo browser, probabilmente vedrai un avviso spaventoso come quello qui sotto:

Questo è previsto e normale. Siamo interessati solo all’aspetto della crittografia del nostro certificato, non alla convalida da parte di terzi dell’autenticità del nostro host. Fai clic su” AVANZATE ” e quindi sul link fornito per procedere comunque al tuo host:

Dovresti essere portato al tuo sito. Se guardi nella barra degli indirizzi del browser, vedrai un lucchetto con una “x” sopra di esso. In questo caso, ciò significa solo che il certificato non può essere convalidato. Sta ancora crittografando la tua connessione.

Se hai configurato Apache per reindirizzare HTTP a HTTPS, puoi anche verificare se il reindirizzamento funziona correttamente:

http://server_domain_or_IP

Se ciò si traduce nella stessa icona, ciò significa che il reindirizzamento ha funzionato correttamente.

Passo 6: Passare a un reindirizzamento permanente

Se il reindirizzamento ha funzionato correttamente e si è sicuri di voler consentire solo il traffico crittografato, è necessario modificare nuovamente l’host virtuale Apache non crittografato per rendere il reindirizzamento permanente.

Aprire nuovamente il file di configurazione del blocco server:

sudo nano /etc/apache2/sites-available/000-default.conf

Trova la riga Redirect che abbiamo aggiunto in precedenza. Aggiungi permanent a quella riga, che cambia il reindirizzamento da un reindirizzamento temporaneo 302 a un reindirizzamento permanente 301:

<VirtualHost *:80> . . . Redirect permanent "/" "https://your_domain_or_IP/" . . .</VirtualHost>

Salva e chiudi il file.

Verificare la presenza di errori di sintassi nella configurazione:

sudo apache2ctl configtest

Quando sei pronto, riavvia Apache per rendere permanente il reindirizzamento:

sudo systemctl restart apache2

Conclusione

È stato configurato il server Apache per utilizzare una crittografia avanzata per le connessioni client. Ciò ti consentirà di servire le richieste in modo sicuro e impedirà a parti esterne di leggere il tuo traffico.