Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Apache e SSL: creazione di certificati per connessioni cifrate

Creare connessioni cifrate sul nostro Web server consente di rendere sicure le connessioni con i nostri utenti. Vediamo come creare in proprio un certificato da utilizzare per la crittografia delle comunicazioni
Creare connessioni cifrate sul nostro Web server consente di rendere sicure le connessioni con i nostri utenti. Vediamo come creare in proprio un certificato da utilizzare per la crittografia delle comunicazioni
Link copiato negli appunti

Quando utilizziamo il protocollo HTTP il traffico viaggia, come si suol dire, "in chiaro": vi è assoluta mancanza di confidenzialità sui dati che transitano tra web server e client. Su una rete pubblica, come Internet, le informazioni risultano potenzialmente a disposizione di qualche malintenzionato. Inoltre chi ci garantisce l'identità del web server a cui ci stiamo collegando? Possiamo escludere che qualcuno non stia "impersonando" il sito su cui stiamo navigando?

L'adozione del protocollo SSL/TLS fornisce una possibile compensazione a tutte queste lacune. SSL sta per Secure Socket Level Protocol, originariamente sviluppato da Netscape Comunication Corporation, è tuttavia un protocollo aperto e non proprietario. Mentre TLS, Transport Layer Security, ne rappresenta la versione standardizzata realizzata dall'IEFT (Internet Engineering Task Force) e basata su SSL versione 3.

Come è noto il protocollo TCP/IP si occupa dell'indirizzamento e trasporto dei dati, altri protocolli si appoggiano ad esso per svolgere le proprie funzioni applicative, nel caso di HTTP mostrare pagine web. SSL si inserisce tra TCP/IP e protocolli di livello superiore (il cosiddetto application layer) per autenticare e cifrare la comunicazione tra client e server.

Gli elementi fondamentali della connessione sono tre:

  • Autenticazione del server: un software client SSL-compatibile (nella categoria rientrano tutti i browser più recenti) attraverso tecniche crittografiche a chiave pubblica può verificare l'autenticità del server
  • Autenticazione del client: utilizzando le medesime tecniche un software server SSL-compatibile può verificare l'autenticità di un client
  • Connessione cifrata: tutte le informazioni scambiate tra client e server vengono cifrate dal mittente e decifrate dal destinatario

Obbiettivi e prerequisiti

Lo scopo di queste pagine (e di quelle successivamente pubblicate) sarà configurare un'area del nostro web server in grado di scambiare dati cifrati con i client. Tralasceremo quasi del tutto ciò che concerne l'autorizzazione all'accesso mediante nome utente e password, che non rappresenta il punto focale della trattazione. A tal fine potrebbero essere adottati sia i meccanismi di autenticazione forniti da Apache, che quelli, più sofisticati, implementati mediante il linguaggio lato server preferito. Supporremo di disporre di un solo IP pubblico e di aver già configurato sul nostro server un host virtuale www.miosito.it, cui aggiungeremo un secondo host virtuale secure.miosito.it per realizzare la connessione sicura.

Assumeremo di lavorare con un sistema GNU/Linux su cui sia installato OpenSSL, il toolkit Open Source per implementare SSL v2/v3 e TLS v1, ed Apache 2 + mod_ssl il modulo, contributo di Ralf S. Engeschall, che consente il supporto a SSL/TLS. Le principali distribuzioni forniscono i pacchetti precompilati per OpenSSL mentre, se preferite i sorgenti, potete effettuarne il download dal sito ufficiale. Per chi, utilizzando Windows, voglia semplificarsi la vita, segnalo il Win32 OpenSSL Installer di Shining Light Productions.

Perché possiate comprendere il significato di tutte le operazioni di seguito illustrate, dovrete possedere almeno i rudimenti della crittografia asimmetrica basata su una chiave privata, segreta, ed una chiave pubblica liberamente distribuita. Purtroppo risulterebbe necessario lo spazio di un intero articolo per illustrare tali concetti. Su HTML.it esiste comunque una guida approfondita.

Istruzioni ed esempi di seguito riportati, si riferiscono in ad una Linux box Fedora Core 6 con OpenSSL 0.9.8b ed Apache 2.2.3.

Assumiamo il ruolo di CA (Certifcation Authority)

Un aspetto fondamentale della nostra connessione, come già accennato, riguarda l'autenticità del server. Prima di iniziare la comunicazione cifrata i client devono in qualche modo poter stabilire se il server sia effettivamente chi dice di essere o meno. Per questo il server fornirà loro un certificato digitale che si compone sostanzialmente di:

  • Una chiave pubblica
  • Informazioni riguardanti la sua identità
  • Una firma digitale di persona od organizzazione che certifica il legame tra informazioni identificative e chiave pubblica

Se dovessimo mettere online un sito commerciale la scelta obbligata sarebbe ricorrere a qualche nota Autorità di Certificazione (Verisign, Thawte etc.) perché ci fornisca, a pagamento, un certificato firmato digitalmente. Nel nostro caso consideriamo una situazione più "casalinga", quale potrebbe essere quella di una piccola applicazione aziendale in cui il numero e la configurazione dei client possano essere in qualche modo gestite. Assumiamo, quindi, personalmente il ruolo di CA utilizzando gli strumenti forniti da OpenSSL e risparmiamo anche qualche soldo.

Il primo passo sarà creare una chiave privata ed un certificato standard X.509 per la CA. Assumiamo i privilegi di root, creiamo una directory per contenere chiavi e certificati, posizioniamoci al suo interno ed infine mettiamoci al lavoro digitando:

[root]# openssl genrsa -des3 -out my-CA.key 2048

Con il precedente comando richiediamo la generazione di una chiave privata RSA, utilizzando l'algoritmo di cifratura Triple DES, che sarà salvata nel file my-CA.key ed avrà lunghezza pari a 2048 bit (512 è il default).

OpenSSL, dal canto suo, imporrà la scelta di una "pass phrase" che dovremo digitare tutte le volte che useremo la chiave privata. Per ragioni di sicurezza consiglio di scegliere una frase ben congegnata e sufficientemente lunga, ma, nello stesso tempo, che non possiate dimenticare!

Generating RSA private key, 2048 bit long modulus
..........................................................................................+++
...............+++
e is 65537 (0x10001)
Enter pass phrase for my-CA.key:
Verifying - Enter pass phrase for my-CA.key:

Passiamo ora alla generazione del certificato:

[root]# openssl req -new -key my-CA.key -x509 -days 3650 -out my-CA.crt

Il comando req serve a creare una richiesta di certificato (chiariremo più avanti cosa sia) o a generare un certificato autofirmato come nel nostro caso. Con -new specifichiamo che si tratta di una nuova richiesta in modo da poter inserire tutti i dati relativi al certificato. L'opzione -key indica la chiave privata usata per firmare il certificato, -x509 il formato del certificato, -days la validità in giorni del certificato in questo caso 10 anni, -out il nome del file generato per contenere il certificato.

La risposta di OpenSSL, di seguito riportata, prevede l'inserimento interattivo dei dati che saranno incorporati nel certificato. I valori digitati sono evidenziati in rosso.

Enter pass phrase for my-CA.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:IT
State or Province Name (full name) [Berkshire]:Italy
Locality Name (eg, city) [Newbury]: Miacittà
Organization Name (eg, company) [My Company Ltd]: Mia Azienda
Organizational Unit Name (eg, section) []: Certification Authority
Common Name (eg, your name or your server's hostname) []: Mia Azienda CA
Email Address []: ca@miosito.it                             

Come anticipato la prima richiesta sarà la pass phrase associata alla chiave privata my-CA.key, usata per firmare il certificato. I restanti dati servono ad identificarci come Autorità di Certificazione. Se siete curiosi di vedere che aspetto abbia il certificato apritelo con un editor di testo (senza modificarlo naturalmente), se volete rivedere le informazioni in esso contenute digitate:

[root]# openssl x509 -in my-CA.crt -text -noout

A questo punto smettiamo i panni di CA e riassumiamo le vesti di amministratore del server.

Creiamo un certificato per il server

La procedura che adotteremo sarà analoga a quella del paragrafo precedente con alcune piccole ma sostanziali differenze. Innanzitutto anziché creare un certificato X.509 creeremo una richiesta di certificato che sarà poi elaborata dalla CA per ottenere il certificato vero e proprio.

Procediamo con ordine generando la chiave privata del server che chiameremo my-server.key:

[root]# openssl genrsa -des3 -out my-server.key 1024

Sostanzialmente nulla di nuovo tranne la lunghezza limitata a 1024 bit. Valgono le stesse avvertenze per la pass phrase riportate in precedenza.

Passiamo a generare la richiesta di certificato my-server.csr. Per comodità vengono riportati in un unico riquadro sia il comando che la corrispondente risposta di OpenSSL:

 
[root]# openssl req -new -key my-server.key -out my-server.csr

Enter pass phrase for awb-server.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]: IT
State or Province Name (full name) [Berkshire]: Italy
Locality Name (eg, city) [Newbury]: Miacittà
Organization Name (eg, company) [My Company Ltd]: Mia Azienda
Organizational Unit Name (eg, section) []: Servizi Web        
Common Name (eg, your name or your server's hostname) []:secure.miosito.it
Email Address []:info@miosito.it

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Tutto procede come nel paragrafo precedente con una importante avvertenza: il Common Name fornito deve corrispondere all'indirizzo usato per la connessione SSL. In caso contrario i browser rileveranno un'incongruenza tra dati del certificato e sito web che fornisce tale certificato.

Come ultimo passo torniamo a travestirci da CA e dalla richiesta di certificato appena creata, generiamo il certificato in formato X.509, firmato con la chiave privata della CA:

 
[root]# openssl x509 -req -in my-server.csr -out my-server.crt -sha1 -CA my-CA.crt -CAkey my-CA.key -CAcreateserial -days 2190

Signature ok
subject=/C=IT/ST=Italy/L=Miacittà/O=Mia Azienda/OU=Servizi Web/CN=secure.miosito.it/emailAddress=info@miosito.it
Getting CA Private Key
Enter pass phrase for my-CA.key:

Le opzioni -in e -out chiaramente identificano il file utilizzato in ingresso ed il file ottenuto come uscita che abbiamo deciso di chiamare my-server.crt. Il certificato è firmato con my-CA.key come indica l'opzione -CAkey. La durata sarà di circa 6 anni, days 2190, comunque inferiore alla durata scelta in precedenza per il certificato della CA.

L'illustrazione di tutte le opzioni, costringendo a digressioni esemplificative, appesantirebbe la trattazione facendo perdere di vista gli elementi essenziali dell'articolo. Perciò se siete interessati a sviscerarne il significato digitiate "man x509" al prompt dei comandi e la vostra curiosità sarà appagata.

Conclusioni

Al termine della procedura siamo in possesso dei seguenti file:

  1. my-CA.key: chiave privata della CA
  2. my-CA.crt: certificato della CA
  3. my-server.key: chiave privata del server
  4. my-server.csr: richiesta di certificato del server
  5. my-server.crt: certificato del server

Consiglio di proteggerli adeguatamente sia a livello di permessi (chmod 400) che predisponendone una copia di sicurezza. Risulta evidente il danno provocato da un'appropriazione indebita o da una loro perdita per un guasto hardware. A questo punto non ci resta che configurare Apache perché, utilizzando alcuni dei file generati, sia in grado di instaurare una connessione SSL. Tutto ciò sarà argomento di un prossimo articolo.

Come avrete potuto osservare OpenSSL risulta un tool veramente interessante e potente e si intuisce che le sue applicazioni non si limitino solo ai nostri scopi. Non guasta, inoltre, che sia open source, disponibile gratuitamente e multipiattaforma. Prima di chiudere e darvi appuntamento a breve su queste pagine, voglio segnalare che la procedura descritta, con i necessari adattamenti, può essere proficuamente adottata per creare certificati per il web server di casa Microsoft IIS.....forse ci sarà occasione di spendere qualche parola in proposito.

Ti consigliamo anche