Tutorial: configurazione di SSL/TLS su Amazon Linux 2 - Amazon Elastic Compute Cloud

Tutorial: configurazione di SSL/TLS su Amazon Linux 2

Il protocollo Secure Sockets Layer/Transport Layer Security (SSL/TLS) crea un canale crittografato tra un server Web e un client Web che protegge i dati in transito da eventuali intercettazioni. In questo tutorial viene spiegato come aggiungere manualmente il supporto per SSL/TLS a un'istanza EC2 con Amazon Linux 2 e il server Web Apache. Questo tutorial presuppone che si non stia utilizzando un sistema di bilanciamento del carico (load balancer). Se si utilizza Elastic Load Balancing, è possibile scegliere di configurare l'offload SSL sul sistema di bilanciamento del carico, utilizzando invece un certificato di AWS Certificate Manager.

Per motivi storici, la crittografia Web viene spesso definita semplicemente con l'acronimo SSL. Se da un lato i browser Web continuano a supportare il protocollo SSL, dall'altro il protocollo TLS, suo successore, è meno vulnerabile agli attacchi. Amazon Linux 2 disabilita il supporto lato server su tutte le versioni di SSL per impostazione predefinita. Gli organismi che si occupano degli standard di sicurezza considerano TLS 1.0 non sicuro. TLS 1.0 e TLS 1.1 sono stati dichiarati formalmente obsoleti a marzo 2021. Le istruzioni contenute in questo tutorial si basano esclusivamente sull'abilitazione di TLS 1.2. TLS 1.3 è stato finalizzato nel 2018 ed è disponibile in Amazon Linux 2 purché la libreria TLS sottostante (OpenSSL in questo tutorial) sia supportata e abilitata. Per ulteriori informazioni sugli standard di crittografia aggiornati, consulta RFC 7568 e RFC 8446.

Questo tutorial fa riferimento alla crittografia Web moderna semplicemente come TLS.

Importante

Queste procedure sono pensate per l'utilizzo con Amazon Linux 2. Supponiamo anche che si stia operando su una nuova istanza Amazon EC2. Se si sta tentando di impostare un'istanza EC2 che esegue una distribuzione diversa o un'istanza che esegue una versione precedente di Amazon Linux 2, alcune procedure in questa esercitazione potrebbero non funzionare. Per Amazon Linux AMI, consulta Esercitazione: Configurare SSL/TLS con l'AMI Amazon Linux. Per Ubuntu, consulta la documentazione seguente della community: Open SSL on Ubuntu. Per Red Hat Enterprise Linux, consulta il seguente argomento: Configurazione del server Web HTTP Apache. Per altre distribuzioni, consulta la relativa documentazione specifica.

Nota

In alternativa, è possibile utilizzare AWS Certificate Manager (ACM) per AWS Nitro enclaves, un'applicazione enclave che permette di utilizzare certificati SSL/TLS pubblici e privati con le applicazioni Web e i server in esecuzione su istanze Amazon EC2 con AWS Nitro Enclaves. Nitro Enclaves è una funzionalità Amazon EC2 che consente la creazione di ambienti di calcolo isolati per proteggere ed elaborare in modo sicuro dati altamente sensibili, come certificati SSL/TLS e chiavi private.

ACM per Nitro Enclaves funziona con nginx in esecuzione sull'istanza Amazon EC2 Linux per creare chiavi private, distribuire certificati e chiavi private e gestire i rinnovi dei certificati.

Per utilizzare ACM per Nitro Enclaves, è necessario utilizzare un'istanza Linux abilitata all'enclave.

Per ulteriori informazioni, consulta Che cos'è AWSNitro Enclaves? e AWS Certificate Manager per Nitro Enclaves nella Guida per l'utente di AWS Nitro Enclaves.

Prerequisiti

Prima di iniziare questo tutorial, completare le procedure descritte di seguito:

  • Avviare un'istanza Amazon Linux 2 supportata da EBS. Per ulteriori informazioni, consulta Fase 1: avvio di un'istanza.

  • Configurare i gruppi di sicurezza in modo da consentire all'istanza di accettare le connessioni sulle porte TCP seguenti:

    • SSH (porta 22)

    • HTTP (porta 80)

    • HTTPS (porta 443)

    Per ulteriori informazioni, consulta Autorizzazione del traffico in entrata per le istanze Linux.

  • Installare il server Web Apache. Per istruzioni dettagliate, consulta Tutorial: Installazione di un server Web LAMP su Amazon Linux 2. Sono necessari solo il pacchetto httpd e le relative dipendenze. Puoi pertanto ignorare le istruzioni relative a PHP e MariaDB.

  • Per identificare e autenticare i siti Web, l'infrastruttura a chiave pubblica (PKI) TLS si basa su Domain Name System (DNS). Per utilizzare l'istanza EC2 per ospitare un sito Web pubblico, devi registrare un nome di dominio per il server Web o trasferire un nome di dominio esistente nell'host Amazon EC2. Per questa operazione sono disponibili numerosi servizi di registrazione di domini e hosting DNS di terze parti. In alternativa, puoi utilizzare Amazon Route 53.

Fase 1: abilitare TLS nel server

Opzione: completare questo tutorial mediante Automation

Per completare questo tutorial mediante AWS Systems Manager Automation anziché le attività seguenti, esegui il documento di automazione.

Questa procedura illustra il processo di configurazione di TLS in Amazon Linux 2 con un certificato digitale autofirmato.

Nota

Un certificato autofirmato è accettabile in ambienti di test, ma non in ambienti di produzione. Se esponi un certificato autofirmato in Internet, i visitatori del sito visualizzeranno avvisi di sicurezza.

Per abilitare TLS in un server

  1. Connettersi all'istanza e confermare che Apache è in esecuzione.

    [ec2-user ~]$ sudo systemctl is-enabled httpd

    Se il valore restituito non è "enabled" ("abilitato), avviare Apache e configurarlo in modo che venga avviato all'avvio del sistema:

    [ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd
  2. Per verificare che tutti i pacchetti software siano aggiornati, eseguire un aggiornamento rapido del software sull'istanza. Questo processo può richiedere alcuni minuti, ma è importante assicurarsi di disporre della versione più recente degli aggiornamenti della sicurezza e delle correzioni dei bug.

    Nota

    L'opzione -y installa gli aggiornamenti senza chiedere conferma. Se desideri esaminare gli aggiornamenti prima di installarli, puoi omettere questa opzione.

    [ec2-user ~]$ sudo yum update -y
  3. Dopo aver aggiornato l'istanza, aggiungere il supporto per TLS installando il modulo Apache mod_ssl.

    [ec2-user ~]$ sudo yum install -y mod_ssl

    L'istanza dispone ora dei file seguenti, che serviranno per configurare il server sicuro e creare un certificato per il test:

    • /etc/httpd/conf.d/ssl.conf

      File di configurazione per mod_ssl. Contiene le direttive che indicano ad Apache dove cercare le chiavi e i certificati di crittografia, le versioni del protocollo TLS da consentire e il tipo di crittografia da accettare.

    • /etc/pki/tls/certs/make-dummy-cert

      Script che genera un certificato X.509 autofirmato e una chiave privata per l'host del server. Questo certificato risulta utile per verificare se Apache è configurato correttamente per l'utilizzo di TLS. Non deve essere usato in ambienti di produzione poiché non garantisce l'identità. In caso contrario, attiva avvisi nei browser Web.

  4. Eseguire lo script per generare un certificato dummy autofirmato e una chiave per il test.

    [ec2-user ~]$ cd /etc/pki/tls/certs sudo ./make-dummy-cert localhost.crt

    Viene così generato il nuovo file localhost.crt nella directory /etc/pki/tls/certs/. Il nome di file specificato corrisponde al file predefinito assegnato nella direttiva SSLCertificateFile in /etc/httpd/conf.d/ssl.conf

    Il file contiene sia un certificato autofirmato che la relativa chiave privata. Apache richiede che certificato e chiave siano entrambi in formato PEM, che è composto da caratteri ASCII con codifica Base64 racchiusi tra le righe "BEGIN" ed "END", come nell'esempio abbreviato riportato di seguito.

    -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q 3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT ... 56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs 27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo 4QQvAqOa8UheYeoXLdWcHaLP -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy ... z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0 CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3 WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak 3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg== -----END CERTIFICATE-----

    I nomi e le estensioni di file rappresentano una convenzione e non hanno alcuna ripercussione sulla funzionalità. Ad esempio è possibile denominare un certificato cert.crt, cert.pem o con qualsiasi altro nome di file, a condizione che la direttiva corrispondente nel file ssl.conf utilizzi lo stesso nome.

    Nota

    Quando si sostituiscono i file TLS predefiniti con file personalizzati, assicurarsi che siano in formato PEM.

  5. Aprire il file /etc/httpd/conf.d/ssl.conf utilizzando un editor di testo (come vim o nano) e commentare la riga seguente, in quanto anche il certificato dummy autofirmato contiene la chiave. Se non si commenta questa riga prima di completare il passaggio successivo, l'avvio del servizio Apache non riesce.

    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
  6. Riavviare Apache.

    [ec2-user ~]$ sudo systemctl restart httpd
    Nota

    Assicurarsi che la porta TCP 443 sia accessibile sull'istanza EC2, come descritto in precedenza.

  7. Il server Web Apache ora dovrebbe supportare HTTPS (HTTP protetto) sulla porta 443. Per eseguire il test, digitare l'indirizzo IP o il nome di dominio completo dell'istanza EC2 nella barra degli indirizzi URL di un browser con il prefisso https://.

    Poiché ti stai connettendo a un sito con un certificato host autofirmato non attendibile, il browser potrebbe visualizzare una serie di avvisi di sicurezza. Ignorare gli avvisi e passare al sito.

    Se la pagina predefinita di test di Apache viene visualizzata, significa che TLS è stato correttamente configurato sul server. Tutti i dati in transito tra il browser e il server ora sono crittografati.

    Nota

    Per evitare che i visitatori del sito vedano schermate di avviso, è necessario ottenere un certificato attendibile che non solo esegua la crittografia, ma che fornisca anche un'autenticazione pubblica del proprietario del sito.

Fase 2: ottenere un certificato firmato dalla CA

Puoi utilizzare la seguente procedura per ottenere un certificato firmato dalla CA:

  • Generare una richiesta di firma del certificato (CSR) da una chiave privata

  • Inviare il CSR alla Certificate Authority

  • Ottenere un certificato host firmato

  • Configurare Apache per utilizzare il certificato

Dal punto di vista della crittografia un certificato host TLS X.509 autofirmato è identico a un certificato firmato da una CA. La differenza è una questione di attendibilità. Una CA si impegna infatti a fornire una convalida minima della titolarità di un dominio prima di emettere un certificato a un richiedente. Ogni browser Web contiene un elenco di CA considerate attendibili dal fornitore del browser ai fini di questa operazione. Un certificato X.509 è principalmente composto da una chiave server privata e da una firma fornita dalla CA e associata a livello di crittografia alla chiave pubblica. Quando un browser si connette a un server Web tramite HTTPS, il server presenta un certificato al browser e questi lo verifica in base al relativo elenco di CA considerati attendibili. Se il firmatario è incluso nell'elenco oppure è accessibile tramite una catena di attendibilità composta da altri firmatari fidati, il browser negozia un canale di dati a crittografia rapida con il server e carica la pagina.

I certificati in genere costano poiché il processo di convalida delle richieste prevede alcuni costi. Consigliamo pertanto di valutare le varie offerte. Alcune CA forniscono certificati di livello base a titolo gratuito. La più importante è rappresentata dal progetto Let's Encrypt, che supporta anche l'automazione del processo di creazione e rinnovo dei certificati. Per ulteriori informazioni sull'utilizzo di Let's Encrypt come CA, consulta la sezione Automazione dei certificati: Let's Encrypt con Certbot su Amazon Linux 2.

Se hai intenzione di offrire servizi di livello commerciale, AWS Certificate Manager è una buona opzione.

L'uso di un certificato host sottostante rappresenta la soluzione ideale. Dal 2019, gruppi appartenenti alla pubblica amministrazione e a settori specifici consigliano una dimensione (modulo) di chiave minima pari a 2048 bit per le chiavi RSA a protezione dei documenti fino al 2030. La lunghezza predefinita della chiave crittografica generata da OpenSSL in Amazon Linux 2 è di 2048 bit, il che è idoneo per l'uso in un certificato firmato da una CA. Nella seguente procedura viene offerto un passaggio opzionale per coloro che desiderano una chiave personalizzata, ad esempio, una chiave con un modulo più grande o che utilizza un algoritmo di crittografia diverso.

Importante

In mancanza di un dominio DNS registrato e ospitato, tali istruzioni per l'acquisizione di certificati host firmati dalla CA non funzioneranno.

Per ottenere un certificato firmato dalla CA

  1. Connettersi all'istanza e passare a /etc/pki/tls/private/. Si tratta della directory in cui viene memorizzata la chiave privata del server per TLS. Se preferisci utilizzare una chiave host esistente per generare la CSR, passa alla Fase 3.

  2. (Opzionale) Generare una nuova chiave privata. Di seguito sono riportate alcune configurazioni di chiave di esempio. Qualsiasi chiave risultante funziona con il server Web, ma il livello e il tipo di sicurezza implementati possono variare.

    • Esempio 1: creare una chiave host RSA predefinita. Il file risultante, custom.key, è una chiave privata RSA a 2048 bit.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key
    • Esempio 2: creare una chiave RSA più complessa con un modulo più grande, Il file risultante, custom.key, è una chiave privata RSA a 4096 bit.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096
    • Esempio 3: creare una chiave RSA crittografata a 4096 bit con protezione con password. Il file risultante, custom.key, è una chiave privata RSA a 4096 bit crittografata in base allo standard AES-128.

      Importante

      La crittografia di una chiave fornisce maggiore sicurezza, ma dal momento che una chiave crittografata richiede una password, i servizi che dipendono da essa non possono essere avviati automaticamente. Ogni volta che usi questa chiave, devi fornire la password ( nell'esempio precedente, "abcde12345") tramite una connessione SSH.

      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096
    • Esempio 4: creare una chiave utilizzando uno standard non RSA. La crittografia RSA può essere relativamente lenta per via della dimensione delle chiavi pubbliche, che sono basate sul prodotto di due grandi numeri primi. Tuttavia, è possibile creare chiavi per TLS che utilizzano una crittografia non RSA. Le chiavi basate su calcoli matematici di curve ellittiche sono di dimensioni inferiori e, dal punto di vista del calcolo, più rapide pur garantendo un livello equivalente di sicurezza.

      [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey

      Il risultato è una chiave privata basata su curva ellittica a 256 bit che utilizza prime256v1, una "curva denominata" supportata da OpenSSL. La complessità dal punto di vista crittografico è leggermente superiore rispetto una chiave RSA a 2048 bit, secondo i dati NIST.

      Nota

      Non tutte le CA forniscono lo stesso livello di supporto per chiavi basate su curve ellittiche come nel caso delle chiavi RSA.

    Verifica che la nuova chiave privata disponga di titolarità e autorizzazioni altamente restrittivi (owner=root, group=root, read/write solo per il proprietario). Il comando è come mostrato nell'esempio seguente.

    [ec2-user ~]$ sudo chown root:root custom.key [ec2-user ~]$ sudo chmod 600 custom.key [ec2-user ~]$ ls -al custom.key

    I comandi precedenti restituiscono il seguente risultato:

    -rw------- root root custom.key

    Dopo aver creato e configurato una chiave affidabile, puoi creare una CSR.

  3. Creare una CSR utilizzando la chiave preferita. Nell'esempio seguente viene utilizzato custom.key.

    [ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem

    OpenSSL visualizza una finestra di dialogo e richiede l'immissione delle informazioni riportate nella seguente tabella. Tutti i campi, tranne Common Name (Nome comune), sono facoltativi per un certificato host di base convalidato a livello di dominio.

    Nome Descrizione Esempio
    Nome paese L'abbreviazione ISO di due lettere per il tuo paese. US = Stati Uniti
    State or Province Name (Nome stato o provincia) Il nome dello stato o della provincia in cui si trova la tua organizzazione. Questo nome non può essere abbreviato. Washington
    Locality Name (Nome località) La località in cui si trova la tua organizzazione, ad esempio una città. Seattle
    Nome organizzazione La denominazione legale completa della tua organizzazione. Non abbreviare il nome dell'organizzazione. Example Corporation
    Organizational Unit Name (Nome unità organizzativa) Eventuali informazioni aggiuntive. Example Dept
    Common Name (Nome comune)

    Questo valore deve corrispondere esattamente all'indirizzo Web che presumibilmente gli utenti immettono in un browser. In genere, ciò significa un nome di dominio con un nome host o alias con un prefisso, nel formato www.example.com. In un ambiente di testing con un certificato autofirmato e nessuna risoluzione DNS, il nome comune può essere composto solo dal nome host. Le CA offrono inoltre certificati più costosi, in grado di accettare nomi contenenti caratteri jolly, ad esempio *.example.com.

    www.example.com
    Indirizzo e-mail L'indirizzo e-mail dell'amministratore del server. someone@example.com

    Infine, OpenSSL richiede l'immissione di una password di verifica opzionale. Questa password è valida solo per la CSR e per le transazioni tra te e la CA. Pertanto, attieniti alle raccomandazioni della CA in merito alla definizione di questo tipo di password e all'altro campo facoltativo, ovvero il nome azienda facoltativo. La password di verifica associata alla CSR non ha alcuna ripercussione sulla funzionalità del server.

    Il file csr.pem risultante contiene la chiave pubblica, la firma digitale della chiave pubblica e i metadati immessi.

  4. Inviare la CSR a una CA. In genere, questa operazione prevede l'apertura del file CSR in un editor di testo e la copia del contenuto in un modulo Web. In questa fase, ti potrebbe venire richiesto di fornire uno o più nomi alternativi di oggetto (SAN) da inserire nel certificato. Se www.example.com è il nome comune, example.com potrebbe essere un nome alternativo di oggetto (SAN) valido e viceversa. Un visitatore del sito che immettesse uno di questi due nomi avrebbe accesso a una connessione priva di errori. Se il modulo Web della CA lo consente, includi il nome comune nell'elenco di SAN. Alcuni CA lo includono automaticamente.

    Dopo l'approvazione della richiesta, riceverai un nuovo certificato host firmato dalla CA. Ti potrebbe inoltre venire richiesto di scaricare un file di certificato intermedio contenente i certificati aggiuntivi necessari per completare la catena di attendibilità della CA.

    Nota

    La CA potrebbe inviare i file in più formati, destinati a scopi specifici. Ai fini di questo tutorial, ti consigliamo di usare solo un file di certificato in formato PEM, che in genere, ma non sempre, è contrassegnato dall'estensione .pem o .crt. Se non sei sicuro di quale file usare, apri il file in un editor di testo e cerca quello contenente uno o più blocchi che iniziano con la seguente riga.

    - - - - -BEGIN CERTIFICATE - - - - -

    Il file deve inoltre terminare con la seguente riga.

    - - - -END CERTIFICATE - - - - -

    Puoi anche testare il file nella riga di comando come indicato di seguito.

    [ec2-user certs]$ openssl x509 -in certificate.crt -text

    Verifica che nel file appaiano queste righe. Non utilizzare file che terminano con .p7b, .p7c o estensioni simili.

  5. Posizionare il nuovo certificato firmato dalla CA ed eventuali certificati intermedi nella directory /etc/pki/tls/certs.

    Nota

    Esistono vari modi per caricare il nuovo certificato nell'istanza EC2, ma il più semplice e immediato prevede di aprire un editor di testo (ad esempio, vi, nano o notepad) sul computer locale e sull'istanza e quindi di copiare e incollare il contenuto del file in queste posizioni. Devi disporre delle autorizzazioni root [sudo] durante l'esecuzione di queste operazioni nell'istanza EC2. In questo modo, puoi verificare in tempo reale se si verificano problemi a livello di autorizzazioni o percorsi. Presta particolare attenzione a non aggiungere altre righe durante la copia del contenuto o a non apportare modifiche di alcun tipo.

    Dall'interno della directory /etc/pki/tls/certs, controlla che le impostazioni relative a proprietà del file, gruppo e autorizzazioni corrispondano ai valori restrittivi di default di Amazon Linux 2 (owner=root, group=root, read/write solo per il proprietario). L'esempio seguente mostra i comandi da utilizzare.

    [ec2-user certs]$ sudo chown root:root custom.crt [ec2-user certs]$ sudo chmod 600 custom.crt [ec2-user certs]$ ls -al custom.crt

    Questi comandi dovrebbero restituire il seguente risultato.

    -rw------- root root custom.crt

    Le autorizzazioni del file del certificato intermedio sono meno rigide (owner=root, group=root, il proprietario può scrivere, il gruppo può leggere, tutti gli utenti possono leggere). L'esempio seguente mostra i comandi da utilizzare.

    [ec2-user certs]$ sudo chown root:root intermediate.crt [ec2-user certs]$ sudo chmod 644 intermediate.crt [ec2-user certs]$ ls -al intermediate.crt

    Questi comandi dovrebbero restituire il seguente risultato.

    -rw-r--r-- root root intermediate.crt
  6. Posizionare la chiave privata utilizzata per creare la CRS nella directory /etc/pki/tls/private/.

    Nota

    Esistono vari modi per caricare la chiave personalizzata nell'istanza EC2, ma il più semplice e immediato prevede di aprire un editor di testo (ad esempio, vi, nano o notepad) sul computer locale e sull'istanza e quindi di copiare e incollare il contenuto del file in queste posizioni. Devi disporre delle autorizzazioni root [sudo] durante l'esecuzione di queste operazioni nell'istanza EC2. In questo modo, puoi verificare in tempo reale se si verificano problemi a livello di autorizzazioni o percorsi. Presta particolare attenzione a non aggiungere altre righe durante la copia del contenuto o a non apportare modifiche di alcun tipo.

    Dall'interno della directory /etc/pki/tls/private, utilizzare i seguenti comandi per verificare che le impostazioni relative a proprietà del file, gruppo e autorizzazioni corrispondano ai valori restrittivi predefiniti di Amazon Linux 2 (owner=root, group=root, read/write solo per il proprietario).

    [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ ls -al custom.key

    Questi comandi dovrebbero restituire il seguente risultato.

    -rw------- root root custom.key
  7. Modificare /etc/httpd/conf.d/ssl.conf per riflettere i nuovi file del certificato e della chiave.

    1. Indicare il percorso e il nome del file del certificato host firmato dalla CA nella direttiva SSLCertificateFile di Apache:

      SSLCertificateFile /etc/pki/tls/certs/custom.crt
    2. In caso di ricezione di un file del certificato intermedio (intermediate.crt in questo esempio), specificare il relativo percorso e nome di file utilizzando la direttiva SSLCACertificateFile di Apache:

      SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
      Nota

      Alcune CA combinano il certificato host e i certificati intermedi in un unico file, rendendo inutile la direttiva SSLCACertificateFile. Consultare le istruzioni fornite dalla CA.

    3. Specificare il percorso e il nome del file della chiave privata (custom.key in questo esempio) nella direttiva SSLCertificateKeyFile di Apache:

      SSLCertificateKeyFile /etc/pki/tls/private/custom.key
  8. Salvare /etc/httpd/conf.d/ssl.conf e riavviare Apache.

    [ec2-user ~]$ sudo systemctl restart httpd
  9. Testare il server digitando il nome del dominio nella barra dell'URL di un browser con il prefisso https://. Il browser deve caricare la pagina di test su HTTPS senza errori.

Fase 3: testare e proteggere la configurazione di sicurezza

Dopo aver configurato TLS e averlo esposto al pubblico, devi testarne il livello effettivo di sicurezza. Questa operazione è semplice grazie a servizi online quali Qualys SSL Labs, che eseguono un'analisi completa e gratuita della configurazione della sicurezza. In base ai risultati, puoi decidere di rafforzare la configurazione di sicurezza di default mediante il controllo dei protocolli accettati, del tipo di cifratura preferito e degli elementi da escludere. Per ulteriori informazioni, consulta la sezione relativa alla formulazione delle classificazioni di Qualys.

Importante

Il test in un ambiente reale è di cruciale importanza per la sicurezza del server. Piccoli errori di configurazione potrebbero generare gravi violazioni della sicurezza e perdita di dati. Poiché le procedure consigliate per la sicurezza sono in costante cambiamento in risposta a programmi di ricerca e minacce emergenti, verifiche periodiche della sicurezza rappresentano una pratica di amministrazione ottimale dei server.

Nel sito Qualys SSL Labs, immetti il nome di dominio completo del server nel formato www.example.com. Dopo circa due minuti riceverai una valutazione del sito (da A a F) e un'analisi dettagliata dei risultati. Nella tabella seguente è riepilogato il report relativo a un dominio dotato di impostazioni identiche alla configurazione Apache predefinita su Amazon Linux 2 e di un certificato Certbot di default:

Valutazione complessiva B
Certificato 100%
Supporto dei protocolli 95%
Scambio di chiavi 70%
Affidabilità crittografia 90%

Benché dalla panoramica emerga una certa solidità della configurazione, il rapporto dettagliato mette in luce diversi potenziali problemi, qui elencati in ordine di gravità:

L'uso della crittografia RC4 è supportato su alcuni browser meno recenti. La crittografia rappresenta il nucleo matematico di un algoritmo di codifica. RC4, un tipo di crittografia rapida utilizzato per codificare i flussi di dati TLS, è noto per essere caratterizzato da diversi punti deboli gravi. A meno di avere ottime ragioni per supportare browser legacy, è necessario disabilitare questa opzione.

Sono supportate versioni di TLS meno recenti. La configurazione supporta TLS 1.0 (già obsoleto) e TLS 1.1 (in procinto di diventare obsoleto). A partire dal 2018, è raccomandato soltanto TLS 1.2.

La proprietà Forward Secrecy non è completamente supportata. La proprietà Forward Secrecy è una caratteristica degli algoritmi che eseguono la crittografia utilizzando chiavi di sessione temporanee (effimere) derivate dalla chiave privata. Ciò in pratica significa che gli utenti malintenzionati non possono decriptare i dati HTTPS anche se sono in possesso della chiave privata a lungo termine di un server Web.

Per correggere e rendere valida anche per il futuro la configurazione TLS

  1. Aprire il file di configurazione /etc/httpd/conf.d/ssl.conf in un editor di testo e commentare la seguente riga inserendo il carattere "#" all'inizio:

    #SSLProtocol all -SSLv3
  2. Aggiungere la seguente direttiva:

    #SSLProtocol all -SSLv3 SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    Questa direttiva disabilita in modo esplicito SSL versioni 2 e 3, nonché TLS versioni 1.0 e 1.1. Il server ora non accetta più connessioni crittografate con client che utilizzano crittografie diverse da TLS 1.2. Le descrizioni dettagliate della direttiva illustrano più chiaramente al lettore la tipologia di configurazione impostata per il server.

    Nota

    La disabilitazione di TLS versioni 1.0 e 1.1 consente di bloccare l'accesso al sito da parte di una piccola percentuale di browser Web non aggiornati.

Per modificare l'elenco delle crittografie consentite

  1. Nel file di configurazione /etc/httpd/conf.d/ssl.conf, individuare la sezione con la direttiva SSLCipherSuite e commentare la riga esistente inserendo il carattere "#" all'inizio.

    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
  2. Specificare suite di crittografia esplicite e un ordine di crittografia che dia priorità alla funzione Forward Secrecy e che eviti crittografie non sicure. La direttiva SSLCipherSuite qui utilizzata si basa su un output del generatore di configurazioni SSL di Mozilla, che personalizza una configurazione TLS in funzione del software specifico in esecuzione sul server (per ulteriori informazioni, vedere l'utile risorsa sulla sicurezza/TLS lato server di Mozilla). Per prima cosa determinare le versioni di Apache e OpenSSL in base all'output dei seguenti comandi.

    [ec2-user ~]$ yum list installed | grep httpd [ec2-user ~]$ yum list installed | grep openssl

    Ad esempio, se l'informazione restituita è Apache 2.4.34 e OpenSSL 1.0.2, inserirla nel generatore. Scegliere poi il modello di compatibilità “moderna”, che crea una direttiva SSLCipherSuite e applica in modo rigido la sicurezza ma che funziona per la maggior parte dei browser. Se il software non supporta la configurazione moderna, è possibile aggiornarlo o scegliere la configurazione “intermedia”.

    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

    Le crittografie selezionate includono nel proprio nome l'acronimo ECDHE (, abbreviazione di Elliptic Curve Diffie-Hellman Ephemeral). Il termine effimero fa riferimento alla proprietà Forward Secrecy. Come effetto secondario, queste crittografie non supportano RC4.

    È consigliabile utilizzare un elenco esplicito di crittografie anziché utilizzare le impostazioni predefinite o le direttive concise il cui contenuto non è visibile.

    Copiare la direttiva generata in /etc/httpd/conf.d/ssl.conf.

    Nota

    Nonostante in questa sede siano riportate su più righe per facilitarne la leggibilità, una volta copiata su /etc/httpd/conf.d/ssl.conf la direttiva deve trovarsi su un'unica riga con solo due punti (senza spazi) tra i nomi di crittografia.

  3. Rimuovere infine i commenti mediante la rimozione del carattere "#" dall'inizio della riga:

    #SSLHonorCipherOrder on

    Questa direttiva obbliga il server a preferire crittografie con classificazione più elevata, comprese (in questo caso) quelle che supportano la proprietà Forward Secrecy. Con questa direttiva abilitata, il server cerca di stabilire una connessione stabile e affidabile prima di ripiegare sulle crittografie consentite con un livello inferiore di sicurezza.

Dopo aver completato entrambe le procedure, salvare le modifiche a /etc/httpd/conf.d/ssl.conf e riavviare Apache.

Eseguendo nuovamente il test del dominio mediante il servizio Qualys SSL Labs, non dovrebbero più essere presenti né la vulnerabilità RC4 né gli altri avvisi e il riepilogo è simile al seguente.

Valutazione complessiva A
Certificato 100%
Supporto dei protocolli 100%
Scambio di chiavi 90%
Affidabilità crittografia 90%

Ogni aggiornamento a OpenSSL introduce nuove crittografie e rimuove il supporto per quelle vecchie. È importante mantenere aggiornata l'istanza Amazon Linux 2 EC2, verificare l'emissione di annunci relativi alla sicurezza di OpenSSL e prestare attenzione alle segnalazioni di nuovi exploit relativi alla sicurezza pubblicati sulla stampa di settore.

Risoluzione dei problemi

  • Il server Web Apache non si avvia a meno che non venga fornita una password

    Si tratta del comportamento previsto se per il server hai installato una chiave privata crittografata e protetta con password.

    Puoi rimuovere i requisiti di crittografia e password dalla chiave. Supponiamo, ad esempio, di avere una chiave RSA crittografata privata denominata custom.key nella directory di default e associata alla password abcde12345. Per generare una versione non crittografata della chiave, devi eseguire i seguenti comandi nell'istanza EC2:

    [ec2-user ~]$ cd /etc/pki/tls/private/ [ec2-user private]$ sudo cp custom.key custom.key.bak [ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt [ec2-user private]$ sudo mv custom.key.nocrypt custom.key [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ sudo systemctl restart httpd

    A questo punto, Apache viene avviato senza visualizzare alcuna richiesta di password.

  • Vengono visualizzati errori quando eseguo il comando sudo yum install -y mod_ssl.

    Quando installi i pacchetti richiesti per SSL, è possibile che vengano visualizzati errori simili ai seguenti.

    Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64 Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64

    Generalmente ciò significa che l'istanza EC2 non sta eseguendo Amazon Linux 2. Questo tutorial supporta solo istanze appena create a partire da un'AMI di Amazon Linux 2 ufficiale.

Automazione dei certificati: Let's Encrypt con Certbot su Amazon Linux 2

avvertimento

Il certificato DST Root CA X3 con firma incrociata Let's Encrypt è scaduto il 30 settembre 2021. Ciò può causare il fallimento delle connessioni Let's Encrypt con OpenSSL 1.0.x su Centos/RHEL7 e Amazon Linux. Le misure correttive possono essere trovate qui, oppure puoi vedere una delle soluzioni alternative manuali presenti nella Pagina del blog OpenSSL.

Importante

In mancanza di un dominio DNS registrato e ospitato, tali istruzioni per l'acquisizione di un certificato host Let's Encrypt non funzioneranno. Queste istruzioni non funzionano con i nomi host DNS pubblici assegnati da AWS.

L'autorità di certificazione Let's Encrypt rappresenta il punto focale dell'impegno di Electronic Frontier Foundation (EFF) volto ad applicare la crittografia a tutto il sistema Internet. In linea con questo obiettivo, i certificati host di Let's Encrypt sono stati sviluppati in modo da venire creati, convalidati, installati e gestiti con intervento minimo da parte degli utenti. Gli aspetti automatizzati della gestione dei certificati vengono svolti da un agente software in esecuzione sul server Web. Dopo averlo installato e configurato, l'agente comunica in modo sicuro con Let's Encrypt ed esegue attività di amministrazione su Apache e sul sistema di gestione delle chiavi. Questo tutorial utilizza l'agente gratuito Certbot in quanto consente di fornire una chiave di crittografia personalizzata come base per i certificati, nonché consente all'agente stesso di creare una chiave in base alle relative impostazioni di default. Puoi anche configurare Certbot in modo che rinnovi i certificati a scadenza regolare senza alcun intervento dell'utente, come descritto nella sezione Per automatizzare Certbot. Per ulteriori informazioni, consulta la guida per l'utente di Certbot e la pagina principale.

Certbot non è ufficialmente supportato in Amazon Linux 2, ma è disponibile per il download e funziona correttamente una volta installato. Consigliamo di eseguire i seguenti backup per proteggere i dati ed evitare inconvenienti:

  • Prima di iniziare, eseguire uno snapshot del volume root Amazon EBS. Ciò consente di ripristinare lo stato originale dell'istanza EC2. Per informazioni sulla creazione di snapshot EBS, consulta Creazione di snapshot Amazon EBS.

  • La procedura seguente richiede la modifica del file httpd.conf, che controlla il funzionamento di Apache. Certbot apporta modifiche automatiche proprie a questo file e ad altri file di configurazione. Crea una copia di backup dell'intera directory /etc/httpd nel caso tu dovessi ripristinarla.

Preparazione dell'installazione

Completare le seguenti procedure prima di installare Certbot.

  1. Scaricare i pacchetti di archivi EPEL (Extra Packages for Enterprise Linux) 7. Questi pacchetti sono obbligatori per fornire le dipendenze necessarie per Certbot.

    1. Passare alla home directory (/home/ec2-user). Scaricare EPEL utilizzando il seguente comando.

      [ec2-user ~]$ sudo wget -r --no-parent -A 'epel-release-*.rpm' https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/
    2. Installare i pacchetti del repository come mostrato nel seguente comando.

      [ec2-user ~]$ sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-*.rpm
    3. Abilitare EPEL come mostrato nel seguente comando.

      [ec2-user ~]$ sudo yum-config-manager --enable epel*

      Puoi confermare l'abilitazione di EPEL utilizzando il seguente comando.

      [ec2-user ~]$ sudo yum repolist all

      Questa operazione dovrebbe restituire informazioni simili alle seguenti.

      [ec2-user ~]$ ... epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 enabled: 12949+175 epel-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Debug enabled: 2890 epel-source/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Source enabled: 0 epel-testing/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 enabled: 778+12 epel-testing-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug enabled: 107 epel-testing-source/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Source enabled: 0 ...
  2. Modificare il file di configurazione di Apache principale, /etc/httpd/conf/httpd.conf. Individuare la direttiva "Listen 80" e alla fine aggiungere le seguenti righe, sostituendo i nomi di dominio di esempio con il nome comune e il nome oggetto alternativo (SAN) da configurare.

    <VirtualHost *:80> DocumentRoot "/var/www/html" ServerName "example.com" ServerAlias "www.example.com" </VirtualHost>

    Salvare il file e riavviare Apache.

    [ec2-user ~]$ sudo systemctl restart httpd

Installazione ed esecuzione di Certbot

Questa procedura si basa sulla documentazione di EFF per l'installazione di Certbot su Fedora e su RHEL 7. Viene descritto l'uso di default di Certbot, con la conseguente creazione di un certificato basato su una chiave RSA a 2048 bit.

  1. Installare il repository Amazon Extras per epel.

    [ec2-user ~]$ sudo amazon-linux-extras install epel -y
  2. Installare i pacchetti e le dipendenze Certbot utilizzando il seguente comando.

    [ec2-user ~]$ sudo yum install -y certbot python2-certbot-apache
  3. Eseguire Certbot.

    [ec2-user ~]$ sudo certbot
  4. Al prompt "Enter email address (used for urgent renewal and security notices)" (Immettere l'indirizzo e-mail (per notifiche urgenti su rinnovo e sicurezza)), immettere un indirizzo di contatto e premere Invio.

  5. Accettare le condizioni di servizio di Let's Encrypt quando richiesto. Digitare "A" e premere Invio per continuare.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel: A
  6. Quando viene visualizzata la richiesta di autorizzazione per EFF per l'inserimento del tuo nominativo nella lista di distribuzione, digitare "Y" o "N" e premere Invio.

  7. Certbot visualizza il nome comune e il nome oggetto alternativo (SAN) specificati nel blocco VirtualHost.

    Which names would you like to activate HTTPS for? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: example.com 2: www.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel):

    Non immettere alcun valore e premere Invio.

  8. Certbot visualizza il seguente output durante la creazione dei certificati e la configurazione di Apache. Viene quindi richiesto di confermare il reindirizzamento delle query HTTP a HTTPS.

    Obtaining a new certificate Performing the following challenges: http-01 challenge for example.com http-01 challenge for www.example.com Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/httpd/conf/httpd-le-ssl.conf Deploying Certificate for example.com to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Enabling site /etc/httpd/conf/httpd-le-ssl.conf by adding Include to root configuration Deploying Certificate for www.example.com to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

    Per consentire ai visitatori di connettersi al server tramite HTTP non crittografato, immettere "1". Per accettare solo connessioni crittografate tramite HTTPS, digitare "2". Premere Invio per inviare la selezione.

  9. Certbot completa la configurazione di Apache e segnala il completamento dell'operazione e altre informazioni.

    Congratulations! You have successfully enabled https://example.com and https://www.example.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=example.com https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/privkey.pem Your cert will expire on 2019-08-01. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.
  10. Dopo aver completato l'installazione, eseguire il test e l'ottimizzazione della sicurezza del server come descritto nella sezione Fase 3: testare e proteggere la configurazione di sicurezza.

Configurazione del rinnovo automatico dei certificati

Certbot è stato progettato per essere un elemento invisibile e privo di errori del sistema server. Per impostazione di default, genera certificati host caratterizzati da una scadenza breve di 90 giorni. Se non hai configurato il sistema per eseguire il comando automaticamente, devi rieseguire il comando certbot manualmente prima della scadenza. Questa procedura illustra come automatizzare Certbot mediante la configurazione di un processo cron.

Per automatizzare Certbot

  1. Aprire il file /etc/crontab tramite un editor di testo, ad esempio vim o nano, utilizzando sudo. In alternativa, utilizzare sudo crontab -e.

  2. Aggiungere una riga simile alla seguente e salvare il file.

    39 1,13 * * * root certbot renew --no-self-upgrade

    Di seguito vengono descritti i singoli componenti:

    39 1,13 * * *

    Pianifica l'esecuzione di un comando alle 01:39 e 13:39 di ogni giorno. I valori selezionati sono arbitrari, ma gli sviluppatori di Certbot consigliano di eseguire il comando almeno due volte al giorno. Ciò garantisce che tutti i certificati rilevati come danneggiati vengano tempestivamente revocati e sostituiti.

    root

    Il comando viene eseguito con autorizzazioni root.

    certbot renew --no-self-upgrade

    Indica il comando da eseguire. Il sottocomando renew fa sì che Certbot controlli i certificati precedentemente ottenuti e rinnovi quelli la cui scadenza è imminente. Il flag --no-self-upgrade impedisce a Certbot di aggiornare sé stesso senza l'intervento dell'utente.

  3. Riavviare il daemon cron.

    [ec2-user ~]$ sudo systemctl restart crond