SSL - Principi e installazione

Overview di SSL e Apache

SSL (secure Socket Layer) è un protocollo che permette l'invio di pacchetti criptati in Internet ed possibile "abbinarlo" al normale HTTP per avere maggior sicurezza sul traffico prodotto dal server e dal client.
Questa soluzione viene adottata in molti casi, soprattutto per siti che richiedono un elevato livello di sicurezza come site e-commerce o siti che trattano informazioni personali. L'utilizzo del protocollo HTTPS (HTTP Secure) non implica che il server in questione diventi invulnerabile a possibili attacchi ma evita semplicemente (o rende molto più difficile) che il traffico possa essere "sniffato"  per dedurre informazioni come password o numeri delle carte di credito.

La procedura di criptazione dati è relativamente semplice, si basa su una chiave pubblica che il server invia al client ad ogni connessione, per permettergli di inviare in modo sicuro la propria key.
Questi pacchetti criptati possono essere letti solo dal server che ha rilasciato la chiave pubblica poiché sarà l'unico host a possedere la chiave privata, l'unica chiave che ha la possibilità di decriptare le informazioni ricevute.

Il browser grazie alla chiave pubblica inviatagli dal server, e il seguente scambio di chiavi fra client e server, permette di identificare entrambi in modo univoco per prevenire quel tipo di attacco denominato come mimicking (man-in-the-middle attack).

Tipicamente il protocollo HTTP e HTTPS sono distinti anche per quanto rigurda le porte in cui il servizio è tipicamente disponibile, il protocollo HTTP si usa sulla porta 80 e quello HTTPS sulla porta 443, quindi il nostro browser quando dovrà accedere ad una risorsa con il protocollo HTTPS la richiederà al server aprendo una connessione sulla porta 443.

Esistono molteplici soluzioni per l'implementazioni di SSL con Apache, come un progetto del core team di Apache Apache-SSL o anche soluzioni commerciali, ma l'opzione più comune è l'uso del modulo mod_ssl, poiché permette di astrarre le funzionalità di openssl in un modulo, e la sua portabilità in tutti i sistemi Unix e windows lo rendono un oggetto universale.

Compilazione di mod_ssl

Mod_ssl è il modulo più comune per la gestione del protocollo HTTPS in Apache.
E' un progetto nato nel 1998 dalla mente di Ralf S. Engelschall, deriva da un progetto esistente (Apache-SSL) e ormai si può definire la soluzione più utilizzata per implementare il protocollo HTTPS in Apache.
Il progetto è stato rilasciato tramite una licenza BSD-style, quindi è utilizzabile gratuitamente sia per scopi commerciali che non, oltre a poter essere riutilizzato autonomamente su progetti di terzi.

Semplificando, mod_ssl si può vedere come una patch del codice sorgente di Apache, e come qualsiasi altra patch deve essere correlata alla versione corretta del package da patchare.
Anche in questo caso si ha una versione di mod_ssl specifica per una versione specifica di Apache.
Per esempio, se si deve patchare Apache 1.3.23, la versione di mod_ssl corretta è mod_ssl-2.8.6-1.3.23.

La procedura di massima per l'installazione di mod_ssl tramite sorgenti si limita al lancio dello script configure con le opzioni per il patching dei sorgenti. Supponiamo di trovarci nella directory scompattare del tar.gz ufficiale, parallela alla directory dei sorgenti di Apache.
[root@dido mod_ssl-2.8.6-1.3.23]# ./configure --with-apache=../apache_1.3.23/ --with-ssl=../openssl-0.9.6g
Configuring mod_ssl/2.8.6 for Apache/1.3.23
+ Apache location: ../apache_1.3.23/ (Version 1.0)
+ OpenSSL location: ../openssl-0.9.6g
+ Auxiliary patch tool: ./etc/patch/patch (local)
+ Applying packages to Apache source tree:
[...]
Now proceed with the following commands:
$ cd ../apache_1.3.23/
$ make
$ make certificate
$ make install

Infine successivamente eseguire la compilazione e l'installazione di Apache come meglio si crede. Spostarsi nella directory in cui si trovano i suoi sorgenti e proseguire con il ./configure.
In questo caso viene abilitato il DSO mode per tutti i moduli disponibili compreso mod_ssl
[root@dido apache_1.3.23]# ./configure --with-layout=Apache --enable-module=most --enable-shared=max
[root@dido apache_1.3.23]# make
[root@dido apache_1.3.23]# make certificate
[root@dido apache_1.3.23]# make install

Nel caso in cui si debba installare mod_ssl per un Apache già in esecuzione e con il supporto DSO e EAPI abilitata  bisogna appoggiarsi ad apxs.
[root@dido root]# cd /usr/src/mod_ssl-2.8.6-1.3.23/
[root@dido mod_ssl-2.8.6-1.3.23]# ./configure --with-ssl=../openssl-0.9.6g --with-apxs=/usr/local/apache/bin/apxs
[...]
Installazione del modulo.
[root@dido mod_ssl-2.8.6-1.3.23]# /usr/local/apache/bin/apxs -i -a -n mod_ssl pkg.sslmod/libssl.so

Installazione OpenSSL

OpenSSL permette di implementare il protocollo SSL V2/V3 (Secure Sockets Layer) e il protocollo TLS V1 (Transport Layer Security) e consiste in un insieme di librerie per uso generale utilizzabili da terzi programmi.

E' un progetto interamente sviluppato da volontari e si basa sulle librerie SSLeay sviluppate da Eric A. Young e Tim J. Hudson. Le librerie non sono soggette a licenza GPL ma ad una licenza Apache-Style ovvero sia ha la possibilità di utilizzarle anche per uso commerciale ma con alcune limitazioni espresse nella licenza.

L'installazione tramite sorgenti o binari si effettua come qualsiasi altro package.

Procedura di massima per l'installzione di OpenSSL tramite sorgenti
- Scaricare i sorgenti  dal sito ufficiale e verificare MD5Sum.
- Scompattare il package:
[root@dido src]# tar zxvf openssl-0.9.6g.tar.gz
- Lanciare lo script configure con le opzioni che si preferiscono.
Storicamente la directory di installazione di OpenSSL e' /usr/local/ssl:
[root@dido src]# cd openssl-0.9.6g
E' possibile richiamare l'elenco delle opzioni disponibili con il seguente comando
[root@dido openssl-0.9.6g]# ./config --help
[.....]
Lo script config dovrebbe in modo del tutto automatico capire per quale sistema si stanno compilando le librerie, nel caso in cui dovesse fallire è possibile intervenire manualmente specificando le direttive
[root@dido openssl-0.9.6g]# ./config
Operating system: i686-whatever-linux2
Configuring for linux-elf
Configuring for linux-elf
IsWindows=0
[...]
Da tenere presente che non e' necessario installare del tutto le librerie per installare mod_ssl, ma potrebbe essere necessario per altri package come OpenSSH.
- Compilare con il comando make con le varie opzioni per la compilazione ed installazione:
[root@dido openssl-0.9.6g]# make
Per eseguire Test di verifica:
[root@dido openssl-0.9.6g]# make test
Per eseguire l'installazione delle librerie, binari e manuali
[root@dido openssl-0.9.6g]# make install
Oppure lanciare tutti e tre i comandi in una singola linea di comando
[root@dido openssl-0.9.6g]# make all test install > compile.log

Compilazione delle librerie Dinamiche
E' possibile compilare OpenSSL in modo tale che vengano caricate come librerie dinamiche, la procedura cambia a seconda dell'OS ma chi utilizza Linux può appoggiarsi al comando make specificando come target linux-shared e spostare manualmente le librerie.
[root@dido openssl-0.9.6g]# make
[...]
[root@dido openssl-0.9.6g]# make test
[...]
Occorre lanciare prima il comando make install poiché deve creare l'enviroment per librerie che si dovranno spostare manualmente
[root@dido openssl-0.9.6g]# make install
[...]
[root@dido openssl-0.9.6g]# make linux-shared
[...]
[root@dido openssl-0.9.6g]# mv lib* /usr/local/apache/libexec/ssl
[root@dido openssl-0.9.6g]# chmod 0664 /usr/local/apache/libexec/ssl/lib*

Configurazione base di mod_ssl

Lo step successivo all'installazione di mod_ssl è la configurazione di Apache per erogare il servizio tramite il protocollo HTTPS.

- Verificare in httpd.conf se avviene il caricamento del modulo tramite le direttive Addmodule e LoadModule.
LoadModule ssl_module         libexec/libssl.so
AddModule mod_ssl.c (Solo su Apache 1.3)

- Specificare le nuove porte a cui il servizio sarà in ascolto tramite le direttive Port o Listen:
Port 80
Listen 80
Listen 443

- Abilitazione del modulo mod_ssl. Occorrono tre direttive SSLEngine, SSLCertificateKeyFile e SSLCertificateFile:
Attivazione del modulo mod_ssl
SSLEngine on
Path per la chiave privata
SSLCertificateKeyFile conf/ssl/openskills.info.key
Path per il certificato
SSLCertificateFile conf/ssl/openskills.crt

Queste direttive possono essere specificate sia a livello di server configuration o per singolo virtual-host, ma per redirezionare tutto il traffico della porta 80 sulla porta 443 occorre specificare la direttiva SSLrequireSSL nel Directory container:
Redirige tutto il traffico sulla porta 443
<Directory />
SSLrequireSSL
</Directory>
Redirige sulla porta 443 le richieste che comprendono l'URL /private
<Directory /private/>
SSLrequireSSL
</Directory>

- Riavviare Apache e verificare che tutto funzioni:
[root@trinity root]# netstat -at | grep http
tcp        0      0 *:http                  *:*                     LISTEN      
tcp        0      0 *:https                 *:*                     LISTEN
poi con il proprio browser richiedere pagine al server web, sia con il protocollo http e https.

Client Certification

SSL può operare sia con client anonimi che supportono i protocolli e i ciphers specificati tramite le direttive SSLProtocol e SSLCipherSuite oppure autenticare il client tramite i certificati rilasciati dalle varie Certification Authority.

Per abilitare questa funzione occorre specificare al server (a livello di server configuration oppure per virtualhost) il path dove risiede l'elenco dei singoli certificati rilasciati da una CA tramite la direttiva SSLCACertificatePath:
SSLCACertificatePath /usr/local/apache/conf/ssl/cacerts

In alternativa c'è la possibilità di concatenare tutti i certificati in un unico file e specificare il path del file tramite la direttiva SSLCACertificateFile:
SSLCACertificateFile /usr/local/apache/conf/ssl/cacerts.crt

Infine occorre specificare il tipo di matching da eseguire sul client tramite la direttiva SSLVerifyClient la quale ha solo 4 opzioni:
none: Non viene richiesto nessun certificato e viene ignorato qualora il client ne fosse fornito. Settaggio di default.
optional: Non è richiesto nessun certificato, ma ne viene eseguito comunque un check per verificarne l'esistenza. (non è supportata da tutti i browser)
optional_no_ca: Non viene richiesto un certificato, ma se è presente viene accettato.
require: Viene richiesto un certificato valido.

Per esempio:
SSLVerifyClient require

E' possibile che un certificato di un client non sia stato rilasciato da una CA che il server riconosce come tale, ma a sua volta certificato da una seconda CA riconosciuta, quindi è come se ci fosse un intermediario che certifichi il client. E' possibile lato server decidere se accettare o meno questi tipi di certificati e se accettarli dando il numero massimo di intermediari, questo è possibile tramite la direttiva SSLVerifyDepth che come argomento si aspetta il numero max di intermediari per rendere valido il certificato.
L'impostazione di default, non accetta certificati che non sono stati rilasciati direttamente da un CA riconosciuta:
SSLVerifyDepth 1

Come è possibile aggiungere nuovi cerificati è possibile toglierli tramite le direttive SSLCARevocationFileeSSLCARevocationFile.

Autenticazione utenti tramite la certificazione dei client
E' possibile utilizzare i certificati per i client per effettuare un'autenticazione utente.
- Disabilitare la basic Authentification gestita dal modulo mod_auth:
SSLOptions +FakeBasicAuth
- Creazione di un semplice file con la lista dei client e delle relative password criptate, il nome viene dedotto dal certificato. Per estrarre la riga da inserire nel password file eseguire il seguente comando:
[neo@dido neo]$ openssl x509 -noout -subject -in certificate.crt
[neo@dido neo]$ /C=IT/L=MI/O=coresis/OU=OpenskillsTeam/CN=www.openskills.info:[password cryptata]

Il risultato del comando dovrà essere inserito nel password file.

Configurazione avanzata di mod_ssl - Server Level Configuration

Per avere un server funzionale non occorre una ricerca esasperata della configurazione ottimale di mod_ssl, ma questo modulo ci mette a disposizione un insieme di direttive che ci permette di avere un controllo totale sull'erogazione del servizio tramite il protocollo HTTPS.

Tutte le seguenti direttive dovranno essere inserite nel file di configurazione httpd.conf più precisamente all'altezza del server level configuration, da escludere l'uso di queste direttive per i singoli VirtualHosts.

SSLRandomSeed
La funzionalità random per SSL è fondamentale, poiché riduce al minimo la possibilità di deduzione della "key session" scambiata tra il client e il server. Tramite questa direttiva è possibile specificare la sorgente per questi dati casuali, la quale sarà interrogata o solo allo startup del server o ad ogni nuova connessione, ovviamente la seconda risulta più sicura ma pregiudica un poco le prestazioni del server.
La configurazione minima per questa direttiva è:
SSLRandomSeed startup builtin
Questo specifica al modulo mod_ssl che ad ogni startup deve utilizzare uno pseudo-random number generator all'interno del codice di mod_ssl, non è un vero e proprio generatore di dati casuali ma è sempre meglio di niente.
E' possibile utilizzare sempre la stessa sorgente per ogni nuova connessione:
SSLRandomSeed connect builtin
La soluzione migliore (in ambiente Unix) è quella di utilizzare i random device come /dev/random e /dev/urandom e opzionalmente specificare il numero di bytes da estrarre, ovviamente piu sono meglio è per quanto riguarda la sicurezza ma una richiesta potrebbe rivelarsi troppo onerosa in ambito di risorse del sistema.
La possibilità di estrarre un numero esatto di bytes è funzionale solo per /dev/urandom:
SSLRandomSeed connect /dev/random
SSLRandomSeed connect /dev/urandom 512
Oppure si ha la possibilità di utiliizare package esterni all'OS ed al modulo mod_ssl come truerand disponibile nella sottodirectory pkg.contrib di mod_ssl.
Più direttive SSLRandomSeed possono essere specificate di seguito per "aumentare la randomizzazione" dei dati:
SSLRandomSeed startup builtin
SSLRandomSeed startup /dev/urandom 1024
SSLRandomSeed connect builtin
SSLRandomSeed connect /usr/local/apache/bin/truerand 32
SSLRandomSeed connect /dev/urandom 512

SSL session cache
Le sessioni SSL possono essere, opzionalmente, cacheate per una maggior performance del server web. La direttiva che controlla il caching è SSLSessionCache con tre diverse possibilità:
Caching disabilitato, default configuration:
SSLSessionCache none
Caching tramite DBM db file:
SSLSessionCache dbm:path
Caching tramite shared memory segment stabilita da un file, con parametro opzionale per indicare la dimensione:
SSLSessionCache shm:path[size]

Per avere un maggior controllo della cache ci si può appoggiare alle direttive SSLSessiononCacheTimeout e SSLMutex. La prima identifica il timeout della cache e la seconda si può vedere come un semaforo che gestisce il write lock della cache, questo per avitare che più processi di Apache scrivino sulla stessa cache e quindi evitare sovrapposizioni e "scrambling" dei contenuti:
Cache time out di 300 sec per ogni sessione
SSLSessiononCacheTimeout 300
Uso del semaforo per locking della cache
SSLMutex sem
Le opzioni disponibili per la direttiva SSLMutex sono:
Disabilita il mutex lock:
SSLMutex none
Usa un file per indicare cha la cache è in lock:
SSLMutex file:path
Usa i semafori di sistema:
SSLMutex sem

Configurazione avanzata di mod_ssl - Per Directory configuration

Lo switch on o off del modulo mod_ssl non è possibile per i singoli virtualhost o per specifiche directory ma è possibile utilizzare due direttive SSLrequireSSL e SSLrequire per settare una configurazione per ogni singolo virtual host o directory.

SSLrequireSSL
Direttiva che obbliga l'uso di SSL per quando si richiede una risorsa all'interno di una directory o più semplicemnete per tutte le risorse di un virtual host. Ricordarsi che nel caso si voglia utilizzare il file .htaccess occorre specificare AllowOverride AuthConfig.
In httpd.conf se si vuole obbligare l'uso di SSL per accedere a /private si deve avere qualcosa di simile:
<Location /private>
SSLRequireSSL
</Location>

SSLRequire
Direttiva utilizzata per testare l'environment settato da mod_ssl ed Apache. I vari headers e variabili possono essere estratti e si può eseguire un controllo per verificare che la sorgente possa accedere alle risorse. La sintassi è complessa ma la sua estrema flessibilità permette di creare delle Access List più che funzionali:
SSLRequire ( %{HTTPS}eq "on" and %{SSL_PROTOCOL}ne "SSLv2"
and %{SSL_CHIPER_USERKEYSIZE} >= 128) or %{REMOTE_ADDR}= ~ m/^192\.168/
In questo caso, si verifica che SSL venga utilizzato con il protocollo v2 e che la key utilizzata sia almeno di 128 bit e solo se tutte le tre condizioni si sono verificate o se la sorgente abbia un IP con indirizzo di rete 192.168 si potrà accedere alla risorsa

SSLProtocol e SSLCipherSuite
E' possibile tramite la direttiva SSLProtocol controllare il protocollo e tramite SSLCipherSuite controllare il cipher utilizzati per la connessione.
Sono direttive che possono essere specificate anche al server level configuration.
I protocolli supportati sono:
- SSL v2 (l'implementazione originale di SSL)
- SSL v3 (di fatto lo standard odierno)
- TLS v1 (non del tutto supportato ancora).
Di default sono supportati tutti:
SSLProtocol all
ma è possibile restringere l'uso a uno o più protocolli:
SSLProtocol SSLv3
Anche in questo caso è possibile utillizzare il prefisso + e - per aggiungere o togliere protocolli ereditati dalle direttive precedenti, per esempio:
SSLProtocol SSLv3 -TLSv1

Mentre per verificare i cipher supportati occorre interrogare openssl:
[neo@dido neo]$ openssl ciphers
EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:RC2-CBC-MD5:RC4-MD5:
RC4-64-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:
EXP1024-RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:
EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5
Ci sono più di trenta possibilità, con ogni tipo di protocollo che può usare uno specifico Key exchange algorithm, authentication method, encrypt method e digest type.
Ognuno di questi quattro componenti può essere rimosso or riordinato nella lista dei ciphers.

La direttiva SSLCipherSuite ha come argomento uno o piu componenti (separati dai ":") che verranno aggiunti o modificati dalla lista a seconda del prefisso:
Accetta solo RSA key exchangee rifiuta l'export o la cryptazione nulla
SSLCiphersSuite RSA:!NULL:!EXP
Accetta tutti i ciphers ma da la precedenza a quelli che utilizzano SSLv2 e poi quelli SSLv3
SSLCiphersSuite ALL:+SSL2v2
Impostazione di default: accetta tutti i ciphers, tranne ADH(Diffle-Hellman Authentification), usa rc4 encoding per la cryptazione e RSA per il key exchange dando la precedenza ai cipers con una maggior cryptazione, con protocollo SSLv2 e l'export ciphers alla fine:
SSLCiphersSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

Gestire la password di startup di Apache+mod_ssl

Quando Apache è configurato per supportare SSL e la chiave privata utilizzata per la cryptazione dati è protetta tramite una pass phrase, tale pass phrase viene richiesta ad ogni avvio del server web.

Questo potrebbe risultare un problema se viene richiesto un avvio automatico del servizio dopo un down accidentale. Ci sono due possibilità per ovviare al problema:

- Rimuovere la password
E' possibile tramite openssl con il seguente comando:
openssl rsa -in www.openskills.info.key -out www.openskills.info.key
Per rimettere la password o per cambiarla:
openssl rsa -des3 -in www.openskills.info.key -out www.openskills.info.key

- SSLPassPhraseDialog
Direttiva che permette di delegare l'invio della pass phrase ad Apache all'avvio dello stesso.
Ovviamente la soluzione più idonea è quella di scrivere un piccolo script shell che esegue un echo della password. Per esempio:
#!/bin/sh
echo "password"
Nella configurazione di Apache basta poi richiamarlo con:
SSLPassPhraseDialog exec:/usr/local/apache/sbin/script.sh
Questa seconda soluzione può comportare un problema di sicurezza poiché la password è in chiaro in un file, potenzialmente leggibile da chiunque.

Creazione di certificati "fasulli"

Nel caso avessimo inviato la richiesta per un certificato ufficiale ad una CA (es Verisign) e non lo abbiamo ancora ricevuto o comunque volessimo poter stabilire connessioni sicure tramite https, è possibile creare certificati "fasulli" utilizzando openssl o mod_ssl.

Innanzitutto dobbiamo creare una chiave privata (es: private.key) ed una chiave pubblica (es: public.csr). Per far questo (presupponendo di avere installato un supporto SSL) basta andare nella directory dove si vuole generare la coppia di chiavi, esempio /usr/local/apache/ssl.certs/ , lanciare il seguente comando:
[root@eberk ssl.certs]# openssl req -new -nodes -keyout private.key -out public.csr
e inserire i dati richiesti.
Una volta generata la coppia di chiavi, per generare un certificato (.crt), basta lanciare il seguente comando:
[root@eberk ssl.certs]# openssl req -key private.key -in public.csr -out fakecertificate.crt
Ora il certificato è pronto, anche se l'abbiamo generato noi e non una CA.
Fatto cio, configurare httpd.conf aggiungendo le seguenti righe:
SSLCertificateFile /etc/ssl/crt/fakecertificate.crt
SSLCertificateKeyFile /etc/ssl/crt/private.key
Ora avviare Apache con supporto SSL.
Di fatto ora Apache risponderà alle richieste con una connessione http sicura.
Per testare se effettivamente ciò avviene lanciare il seguente comando di debug:
[root@eberk diego]# openssl s_client -connect localhost:443 (o 80) -state
Attenzione, Apache non si accorge che il certificato è "fasullo", ma il browser si, e comunicherà, con una finestra di pop-up, all'utilizzatore che il certificato non è stato rilasciato da nessuna delle CA da lui conosciute.

Oltre al metodo sopra illustrato è possibile generare un certificato finto durante la compilazione dei sorgenti di apache o tramite uno script all'interno dei sorgenti di mod_ssl.
Lo script è mkcert.sh ed è contenuto in mod_ssl nella sottodirectory pkg.sslsup, lo script genera una chiave privata e certificato di una CA customizzabile (ca.key e ca.crt) e chiave e certificato relativo a questa CA per il server (server.key e server.crt).
Una volta generati configurare httpd.conf con la stessa procedura sopra elencata.

Altro metodo per creare un certificato è lanciare il make certificate (dopo aver lanciato il comando configure e make) quando si compila Apache con il supporto mod_ssl.
Prevede diverse varianti di creazione/installazione in funzione alla necessità del certificato:
[root@eberk apache_1.3.17]# make certificate TYPE=dummy Crea un certificato realizzato dalla Snake Oil CA (ovviamente la snake Oil non esiste) intestato a se stessa.
[root@eberk apache_1.3.17]# make certificate TYPE=test Crea un certificato realizzato dalla Snake Oil CA dando la possibilità di customizzarlo rispondendo alla solita trafila di domande. Serve se si vuole testare un server.
[root@eberk apache_1.3.17]# make certificate TYPE=custom Per installare un certificato ufficiale rilasciato da una CA esistente. Serve se lo si vuole installare su una macchina reale in produzione.
[root@eberk apache_1.3.17]# make certificate TYPE=existing Utilizza un certificato gia esistente (upgrade del server).
L'opzione di default è TYPE=test. Make certificate setta i parametri di httpd.conf relative ai certificati, quindi nonn si ha la necessita di aggiungere a "mano" le 2 righe relative.

Generazione e installazione di chiavi e certificati (procedura per Verisign)

Per installare un certificato innanzitutto bisogna assicurarsi di avere installato il supporto SSL sul server web.

Generare una coppia di chiavi con OpenSSL
Andare nella directory dove si vuole generare la coppia di chiavi, esempio:
cd /usr/local/apache/ssl.certs/ e lanciare il comando:
openssl req -new -nodes -keyout private.key -out public.csr
Ora OpenSLL porrà una serie di domande a cui si dovra rispondere.
Assicurarsi che le informazioni inserite siano corrette.

Using configuration from /etc/ssl/openssl.cnf
Generating a 1024 bit RSA private key
.++++++
............++++++
writing new private key to 'private.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 ID.
There are a 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) [AU]:IT
State or province Name (full name) [Some-State]:Milan
Locality Name (eg,city) []:Milano
Organization Name (eg, company) [Internet Widgits Pty Ltd]: pippo spa
Organization Unit Name (eg, section) []:Information Technology
Common Name (eg, YOUR name) []:www.pippo.com
Email Address []:[email protected]

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

Nel mio esempio ho creato una chiave privata chiamata private.key e una chiave pubblica (CSR) chiamata public.csr.
Attenzione, la chiave privata non è criptata! Lanciare il seguente comando per criptarla:
[root@eberk ssl.certs]# openssl rsa -in private.key -des3 -out secureprivate.key
Nota: con la chiave privata criptata, Apache in fase di start chiederà ogni volta la passphrase inserita durante la generazione della chiave.
Ora cambiarne i permessi di modo che solo root possa leggere il file.
[root@eberk ssl.certs]# chmod 400 secureprivate.key
Rimuovere la vecchia chiave non criptata.

Una volta generato il CSR (e sicuri che i dati inseriti siano corretti) aprire il file con un editor di testi (notepad o VI vanno bene, word no, in quanto aggiunge caratteri invisibili), copiate il contenuto del file in una mail nel seguente modo.

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBJTCB0AIBADBtMQswCQYDVQQGEwJVUzEQMA4GA1UEChs4lBMHQ
XJpem9uYTENA1UEBxMETWVzYTEfMB0GA1UEChMWTWVs3XbnzYSBDb
21tdW5pdHkgQ29sbGVnZTEA1UEAxMTd3d3Lm1jLm1hcmljb3BhLmV
kdTBaMA0GCSqGSIb3DQEBAQUAA0kAMEYCQQDRNU6xslWjG41163gA
rsj/P108sFmjkjzMuUUFYbmtZX4RFxf/U7cZZdMagz4IMmY0F9cdp
DLTAutULTsZKDcLAgEDoAAwDQYJKoZIhvcNAQEEBQADQQAjIFpTLg
fmBVhc9SQaip5SFNXtzAmhYzvJkt5JJ4X2r7VJYG3J0vauJ5VkjXz
9aevJ8dzx37ir3P4XpZ+NFxK1R=
-----END NEW CERTIFICATE REQUEST-----

Aggiungere nella mail il server software da certificare dopo averne verificato la compatibilità.
Altre cose da aggiungere sono, se ci sono, i contatti e-mail le varie sezioni aziendali (es sezione tecnica), ed il metodo di pagamento.
Inviata la mail, verrà spedito tramite E-mail il certificato rilasciato dalla CA..
Infine per installare il certificato occorre editare il file di configurazione del server (nel nostro esempio httpd.conf) ed aggiungere i path della chiave privata e del certificato, esempio:
SSLCertificateFile /etc/sslcrt/public.crt
SSLCertificateKeyFile /etc/ssl/crt/private.key

SSL e Logging

Può essere definito un log a parte per le connessioni che utilizzano il protocollo HTTPS.

La direttiva in questione è SSLLog identica alla direttiva TransferLog:
SSLLog /logs/ssl.log

I messaggi di errore vengono loggati nel "normale" error log e la verbosità dei messaggi è controllabile tramite la direttiva SSLLogLevel come per la direttiva LogLevel accetta i seguenti  argomenti: none, debug, trace, info, warn, error. Nell'esempio si loggano solo messaggi di livello warn:
SSLLogLevel warn

Inoltre è possibile customizzare il contenuto dei messaggi tramite la direttiva LogFormat comunemente utilizzata anche per settare i normali log, addizionalmente si possono definire le seguenti variabili:
%{version}c equivalente a %{SSL_PROTOCOL}x
%{cipher}c  equivalente a %{SSL_CIPHER}x
%{subjectdn}c equivalente a %{SSL_CLIENT_S_DN}x
%{issuerdn}c equivalente a %{SSL_CLIENT_I_DN}x
%{errcode}c certificate verification error code
%{errstr}c certificate verification error string

Per esempio:
CustomLog logs/ssl_log "%h %t \ " %r\" %{SSL_PRTOTOCOL}x %{SSL_CIPHER}x  env=HTTPS

SSL e VirtualHost

Ci sono due possibili vie per configurare dei virtualhost con il supporto HTTPS, entrambe però richiedono virtualhost IP-based.

- Definire un singolo certificato e chiave privata nel main host, i quali verranno utilizzati da tutti i virtualhost.
- Definire certificati  e chiavi private per singoli virtual-host.

Evitare la rinegoziazione di protocollo fra server https e client

Ad ogni richiesta fatta da Apache tramite SSL dove è configurato un particolare protocollo o cipher a seconda della risorsa richiesta, si obbliga il client che ha eseguito la richiesta ad una nuova negoziazione sul protocollo secondo le direttive settate sul server a seconda della risorsa richiesta.

E' possibile evitare questa rinegoziazione (che porta via tempo e risorse) del protocollo tramite la seguente direttiva:
SSLOption +OptRenegotiate

Procedura di creazione di una chiave ssl per la sicurezza di accesso alle pagine web

L'SSL (Secure Socket Layer) è un protocollo di sicurezza per siti o parti di siti e serve per accedere in modo sicuro ad uno spazio web. E' possibile creare certificati digitali da utilizzare con Apache in questo modo:
- Andare nella directory di Apache: cd /etc/httpd/conf
- Rimuovere i certificati esistenti: rm ssl.key/server.key e rm ssl.crt/server.crt
- Creare la propria chiave: /usr/bin/openssl genrsa 1024 > /etc/httpd/conf/ssl.key/server.key
- Settare correttamente i permessi per l'accesso alla chiave: chmod 600 /etc/httpd/conf/ssl.key/server.key
- Creare il certificato vero e proprio: make testcert
- Fare ripartire il server Apache: service httpd restart (su RedHat/Fedora) o /etc/init.d/httpd restart

A questo punto possiamo provare il certificato digitando su un browser: https://indirizzoIPserver

Tips per la compilazione di OpenSSL

Ecco alcune opzioni che si possono specificare nel lancio dello script configure per abilitare o disabiliatre alcune features del package di openssl.

Threads, no-threads Abilita o disabilita l'uso del thread code nelle librerie. E' molto efficente ma causa problemi su molte piattaforme.
no-asm Disabilita il codice assembly per compilare le librerie
386 Opzione per compilare le librerie con codice assembly per i 386 compatibili
Il codice di default prevede un processore intel 486 o superiore
no-<cipher> Disabilita il chipher specificato (dsa,des,dh,bf,md2 etc..)
rsaref Opzione per la compilazione delle librerie con RSAREF richiesta negli States.

Esempio:
# ./config threads no-md2 rsaref

CAcert certificati SSL gratuiti

Ora puoi ottenere la sicurezza al giusto prezzo... Gratuitamente!

Per creare certificati digitali utilizzabili con la tecnologia SSL finora c'erano solo due opzioni: rivolgersi a un operatore commerciale e pagare il servizio oppure generare un certificato ("fasullo") al fine soltanto di utilizzare il protocollo HTTPS senza per niente garantire l'identità.

Ora con CAcert potete creare e gestire gratuitamente dei certificati che garantiscono l'identità.

Il sistema funziona ma ancora si deve aspettare per poter avere il certificato di CAcert nei browser più utilizzati (è sufficiente scaricare il certificato da CAcert.org per Mozilla/Firefox o IE). Usare questo servizio aiuterà alla espansione con conseguente miglioramento del supporto per i browser.

CAcert

Prima di tutto è necessario registrarsi sul sito http://www.cacert.org/ dal link apposito.

Dopo aver dato i vostri dati e un indirizzo email valido dovrete confermare l'indirizzo tramite un link che vi verrà spedito all'indirizzo specificato. Una volta confermato questo indirizzo sarà un indirizzo verificato da CAcert e sarà anche il Predefinito del vostro Account.

Verificare un dominio

Prima di creare il certificato per il server è necessario verificare il dominio. Per fare questo è sufficiente indicare il dominio da verificare tramite il link appostito e essere in grado di ricevere la mail di conferma a uno dei seguenti indirizzi:


[email protected]
[email protected]
[email protected]
[email protected]
[email protected]


A questo punto sarà possibile creare il certificato per il dominio example.tld o per una zona come wwwexample.tld.

Certificati per i Server (Server Certificates)

Per creare un certificato per un server usando OpenSSL dovete posizionarvi in una directory (non accessibile da altri utenti) e dare il comando:

# openssl req -nodes -new -keyout private.key -out server.csr


Potreste anche volere usare delle opzioni per impostare la durata del certificato

openssl req -nodes -new -days 1825 -keyout private.key -out server.csr


A questo punto vi verranno chieste delle informazioni riguardo al certificato

Generating a 1024 bit RSA private key
.....++++++
.................++++++
writing new private key to 'private.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) [AU]:IT
State or Province Name (full name) [Some-State]:Milano
Locality Name (eg, city):Milano
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Società Srl
Organizational Unit Name (eg, section): CED
Common Name (eg, YOUR name):Nome Responsabile
Email Address: [email protected]

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