Autorità di certificazione locale: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
(da adottare)
 
(30 versioni intermedie di 6 utenti non mostrate)
Riga 1: Riga 1:
In questa guida tratteremo come configurare la scheda PCMCIA '''''U2Speed''''' su ''Debian '''Sarge''''' installata sul mitico Thinkpad T20.
{{Guida da adottare}}{{Versioni compatibili}}
=Note sulla compatibilità=
La guida è compatibile '''soltanto con Apache 1''', la versione apache 2 non è idonea a questa guida.
==Introduzione==
L'utilizzo di un'autorità di certificazione locale (''self signed CA'') trova applicazione in tutti quei casi in cui non sia necessario che una root CA esterna firmi i nostri certificati.


Uno scenario tipico è quello in cui si voglia realizzare un sistema di autenticazione web basato su certificati: per autenticarsi i client devono presentare il certificato richiesto.


Illustrerò come generare una CA locale, come usarla per creare certificati lato server e lato client, infine mostrerò come revocare un certificato.


== OS ==
==Installazione e Configurazione di Openssl==
<div align="left" style="width:100%;  border: none; padding: 0.4em;">
Per installare la libreria [http://it.wikipedia.org/wiki/Secure_Sockets_Layer:Link SSL] e gli applicativi necessari alla creazione di chiavi e certificati dare il comando:
{| cellpadding=5 cellspacing=1 border=0
<pre># apt-get install openssl</pre>
|-
|align=left width=100% style="background-color:#f3f3ff; border:1px solid"|
Il sistema operativo Debian Sarge si basa sul '''kernel 2.6.8'''. L'installazione � stata eseguita senza  particolari rilevanti quindi viene utilizzato il sistema di default linux26.
|}
</div>


== La rete ==
Per minimizzare la quantità di informazioni richieste durante la creazione di chiavi e certificati, può
<div align="left" style="width:100%;  border: none; padding: 0.4em;">
essere utile modificare il file <code>/etc/ssl/openssl.cnf</code> per esempio alla seguente sezione:
{| cellpadding=5 cellspacing=1 border=0
<pre>
|-
[ req_distinguished_name ]
|align=left width=100% style="background-color:#f3f3ff; border:1px solid"|
AccessPoint Router USRobotics USR9110 rende possibile la navigazione WiFi ai terminali circostanti.<br>
''Nota'': si consiglia l'aggiornamento al firmware v5.0 del sopracitato Access Point [http://www.usr-emea.com/support/s-prod-template.asp?loc=itly&prod=9110 download].<br>
Il terminale di nostro interesse � il Thinkpad T20, (os Debian Sarge) con in dotatazione la '''PCMCIA'''
'''Wireless Adapter [http://www.upspeed.net UPspeed]''' sulla quale � installato il chipset  [http://www.marvell.com/ '''Marvell Tecnology'''].
|}
</div>


== Pacchetti specifici necessari ==
countryName            = Country Name (2 letter code)
''ndiswrapper-utils''
countryName_default    = IT
''ndiswrapper-module-2.6.8-x''
...
''wireless-tools''
stateOrProvinceName            = State or Province Name (full name)
''pcmcia-cs''
stateOrProvinceName_default    = Italy
''apmd
...


== SetUp ==
0.organizationName              = Organization Name (eg, company)
Eseguire
0.organizationName_default      = Azienda SpA
<pre>
...
# su -
</pre>
 
==Generazione di una CA locale==
Per mezzo di questa autorità di certificazione saranno creati tutti gli altri certificati: quello del server e quelli dei client.
 
===Creazione della chiave (root CA)===
Prima del certificato è necessario creare una chiave. Il seguente comando genera nella directory <code>/etc/openssl/private</code> la chiave privata <code>ca.key</code> di 1024 bit criptata con algoritmo ''triple DES'':
<pre># openssl genrsa -des3 -out private/ca.key 1024
Enter pass phrase for private/ca.key:
Verifying - Enter pass phrase for private/ca.key:
</pre>
</pre>
per portarci in modalit root.
Per prima cosa aggiorniamo Apt: osserviamo il file ''/etc/apt/source.list'' e digitiamo ''apt-get update''.
Attraverso l'uso di una Gui come Synaptic (oppure se preferibile attraverso la shell) scarichiamo i pacchetti:<br>
<ul><li>'''ndiswrapper-utils'''</li>
<li>'''ndiswrapper-modules-2.6.8-x''' (se necessario anche ndiswrapper-common)</li>
''N.B.'' Potrebbe essere necessario ricompilare ndiswrapper dai [http://ndiswrapper.sourceforge.net/ sorgenti]
<li>'''wireless-tools'''</li></ul>


A questo punto dopo aver installato il pacchetto '''apmd''':<br>
La chiave sarà generata dopo aver immesso la ''pass phrase''.
<ul><li>Aggiungere al file ''/etc/modules'' la riga ''apm''</li>
<li>Aggiungere nel file ''/boot/grub/menu.lst'' il parametro del kernel ''apm=on''</li></ul><br>


Assicuriamoci che anche il modulo '''pcmcia-cs''' sia installato (lsmod | grep pcmcia-cs).<br><br>
{{ warningbox | vista l'importanza della chiave privata a livello sicurezza, dare gli opportuni permessi alla directory <code>/etc/openssl/private</code> e a <code>ca.key</code>. }}


Adesso � necessario procurarsi il driver in esame della Marvell Tecnology.<br>
===Generazione del certificato (root CA)===
Quindi possiamo utilizzare due strade:<br>
Prima di procedere assicurarsi che <code>/etc/ssl/index.txt</code> sia vuoto e che <code>/etc/ssl/serial</code> contenga il valore 01.
1) Utilizzare il driver del cd in dotazione (consiglio i driver per windows98)<br>
2) Scaricare il driver da [http://downloads.trendnet.com/TEW-421PC_B1/Driver/Utility_Driver_TEW-421PC_423PI_b1_2.00.zip questo link]<br>


'''N.B.''' Per questa fase rimando alla dettagliata guida che troviamo [http://guide.debianizzati.org/index.php/NdisWrapper qui]<br>
Utilizziamo la chiave creata nella sezione [[#Creazione della chiave (root CA)|Creazione della chiave (root CA)]], per generare un certificato root CA <code>ca.crt</code> con validità di un anno:
<pre># openssl req -config /etc/ssl/openssl.cnf -new -x509 -key private/ca.key -out ca.crt -days 365
Enter pass phrase for private/ca.key:</pre>


Il certificato appena creato sarà utilizzato esclusivamente per firmare tutti gli altri certificati generati in seguito.


A questo punto avviamo ndiswrapper
Affinché i browser possano riconoscere come valida la ''root CA'' appena creata, gli utenti finali dovranno installare il certificato <code>ca.crt</code> nei loro browser. Riferirsi alla sezione [[#Certificato lato client | Certificazione lato client]] per ottenere maggiori informazioni.


<pre>
Aggiungendo l'opzione <code>-batch</code> al precedente comando potremmo automatizzare l'operazione utilizzando i valori predefiniti impostati nel file <code>/etc/ssl/openssl.cnf</code>. Utile quando il comando è utilizzato in uno script.
# ndiswrapper
 
Usage: ndiswrapper OPTION
==Certificato lato server==
Manage ndis drivers for ndiswrapper.
Questo è il certificato che il server utilizza per cifrare i dati scambiati con i vari client. Un tipico esempio è un server ''https''.
-i inffile        Install driver described by 'inffile'
-d devid driver  Use installed 'driver' for 'devid'
-e driver        Remove 'driver'
-l                List installed drivers
-m                Write configuration for modprobe
-hotplug          (Re)Generate hotplug information
</pre>


<pre>
====Creazione della chiave (server)====
# ndiswrapper -i /media/cdrom/drivers/nomedriver.inf
Il modo in cui creare la chiave e le osservazioni da fare sono le stesse viste nella sezione [[#Creazione della chiave (root CA)|Creazione della chiave (root CA)]]:
</pre>
<pre># openssl genrsa -des3 -out private/server.key 1024
Enter pass phrase for private/server.key:
Verifying - Enter pass phrase for private/server.key:</pre>


il driver Ndis � stato installato, per verificare l'insieme dei drivers installati utilizziamo il comando ndiswrapper
È molto probabile che la chiave generata sia poi utilizzata insieme al relativo certificato nella configurazione di ''apache''; in tal caso ''apache'' attenderà ad ogni avvio che venga inserita la ''pass phrase'' relativa alla chiave utilizzata. Vista la scomodità di tale soluzione, si può togliere la ''pass phrase'' dalla chiave:
<pre># openssl rsa -in private/server.key -out private/server.key.unsecure
Enter pass phrase for private/server.key:
writing RSA key</pre>


<pre>
{{ Warningbox | la chiave priva di ''pass phrase'' non è protetta, quindi assicurarsi che abbia i permessi opportuni.}}
# ndiswrapper -l
Installed ndis drivers:
nomedriver driver present
</pre>


Adesso inseriamo la scheda PCMCIA UPspeed nella porta e osserviamo come reagisce il sistema.<br>
===Generazione di una Certificate Signing Request (CSR)===
Digitiamo:
Con la chiave creata nella sezione [[#Creazione della chiave (server)|Creazione della chiave (server)]] generiamo una richiesta di firma per il certificato lato server che stiamo creando:
<pre>
<pre># openssl req -config /etc/ssl/openssl.cnf -new -key private/server.key -out server.csr
# ndiswrapper -l
Enter pass phrase for private/server.key:</pre>
Installed ndis drivers:
nomedriver driver present, '''hardware present'''
</pre>
<pre>
# dmesg
</pre>
Poi
<pre>
# lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
00:03.0 Ethernet controller: 3Com Corporation 3c556B CardBus [Tornado] (rev 20)
00:03.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem (rev 20)
00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)
00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)
02:00.0 Ethernet controller: Unknown device 1faa (rev 03)
</pre>


A questo punto dobbiamo fare in modo di caricare in memoria il modulo ndiswrapper in modo che lo stesso possa finalmente gestire la nostra scheda Wireless:
Impartito il comando, è richiesta in input una serie di informazioni tra cui la più importante è quella relativa all'opzione <code>commonName</code> in cui va specificato l'<code>FQDN</code> del server che utilizzerà il certificato, al fine di evitare problemi di "fiducia" coi client.


===Firma della CSR===
Quando disponiamo di una ''CSR'' è necessario spedirla alla ''CA'' scelta affinché la firmi, tuttavia se abbiamo provveduto, come spiegato nella sezione [[#Generazione di una CA locale|Generazione di una CA locale]], alla creazione di una nostra ''CA'' , possiamo firmare noi la ''CSR'' ottenuta alla sezione [[#Generazione di una Certificate Signing Request (CSR)|Generazione di una Certificate Signing Request]]:
<pre>
<pre>
# modprobe ndiswrapper
# openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -keyfile private/ca.key \
</pre>
> -cert ca.crt -in server.csr -out certs/server.crt
Se la scheda Wireless viene finalmente inizializzata allora � pronta per lavorare, per verificare lo stato dell'interfaccia Wireless utilizziamo l'utility iwconfig (Wireless Tools for Linux - [http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html])
Enter pass phrase for private/ca.key:</pre>
 
Il risultato del precedente comando è il file <code>/etc/ssl/certs/server.crt</code>, l'aggiornamento di <code>/etc/ssl/index.txt</code> e di <code>/etc/ssl/serial</code>. A questo punto il file <code>server.csr</code> non è più necessario.
Il risultato dell'operazione è il certificato per mezzo del quale il server https cifrerà i dati scambiati con i client.


<pre>
==Configurazione Web Server==
# iwconfig
Prendo in considerazione solo la configurazione relativa ad ''apache'' , in particolare ad ''apache-ssl''. Utilizzando ''apache'' con ''mod-ssl'' si dovrebbero ottenere risultati analoghi.
lo        no wireless extensions.
eth0      no wireless extensions.
sit0      no wireless extensions.
wlan0    IEEE 802.11g  ESSID:off/any
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:00:00:00:00:00
          Bit Rate:54 Mb/s  Tx-Power:16 dBm
          RTS thr:2347 B  Fragment thr:2346 B
          Encryption key:off
          Power Management:off
          Link Quality:100/100  Signal level:-10 dBm  Noise level:-256 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0  Missed beacon:0
</pre>


{{ Warningbox | '''N.B.''' Se i nostri output dei comandi ''iwconfig'' e ''dmesg'' non sono regolari ma differenti da quelli sopra (esempio iwconfig non riconosce la rete wlan0, oppure un errore del tipo **DANGER** relativo al kernel in output a dmesg) allora forse avete incontrato il problema che ha spinto uomolosco a scrivere questa guida. Passiamo quindi direttamente [http://guide.debianizzati.org/index.php/PCMCIA_WiFi_UPspeed_su_Debian_Sarge_on_Thinkpad_T20#Solution qui].<br> }}
===Direttive apache-ssl===
Importanti sono le seguenti direttive:
; SSLCACertificatePath: indica la directory dove sono contenuti certificati e ''CRL'' (''Certificate Revocation List'')
Esempio: <code>SSLCACertificatePath /etc/ssl</code>
; SSLCertificateFile: indica il certificato lato server per mezzo del quale i dati vengono cifrati. Secondo quanto riportato in questa guida esso corrisponde al file <code>/etc/ssl/certs/server.crt</code>.
Esempio: <code>SSLCertificateFile server.crt</code>
; SSLCertificateKeyFile: indica la chiave privata del certificato lato server. Secondo quanto qui riportato essa corrisponde al file <code>/etc/ssl/private/server.key</code>. Per maggiori informazioni vedere l'osservazione sulle chiavi private fatta nella sezione [[#Certificato lato server|Certificato lato server]].
Esempio: <code>SSLCertificateKeyFile server.key</code>
; SSLVerifyClient: definisce la certificazione di cui i client necessitano per autenticarsi.
Esempio: <code>SSLVerifyClient 2  #The client must present a valid certificate.</code>
; SSLVerifyDepth: nel nostro caso va impostata a 1 in quanto ci fidiamo solo di certificati firmati dalla nostra CA locale.
Esempio: <code>SSLVerifyDepth 1</code>
;SSLUseCRL: i certificati client sono controllati basandosi sull'appropriata ''CRL''. La ''CRL'' deve essere in formato ''PEM''. è necessario un link simbolico alla ''CRL'' posto all'interno del percorso indicato dalla direttiva '''SSLCACerificatePath'''. Non prende argomenti. Il percorso della ''CRL'' è specificato da '''SSLCACertificatePath.''' I link simbolici alle ''CRL'' hanno la forma <code><hash>.r<number>, dove <hash></code> è l'hash del file contenente la ''CRL''. La sezione [[#Apache e CRL | Apache e CRL]] spiega come creare link simbolici di tale tipo.
Esempio: <code>SSLUseCRL</code>
; SSLOnRevocationSetEnv: se il client presenta un certificato revocato, la sessione SSL è stabilita e la variabile indicata è impostata. L'idea è di gestire con uno script questo tipo d'errore. Per la descrizione delle altre direttive del tipo ''SSLOn*SetEnv'' riferirsi alla documentazione di ''apache''.
Esempio: <code>SSLOnRevocationSetEnv SSL_REVOKED</code>


===Apache e CRL===
Questa sezione tratta della configurazione di ''apache-ssl'' per l'uso di ''CRL''. Riferirsi a [[#Revoca di un certificato | Revoca di un certificato]] e in particolare a [[#Creazione e aggiornamento di una CRL | Creazione e aggiornamento di una CRL]].


Bene se ci troviamo a questo punto possiamo dire che il pi� � fatto.<br>
Affinché ''apache-ssl'' sia informato sulla validità dei certificati, è necessario l'utilizzo delle direttive '''SSLCACertificatePath''' e '''SSLUseCRL'''. La prima indica il percorso in cui cercare la ''CRL'', la seconda istruisce il demone a fare uso della ''CRL''.
Per consentire alla nostra macchina di caricare il modulo ndiswrapper con il boot del sistema operativo dobbiamo modificare il file ''/etc/modules'' utilizzando sempre l'utility ndiswrapper


La ''CRL'' deve essere puntata da un link simbolico della forma <code><hash>.r<number></code> presente all'interno del percorso indicato dalla direttiva '''SSLCACertificatePath''' (p.e. <code>/etc/ssl</code>):
<pre>
<pre>
# ndiswrapper -m
# cd /etc/ssl
Adding "alias wlan0 ndiswrapper" to /etc/modules
# hash=`openssl crl -hash -in crl/crl.pem -noout`
# ln -sf crl/crl.pem $hash.r0
# ls -l $hash.r0
 
lrwxr-xr-x  1  root  root  11 2004-09-24 10:41 bb6e3a6b.r0 -> crl/crl.pem
</pre>
</pre>


'''N.B.''' E' necessario editare manualmente il file ''/etc/modules'' aggiungendo la riga ''ndiswrapper''.<br>
===CA, certificati e CRL per virtual host===
 
Tutte le direttive elencate nella sezione [[#Direttive apache-ssl|Direttive apache-ssl]] possono essere utilizzate nei contesti ''server config'' e ''virtual host''.
Per utilizzare una connessione di rete Wireless che dobbiamo procedere con la configurazione della scheda di rete Wireless affinch� la stessa sia in grado di colloquiare con l'access point (AP).
Ora ricorriamo nuovamente all'utilizzo dell'utility iwconfig


La prima conseguenza è che si possono specificare ''CA'', ''CRL'' e certificati distinti per ogni singolo host virtuale.
La seconda conseguenza è che si può creare confusione tra le direttive nei contesti ''server config'' e ''virtual host''. Si consideri una configurazione del tipo seguente:
<pre>
<pre>
# iwconfig -h
[...]
Usage: iwconfig interface [essid {NN|on|off}]
SSLOnRevocationSetEnv SSL_REVOKED
                          [nwid {NN|on|off}]
[...]
                          [mode {managed|ad-hoc|...}
<VirtualHost x.y.z.w:443>
                          [freq N.NNNN[k|M|G]]
SSLCACertificateFile /etc/ssl/virtual1/ca.crt
                          [channel N]
SSLCertificateFile /etc/ssl/virtual1/certs/server.crt
                          [ap {N|off|auto}]
SSLCertificateKeyFile /etc/ssl/virtual1/private/server.key
                          [sens N]
SSLCACertificatePath /etc/ssl/virtual1
                          [nick N]
SSLUseCRL
                          [rate {N|auto|fixed}]
[...]
                          [rts {N|auto|fixed|off}]
</VirtualHost>
                          [frag {N|auto|fixed|off}]
                          [enc {NNNN-NNNN|off}]
                          [power {period N|timeout N}]
                          [txpower N {mW|dBm}]
                          [commit]
</pre>
</pre>
Quando è revocato un certificato client relativo al virtual host <code>x.y.z.w</code>, il risultato potrebbe non corrispondere a quanto voluto. Se si visitasse l'URL <code>https://x.y.z.w</code> con il browser in cui è installato il certificato revocato, si noterebbe che l'accesso non verrebbe impedito. Questo accade perché '''SSLOnRevocationSetEnv SSL_REVOKED''' non nega l'accesso ai certificati revocati, ma imposta la variabile '''SSL_REVOKED''' a "YES" e la direttiva posta nel contesto ''server config'' ha valore anche per gli host virtuali.
La soluzione è quella di commentare la direttiva nel contesto ''server config'' e attivarla, se serve, per ogni singolo host virtuale.


in alto possiamo visualizzare alcune delle opzioni che utilizzeremo per configurare al meglio la nostra scheda di rete Wireless, in particolare utilizzeremo le seguenti impostazioni
==Certificato lato client==
I passi da seguire per la creazione dei certificati lato client sono essenzialmente analoghi a quelli illustrati nella sezione [[#Certificato lato server | Certificato lato server]].


===Creazione chiave (client)===
Prima di tutto generiamo la chiave. La ''pass phrase'' utilizzata servirà all'utente finale per autenticarsi nelle zone protette del server web.
<pre>
<pre>
# iwconfig wlan0 rate auto
# openssl genrsa -des3 -out private/client1.key 1024
# iwconfig wlan0 mode managed
Enter pass phrase for private/client1.key:
# iwconfig wlan0 channel 11
# iwconfig wlan0 key s:WEP_KEY enc open
# iwconfig wlan0 essid nome_nodo
</pre>
</pre>


a questo punto dovremmo attivare l'interfaccia di rete wlan0 per collegarci con l'AP (access point)
===Generazione di una CSR per il client===
<pre>
# openssl req -config /etc/ssl/openssl.cnf -new -key private/client1.key -out client1.csr
Enter pass phrase for private/client1.key:
</pre>


===Firma della CSR per il client===
La ''CSR'' va firmata dalla nostra ''CA'' locale:
<pre>
<pre>
# ifconfig wlan0 up
# openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -keyfile private/ca.key \
> -cert ca.crt -in client1.csr -out certs/client1.crt
Enter pass phrase for private/ca.key:
</pre>
</pre>


ora non ci resta che farci assegnare un indirizzo IP dall'AP utilizzando il nostro client dhcp.<br>
a questo punto il file <code>client1.csr</code> non è più necessario. Infine <code>client1.crt</code> e <code>client1.key</code> vanno messi in un unico file:
Buona navigazione tra i fili!!!
<pre>
<pre>
# dhclient wlan0
# cat private/client1.key > private/client1.pem
# cat certs/client1.crt >> private/client1.pem
</pre>
</pre>


== Solution ==
quindi generare il file ''PKCS'' da importare nel browser dell'utente finale:
Se ci troviamo qui significa che qualcosa non va nonostante siamo abbiamo eseguito tutto come da porcedura.
<pre>
Ci sono vari motivi per cui l'installazione del driver non � andata a buon fine..
# openssl pkcs12 -export -in private/client1.pem -out pkcs/client1.p12 -name "Certificato Client 1"
* il driver .inf errato
Enter pass phrase for private/client1.pem:
* un errore nostro nei passaggi
Enter Export Password:
* ecc.. ecc..
Verifying - Enter Export Password:
 
</pre>
Se decidessimo di cercare nuovi driver sarebbe buona cosa muoverci conoscendo il pciId della scheda, cosa
ottenibile facilmente digitando prima
lspci
e poi
lspci -n
{{Box | Esempio |Se l'output di lspci � questo <br>
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)<br>
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)<br>
00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)<br>
00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)<br>
00:03.0 Ethernet controller: 3Com Corporation 3c556B CardBus [Tornado] (rev 20)<br>
00:03.1 Communication controller: 3Com Corporation Mini PCI 56k Winmodem (rev 20)<br>
00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)<br>
00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)<br>
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)<br>
00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)<br>
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)<br>
01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 11)<br>
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88w8335 [Libertas] 802.11b/g Wireless (rev 03)<br>
e quello di lspci -n � <br>
00:00.0 Class 0600: 8086:7190 (rev 03)<br>
00:01.0 Class 0604: 8086:7191 (rev 03)<br>
00:02.0 Class 0607: 104c:ac1b (rev 03)<br>
00:02.1 Class 0607: 104c:ac1b (rev 03)<br>
00:03.0 Class 0200: 10b7:6056 (rev 20)<br>
00:03.1 Class 0780: 10b7:1007 (rev 20)<br>
00:05.0 Class 0401: 1013:6003 (rev 01)<br>
00:07.0 Class 0680: 8086:7110 (rev 02)<br>
00:07.1 Class 0101: 8086:7111 (rev 01)<br>
00:07.2 Class 0c03: 8086:7112 (rev 01)<br>
00:07.3 Class 0680: 8086:7113 (rev 03)<br>
01:00.0 Class 0300: 5333:8c12 (rev 11)<br>
02:00.0 Class 0200: 11ab:1faa (rev 03)<br>
 
..allora il pciId relativo a 02:00.0 � 11ab:1faa
  }}
 


Per spiegare il problema che uomolosco ha incontrato e poi risolto, digitiamo
Ovviamente la pass phrase per <code>/etc/ssl/private/client1.pem</code> è la stessa di <code>/etc/ssl/private/client1.key</code>. La ''Export Password'' viene richiesta al momento dell'importazione del file ''PKCS'' nel client browser.
<pre>  
# lspci -vv
00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
        Subsystem: IBM Thinkpad T20
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 168, Cache Line Size 20
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 50000000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
        Memory window 0: 20000000-21fff000 (prefetchable)
        Memory window 1: 22000000-23fff000
        I/O window 0: 00001400-000014ff
        I/O window 1: 00001800-000018ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
        16-bit legacy interface ports at 0001


00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
===Importazione dei certificati===
        Subsystem: IBM Thinkpad T20
I certificati da importare nel browser secondo quanto fin qui descritto sono:
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
# <code>ca.crt</code> - certificato della ''CA'' locale, da importare nella sezione "Autorità". Serve per dare "fiducia" al sito web della LAN.
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
# <code>client1.p12</code> - certificato dell'utente finale da importare nel browser.
        Latency: 168, Cache Line Size 20
        Interrupt: pin B routed to IRQ 11
        Region 0: Memory at 50100000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
        Memory window 0: 24000000-25fff000 (prefetchable)
        Memory window 1: 26000000-27fff000
        I/O window 0: 00002400-000024ff
        I/O window 1: 00002800-000028ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
        16-bit legacy interface ports at 0001


02:00.0 Ethernet controller: Marvell Technology Group Ltd. (rev3)
==Revoca di un certificato==
        Subsystem: Unknown device 1faa (rev 03)
Un certificato può essere revocato per vari motivi, tra cui i seguenti:
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
* '''unspecified''' motivazione non specificata.
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
* '''keyCompromise''' la chiave relativa al certificato è stata compromessa (p.e. è giunta nelle mani sbagliate).
        Latency: 64
* '''superseded''' il certificato è stato rimpiazzato.
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 22000000 (32-bit, non-prefetchable) [disabled] [size=64K]
        Region 1: Memory at 22010000 (32-bit, non-prefetchable) [disabled] [size=64K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-


</pre>
Per un elenco esaustivo consultare la pagina del manuale ''openssl CA(1)''.


Salta agli occhi il flag '''disabled'''.
il seguente comando revoca il certificato certs/client1.crt:
Per risolvere � necessario agire sul file ''/etc/pcmcia/config.opts e aggiungere le seguenti righe:
<pre>
<pre>
# vi /etc/pcmcia/config.opts
# openssl ca -config openssl.cnf -revoke certs/client1.crt -crl_reason superseded
.....
Enter pass phrase for private/ca.key:
include port 0x1400-0x14ff
include port 0x1800-0x18ff
include memory 0x20000000-0x21fff000
include memory 0x22000000-0x23fff000
 
include port 0x2800-0x28ff
include port 0x2c00-0x2cff
include memory 0x24000000-0x25fff000
include memory 0x26000000-0x27fff000
....
</pre>
</pre>
Il rudimentale database <code>/etc/ssl/index.txt</code> è aggiornato marcando il certificato come revocato. Risultano revocati tutti quei certificati che in <code>/etc/ssl/index.txt</code> presentano una lettera '''R''' come primo campo.


Un' ultimo passo..
===Creazione e aggiornamento di una CRL===
<pre>
Per conoscere quali certificati sono stati revocati, è necessario generare una ''CRL'' (''Certificate Revocation List''). Una ''CRL'' è una lista che dichiara quali certificati sono stati revocati e la motivazione della revoca.
# vi /etc/init.d/pcmcia
<pre># openssl ca -config openssl.cnf -gencrl -out crl/crl.pem</pre>
..
Il comando precedente crea una ''CRL'' in base alle informazioni contenute in <code>/etc/ssl/index.txt</code> e deve essere impartito ogni volta che uno o più certificati sono revocati.
CORE_OPTS="probe_io=0"
..
</pre>


In questo modo scomprir� il flag '''disabled''' e la scheda wireless verr� abilitata e sar� in grado di farvi navigare sui fili.
Dopo aver aggiornato una ''CRL'', è sempre necessario riavviare ''apache-ssl'' per rendere effettivi i cambiamenti.
Torniamo quindi dove eravamo rimasti nel precedente paragrafo!


== Ringraziamenti ==
Per la configurazione di ''apache-ssl'' relativa all'uso delle ''CRL'' vedere la sezione [[#Configurazione Web Server|Configurazione Web Server]].
Ringrazio [http://guide.debianizzati.org/index.php/Utente:Jango jango] per la semplicit� della sua guida.


----
{{Autori
|Autore = [[Utente:Nicsar|~ Nicsar]] 05:00, 1 Nov 2006 (CST) (Nicola Sarobba)
}}


Autore:  
[[Categoria:Web server]]
: [[Utente:Uomolosco|Uomolosco]] 07:52, 7 Ott 2006 (EDT)
[[Categoria:Crittografia]]

Versione attuale delle 19:50, 12 mag 2015

Guida da adottare! Bannermv.png


Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian

Note sulla compatibilità

La guida è compatibile soltanto con Apache 1, la versione apache 2 non è idonea a questa guida.

Introduzione

L'utilizzo di un'autorità di certificazione locale (self signed CA) trova applicazione in tutti quei casi in cui non sia necessario che una root CA esterna firmi i nostri certificati.

Uno scenario tipico è quello in cui si voglia realizzare un sistema di autenticazione web basato su certificati: per autenticarsi i client devono presentare il certificato richiesto.

Illustrerò come generare una CA locale, come usarla per creare certificati lato server e lato client, infine mostrerò come revocare un certificato.

Installazione e Configurazione di Openssl

Per installare la libreria SSL e gli applicativi necessari alla creazione di chiavi e certificati dare il comando:

# apt-get install openssl

Per minimizzare la quantità di informazioni richieste durante la creazione di chiavi e certificati, può essere utile modificare il file /etc/ssl/openssl.cnf per esempio alla seguente sezione:

[ req_distinguished_name ]

countryName             = Country Name (2 letter code)
countryName_default     = IT
...
stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Italy
...

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Azienda SpA
...

Generazione di una CA locale

Per mezzo di questa autorità di certificazione saranno creati tutti gli altri certificati: quello del server e quelli dei client.

Creazione della chiave (root CA)

Prima del certificato è necessario creare una chiave. Il seguente comando genera nella directory /etc/openssl/private la chiave privata ca.key di 1024 bit criptata con algoritmo triple DES:

# openssl genrsa -des3 -out private/ca.key 1024
Enter pass phrase for private/ca.key:
Verifying - Enter pass phrase for private/ca.key:

La chiave sarà generata dopo aver immesso la pass phrase.

Warning.png ATTENZIONE
vista l'importanza della chiave privata a livello sicurezza, dare gli opportuni permessi alla directory /etc/openssl/private e a ca.key.


Generazione del certificato (root CA)

Prima di procedere assicurarsi che /etc/ssl/index.txt sia vuoto e che /etc/ssl/serial contenga il valore 01.

Utilizziamo la chiave creata nella sezione Creazione della chiave (root CA), per generare un certificato root CA ca.crt con validità di un anno:

# openssl req -config /etc/ssl/openssl.cnf -new -x509 -key private/ca.key -out ca.crt -days 365
Enter pass phrase for private/ca.key:

Il certificato appena creato sarà utilizzato esclusivamente per firmare tutti gli altri certificati generati in seguito.

Affinché i browser possano riconoscere come valida la root CA appena creata, gli utenti finali dovranno installare il certificato ca.crt nei loro browser. Riferirsi alla sezione Certificazione lato client per ottenere maggiori informazioni.

Aggiungendo l'opzione -batch al precedente comando potremmo automatizzare l'operazione utilizzando i valori predefiniti impostati nel file /etc/ssl/openssl.cnf. Utile quando il comando è utilizzato in uno script.

Certificato lato server

Questo è il certificato che il server utilizza per cifrare i dati scambiati con i vari client. Un tipico esempio è un server https.

Creazione della chiave (server)

Il modo in cui creare la chiave e le osservazioni da fare sono le stesse viste nella sezione Creazione della chiave (root CA):

# openssl genrsa -des3 -out private/server.key 1024
Enter pass phrase for private/server.key:
Verifying - Enter pass phrase for private/server.key:

È molto probabile che la chiave generata sia poi utilizzata insieme al relativo certificato nella configurazione di apache; in tal caso apache attenderà ad ogni avvio che venga inserita la pass phrase relativa alla chiave utilizzata. Vista la scomodità di tale soluzione, si può togliere la pass phrase dalla chiave:

# openssl rsa -in private/server.key -out private/server.key.unsecure
Enter pass phrase for private/server.key:
writing RSA key
Warning.png ATTENZIONE
la chiave priva di pass phrase non è protetta, quindi assicurarsi che abbia i permessi opportuni.


Generazione di una Certificate Signing Request (CSR)

Con la chiave creata nella sezione Creazione della chiave (server) generiamo una richiesta di firma per il certificato lato server che stiamo creando:

# openssl req -config /etc/ssl/openssl.cnf -new -key private/server.key -out server.csr
Enter pass phrase for private/server.key:

Impartito il comando, è richiesta in input una serie di informazioni tra cui la più importante è quella relativa all'opzione commonName in cui va specificato l'FQDN del server che utilizzerà il certificato, al fine di evitare problemi di "fiducia" coi client.

Firma della CSR

Quando disponiamo di una CSR è necessario spedirla alla CA scelta affinché la firmi, tuttavia se abbiamo provveduto, come spiegato nella sezione Generazione di una CA locale, alla creazione di una nostra CA , possiamo firmare noi la CSR ottenuta alla sezione Generazione di una Certificate Signing Request:

# openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -keyfile private/ca.key \ 
> -cert ca.crt -in server.csr -out certs/server.crt
Enter pass phrase for private/ca.key:

Il risultato del precedente comando è il file /etc/ssl/certs/server.crt, l'aggiornamento di /etc/ssl/index.txt e di /etc/ssl/serial. A questo punto il file server.csr non è più necessario. Il risultato dell'operazione è il certificato per mezzo del quale il server https cifrerà i dati scambiati con i client.

Configurazione Web Server

Prendo in considerazione solo la configurazione relativa ad apache , in particolare ad apache-ssl. Utilizzando apache con mod-ssl si dovrebbero ottenere risultati analoghi.

Direttive apache-ssl

Importanti sono le seguenti direttive:

SSLCACertificatePath
indica la directory dove sono contenuti certificati e CRL (Certificate Revocation List)

Esempio: SSLCACertificatePath /etc/ssl

SSLCertificateFile
indica il certificato lato server per mezzo del quale i dati vengono cifrati. Secondo quanto riportato in questa guida esso corrisponde al file /etc/ssl/certs/server.crt.

Esempio: SSLCertificateFile server.crt

SSLCertificateKeyFile
indica la chiave privata del certificato lato server. Secondo quanto qui riportato essa corrisponde al file /etc/ssl/private/server.key. Per maggiori informazioni vedere l'osservazione sulle chiavi private fatta nella sezione Certificato lato server.

Esempio: SSLCertificateKeyFile server.key

SSLVerifyClient
definisce la certificazione di cui i client necessitano per autenticarsi.

Esempio: SSLVerifyClient 2 #The client must present a valid certificate.

SSLVerifyDepth
nel nostro caso va impostata a 1 in quanto ci fidiamo solo di certificati firmati dalla nostra CA locale.

Esempio: SSLVerifyDepth 1

SSLUseCRL
i certificati client sono controllati basandosi sull'appropriata CRL. La CRL deve essere in formato PEM. è necessario un link simbolico alla CRL posto all'interno del percorso indicato dalla direttiva SSLCACerificatePath. Non prende argomenti. Il percorso della CRL è specificato da SSLCACertificatePath. I link simbolici alle CRL hanno la forma <hash>.r<number>, dove <hash> è l'hash del file contenente la CRL. La sezione Apache e CRL spiega come creare link simbolici di tale tipo.

Esempio: SSLUseCRL

SSLOnRevocationSetEnv
se il client presenta un certificato revocato, la sessione SSL è stabilita e la variabile indicata è impostata. L'idea è di gestire con uno script questo tipo d'errore. Per la descrizione delle altre direttive del tipo SSLOn*SetEnv riferirsi alla documentazione di apache.

Esempio: SSLOnRevocationSetEnv SSL_REVOKED

Apache e CRL

Questa sezione tratta della configurazione di apache-ssl per l'uso di CRL. Riferirsi a Revoca di un certificato e in particolare a Creazione e aggiornamento di una CRL.

Affinché apache-ssl sia informato sulla validità dei certificati, è necessario l'utilizzo delle direttive SSLCACertificatePath e SSLUseCRL. La prima indica il percorso in cui cercare la CRL, la seconda istruisce il demone a fare uso della CRL.

La CRL deve essere puntata da un link simbolico della forma <hash>.r<number> presente all'interno del percorso indicato dalla direttiva SSLCACertificatePath (p.e. /etc/ssl):

# cd /etc/ssl
# hash=`openssl crl -hash -in crl/crl.pem -noout`
# ln -sf crl/crl.pem $hash.r0
# ls -l $hash.r0

lrwxr-xr-x   1  root   root   11 2004-09-24 10:41 bb6e3a6b.r0 -> crl/crl.pem

CA, certificati e CRL per virtual host

Tutte le direttive elencate nella sezione Direttive apache-ssl possono essere utilizzate nei contesti server config e virtual host.

La prima conseguenza è che si possono specificare CA, CRL e certificati distinti per ogni singolo host virtuale. La seconda conseguenza è che si può creare confusione tra le direttive nei contesti server config e virtual host. Si consideri una configurazione del tipo seguente:

[...]
SSLOnRevocationSetEnv SSL_REVOKED
[...]
<VirtualHost x.y.z.w:443>
SSLCACertificateFile /etc/ssl/virtual1/ca.crt
SSLCertificateFile /etc/ssl/virtual1/certs/server.crt
SSLCertificateKeyFile /etc/ssl/virtual1/private/server.key
SSLCACertificatePath /etc/ssl/virtual1
SSLUseCRL
[...]
</VirtualHost>

Quando è revocato un certificato client relativo al virtual host x.y.z.w, il risultato potrebbe non corrispondere a quanto voluto. Se si visitasse l'URL https://x.y.z.w con il browser in cui è installato il certificato revocato, si noterebbe che l'accesso non verrebbe impedito. Questo accade perché SSLOnRevocationSetEnv SSL_REVOKED non nega l'accesso ai certificati revocati, ma imposta la variabile SSL_REVOKED a "YES" e la direttiva posta nel contesto server config ha valore anche per gli host virtuali. La soluzione è quella di commentare la direttiva nel contesto server config e attivarla, se serve, per ogni singolo host virtuale.

Certificato lato client

I passi da seguire per la creazione dei certificati lato client sono essenzialmente analoghi a quelli illustrati nella sezione Certificato lato server.

Creazione chiave (client)

Prima di tutto generiamo la chiave. La pass phrase utilizzata servirà all'utente finale per autenticarsi nelle zone protette del server web.

# openssl genrsa -des3 -out private/client1.key 1024
Enter pass phrase for private/client1.key:

Generazione di una CSR per il client

# openssl req -config /etc/ssl/openssl.cnf -new -key private/client1.key -out client1.csr
Enter pass phrase for private/client1.key:

Firma della CSR per il client

La CSR va firmata dalla nostra CA locale:

# openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -keyfile private/ca.key \
> -cert ca.crt -in client1.csr -out certs/client1.crt
Enter pass phrase for private/ca.key:

a questo punto il file client1.csr non è più necessario. Infine client1.crt e client1.key vanno messi in un unico file:

# cat private/client1.key > private/client1.pem
# cat certs/client1.crt >> private/client1.pem

quindi generare il file PKCS da importare nel browser dell'utente finale:

# openssl pkcs12 -export -in private/client1.pem -out pkcs/client1.p12 -name "Certificato Client 1"
Enter pass phrase for private/client1.pem:
Enter Export Password:
Verifying - Enter Export Password:

Ovviamente la pass phrase per /etc/ssl/private/client1.pem è la stessa di /etc/ssl/private/client1.key. La Export Password viene richiesta al momento dell'importazione del file PKCS nel client browser.

Importazione dei certificati

I certificati da importare nel browser secondo quanto fin qui descritto sono:

  1. ca.crt - certificato della CA locale, da importare nella sezione "Autorità". Serve per dare "fiducia" al sito web della LAN.
  2. client1.p12 - certificato dell'utente finale da importare nel browser.

Revoca di un certificato

Un certificato può essere revocato per vari motivi, tra cui i seguenti:

  • unspecified motivazione non specificata.
  • keyCompromise la chiave relativa al certificato è stata compromessa (p.e. è giunta nelle mani sbagliate).
  • superseded il certificato è stato rimpiazzato.

Per un elenco esaustivo consultare la pagina del manuale openssl CA(1).

il seguente comando revoca il certificato certs/client1.crt:

# openssl ca -config openssl.cnf -revoke certs/client1.crt -crl_reason superseded
Enter pass phrase for private/ca.key:

Il rudimentale database /etc/ssl/index.txt è aggiornato marcando il certificato come revocato. Risultano revocati tutti quei certificati che in /etc/ssl/index.txt presentano una lettera R come primo campo.

Creazione e aggiornamento di una CRL

Per conoscere quali certificati sono stati revocati, è necessario generare una CRL (Certificate Revocation List). Una CRL è una lista che dichiara quali certificati sono stati revocati e la motivazione della revoca.

# openssl ca -config openssl.cnf -gencrl -out crl/crl.pem

Il comando precedente crea una CRL in base alle informazioni contenute in /etc/ssl/index.txt e deve essere impartito ogni volta che uno o più certificati sono revocati.

Dopo aver aggiornato una CRL, è sempre necessario riavviare apache-ssl per rendere effettivi i cambiamenti.

Per la configurazione di apache-ssl relativa all'uso delle CRL vedere la sezione Configurazione Web Server.




Guida scritta da: ~ Nicsar 05:00, 1 Nov 2006 (CST) (Nicola Sarobba) Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized