GET /topic.php - HTTP/1.1
Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR
1.1.4322)
146.133.13.36:38177 -> openskills.info:80

TOPIC | INFOBOX |
RESOURCES
| LIVE
DISCUSSION

Login

SSL - Principi e installazione

Installazione e configurazione di openssl e mod_ssl, Creazione di
chiavi e certificati.

Normal View - Full View
- Short
View

Insert
Infobox

Overview di
SSL e Apache

Author: neo - Last Update:
2002-11-25 17:20:06 - Creation Date: 2002-11-25
17:20:06
Infobox Class: DESCRIPTION - Skill: 2- JUNIOR

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.

Configurazione di
mod_ssl

Author: neo - Last Update:
2002-11-25 17:28:12 - Creation Date: 2002-11-25
17:28:12
Infobox Class: DESCRIPTION - Skill: 3-
INTERMEDIATE

Mod_ssl è il modulo più comune per la gestione del protocollo HTTPS in
Apache.
E' un progetto relativamente giovane, 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

Configurazione base di
mod_ssl

Author: neo - Last Update:
2002-11-25 17:46:46 - Creation Date: 2002-11-25
17:46:46
Infobox Class: DESCRIPTION - Skill: 3-
INTERMEDIATE

Lo step successivo all'installazione è 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

-
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.

Installazione OpenSSL

Author: neo - Last Update:
2004-11-10 23:20:03 - Creation Date: 2004-11-10
23:20:03
Infobox Class: DESCRIPTION - Skill: 3-
INTERMEDIATE

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*

Client
Certification

Author: neo - Last Update:
2002-11-25 18:01:14 - Creation Date: 2002-11-25
18:01:14
Infobox Class: DESCRIPTION - Skill: 3-
INTERMEDIATE

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

Author: neo - Last Update:
2002-11-25 18:37:53 - Creation Date: 2002-11-25
18:37:53
Infobox Class: DESCRIPTION - Skill: 4-
ADVANCED

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

Author: neo - Last Update:
2002-11-25 18:49:17 - Creation Date: 2002-11-25
18:49:17
Infobox Class: DESCRIPTION - Skill: 4-
ADVANCED

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

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

Author: rpennol - ( Revision:
al ) - Last Update:
2004-03-23 21:57:42 - Creation Date: 2004-03-23
21:57:42
Infobox Class: DESCRIPTION - Skill: 3-
INTERMEDIATE

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

Creazione
di certificati "fasulli"

Author: Eberk - ( Revision: al ) - Last Update:
2002-11-25 19:32:30 - Creation Date: 2002-11-25
19:32:30
Infobox Class: TIPS - Skill: 3- INTERMEDIATE

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)

Author: Eberk - Last Update:
2002-11-25 17:53:47 - Creation Date: 2002-11-25
17:53:47
Infobox Class: TIPS - Skill: 3- INTERMEDIATE

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-masked]

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

Tips per la
compilazione di OpenSSL

Author: neo - Last Update:
2002-11-25 19:34:24 - Creation Date: 2002-11-25
19:34:24
Infobox Class: TIPS - Skill: 4- ADVANCED

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

SSL e
Logging

Author: neo - Last Update:
2002-11-25 17:49:25 - Creation Date: 2002-11-25
17:49:25
Infobox Class: TIPS - Skill: 4- ADVANCED

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

Author: neo - Last Update:
2002-11-25 19:35:11 - Creation Date: 2002-11-25
19:35:11
Infobox Class: TIPS - Skill: 2- JUNIOR

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.

Evitazione
rinegoziazione di protocollo fra server https e client

Author: neo - Last Update:
2002-11-25 19:37:14 - Creation Date: 2002-11-25
19:37:14
Infobox Class: TIPS - Skill: 3- INTERMEDIATE

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

Gestire la
password di startup di Apache+mod_ssl

Author: neo - Last Update:
2002-11-25 19:48:16 - Creation Date: 2002-11-25
19:48:16
Infobox Class: TIPS - Skill: 3- INTERMEDIATE

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.

Remote
Host Viewer | Environment Variables |
Server
Status