Autorità di certificazione locale: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(Prima Stesura)
Riga 1: Riga 1:
==Caratteristiche==
{{stub}}
==Introduzione==
L'utilizzazione di una 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.


* Intel Pentium M 1.6 GHz
Uno scenario tipico è quello di una LAN con server https: l'utilizzo di una CA locale evita tutti quei noiosi avvisi da parte dei client che lamentano l'incertezza dell'origine del certificato del server https.
* 2x256 MB DDR-SDRAM
Un altro scenario è quello in cui sia necessario un sistema di autenticazione web basato su certificati: affinché ogni client possa autenticarsi è necessario che esso presenti il certificato richiesto.
* 40 GB Matshita hd
* ATI Mobility Radeon 9600 M10 (RV350)
* Audio Intel AC'97
* Matshita DVD-RAM UJ-820s
* Realtek Ethernet Controller
* LCD 15.4"
* ENE PCMCIA Controller
* Intel Pro/Wireless 2200BG
* Alps Touchpad


<pre># lspci
==Installazione e Configurazione di Openssl==
0000:00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
Per installare la libreria SSL e gli applicativi necessari alla creazione di chiavi e certificati dare il comando:
0000:00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
<pre>apt-get install openssl</pre>
0000:00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
0000:00:01.0 PCI bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to AGP Controller (rev 02)
0000:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
0000:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
0000:00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03)
0000:00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03)
0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
0000:00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03)
0000:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
0000:00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03)
0000:00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
0000:00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
0000:02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
0000:02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
0000:02:04.0 CardBus bridge: ENE Technology Inc CB-710/2/4 Cardbus Controller
0000:02:04.1 FLASH memory: ENE Technology Inc ENE PCI Memory Stick Card Reader Controller
0000:02:04.2 0805: ENE Technology Inc ENE PCI Secure Digital Card Reader Controller
0000:02:04.3 FLASH memory: ENE Technology Inc: Unknown device 0520</pre>


==La mia installazione di Debian Sarge (3.1r0a)==
Per minimizzare la quantità di informazioni richieste durante la creazione di chiavi e certificati, pu&ograve;
 
essere utile modificare il file '''/etc/sslopenssl.cnf''' per esempio alla seguente sezione:
===Backup e partizionamento===
<pre>
 
[ req_distinguished_name ]
Ho fatto un backup di tutti i documenti, file, musica, video, etc...
 
Poi una deframmentazione, meglio se da DOS, in modo da avere il sistema operativo su una parte precisa del disco (all'inizio).
 
Io ho voluto mantenere il sistema op. della microsoft, quindi ho creato le partizioni (almeno 2) da Windows. Si possono creare, credo, anche con l'installer di Debian, ma � un po' complicato. Non fate come il sottoscritto, procuratevi un programma open source per partizionare. : )
 
Io ne ho create 2:
 
*Primaria da 14 GB per / [destinazione dell'intero sistema operativo]
*Logica da 1 GB per lo swap ["memoria virtuale"]
La partizione di swap non � obbligatoria, ma consigliata.


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


Facendo partire l'installazione della Sarge su questo modello Toshiba si ha un blocco sul rilevamento dei controller PCMCIA, in particolare su:
0.organizationName              = Organization Name (eg, company)
<pre>Rilevamento dell'hardware in corso alla ricerca di lettori CD-ROM --> Avvio dei servizi "PC-CARD" in corso</pre>
0.organizationName_default      = Azienda SpA
Ma non ho disperato, al boot mi � bastato scrivere, per far partire l'installer correttamente:
...
<pre>hw-detect/start_pcmcia=false</pre>
Siccome, io credo, non viene riconosciuto correttamente nemmeno l'adattatore grafico, ho dovuto aggiungere:
<pre>vga=771</pre>
se no mi sarei trovato davanti ad una schermata nera. Il comando completo diventa quindi:
<pre>linux26 acpi=yes vga=771 hw-detect/start_pcmcia=false</pre>
Prima del processo di partizionamento dell'installer, viene chiesto di formattare tutto l'hd o di modificare la tabella delle partizioni manualmente: io, per tenermi Windows, ho scelto la seconda opzione.
Quindi appare il men� di partizionamento con visualizzate le tre partizioni:
<pre>- (numero partizione) (tipo) (dimensione) (file system) (uso)
-
-
</pre>
Quella dell'altro SO non va toccata, deve essere impostata su "non usare la partizione".
Quella principale (per /) va configurata cos�:
<pre>usato come (cio� il file system): reiserFS
mount point: /
opzioni: default
etichetta: /
flag "avviabile": attivato
</pre>
</pre>
Quella di swap cos�:
==Generazione di una CA locale==
<pre>usato come: area di swap</pre>
Per mezzo di questa autorit&agrave; di certificazione saranno creati tutti gli altri certificati: quello del server e quelli dei client.
Ho proseguito con il partizionamento guidato e il resto dell'installazione.
 
PRIMA di confermare il partizionamento, ho VERIFICATO nel riepilogo che le partizioni di altri OS non vengano modificate.
Ho scelto di installare il boot loader GRUB nel master boot record.
 
===Installazione (seconda parte)===


Finita la prima parte dell'installazione, il sistema si � riavviato, cos� che mi sono trovato davanti al men� di GRUB (scelta del sistema operativo). Ho selezionato, con la tastiera:
===Creazione della chiave (root CA)===
<pre>Debian GNU/LINUX, kernel 2.6.8-2-686    (o simile)</pre>
Prima del certificato &egrave; 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'':
e ho premuto "e" per editarlo, quindi ho selezionato:
<pre># openssl genrsa -des3 -out private/ca.key 1024
<pre>kernel /boot/vwlinuz-2.6.8-2-686 root=/dev/hda2 ro acpi=yes vga=771    (o simile)</pre>
Enter pass phrase for private/ca.key:
e premuto di nuovo "e" , ho aggiunto in fondo alla riga, senza virgolette: "1" (credo si possa aggiungere anche "single"), poi INVIO e poi "b". Il sistema comincia la seconda parte di installazione; ad un certo punto ci si trova al prompt di manutenzione, digitate (senza #):
Verifying - Enter pass phrase for private/ca.key:
<pre>
# cd /etc/rc2.d/
# rm *pcmcia*
# init2
</pre>
Ho cos� rimosso i riferimenti ai controller PCMCIA. L'installazione parte come previsto. Se non avessi eseguito quest'ultima operazione, si sarebbe verficato un blocco del sistema a:
<pre>
Starting PCMCIA services: cardmgr[2808]: watching 1 socket
cs: IO port probe 0x0100-0x04ff: clean
cs: IO port probe 0x0800-0x08ff: _ |
</pre>
</pre>


===Configurazione desktop===
La chiave sar&agrave; generata dopo aver immesso la ''pass phrase''.


Io ho scelto "ambiente desktop".
{{ warningbox | vista l'importanza della chiave privata a livello sicurezza, dare gli opportuni permessi alla directory '''/etc/openssl/private''' e a '''ca.key'''. }}
Verr� in seguito chiesto di scegliere i driver per la scheda video, cio� "ati".


Se � andato tutto bene, si deve, con i diritti di amministratore, modificare il file:
===Generazione del certificato (root CA)===
<tt>/etc/X11/XF86Config-4</tt><br/>
Prima di procedere assicurarsi che '''/etc/ssl/index.txt''' sia vuoto e che '''/etc/ssl/serial''' contenga il valore 01.
oppure: <tt>/etc/X11/xorg.conf</tt>    oppure    <tt>/etc/X11/Xfree86.conf</tt>


la sezione "Screen" va modificata cos�, se non lo � gi�:
Utilizziamo la chiave creata nella sezione [[#Creazione della chiave (root CA)|Creazione della chiave]], per generare un certificato root CA '''ca.crt''' con validit&agrave; 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>


<pre>
Il certificato appena creato sar&agrave; utilizzato esclusivamente per firmare tutti gli altri certificati generati in seguito.
Subsection "Display"
    Deph          24
    Modes        "1280x800" "1024x768" "800x600" "640x480"
</pre>
Se si mette "1152x768" al posto di "1280x800" si avr� un effetto tipo antialias veramente fastidioso, soprattutto per i carratteri piccoli; infatti questa risoluzione non � specifica a questo video.


Nota: Nel Toshiba M30X-159, per vedere bene le risoluzioni da 1024x768 in su.. ho dovuto modificare nella sezione "Monitor" la sincronizzazione orizzontale e verticale nel seguente modo :
Affinch&eacute; 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 XXX per maggiorni informazioni.
<pre>
Section "Monitor"
Identifier "LPL:0000"
HorizSync 30-61
VertRefresh 56-75
Option "DPMS"
EndSection
</pre>
Se come driver non avete scelto ati, dovete cambiarlo nello stesso file, scrivendo "ati" al posto di quello che ci trovate, nella riga "Driver" nella sezione "Device".
'''Riavviate.'''


===LAN===
Aggiungendo l'opzione '''-batch''' al precedente comando potremmo automatizzare l'operazione utilizzando i valori predefiniti impostati nel file '''/etc/ssl/openssl.cnf'''. Utile quando utilizzata da script.


Sono riuscito a configurare anche la connessione a internet tramite router.
==Certificato lato server==
Questo &egrave; il certificato che il server utilizza per cifrare i dati scambiati con i vari client. Un tipico esempio è un server ''https''.


La procedura � ben descritta in [[Condividere la connessione a internet]].
====Creazione della chiave (server)====
Il modo in cui creare la chiave e le osservazioni sono le stesse viste nella sezione [[#Creazione della chiave (root CA)|Creazione della chiave (root CA)]]:
<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>


===WIRELESS===
&Egrave; probabile che la chiave generata sia poi utilizzata insieme al relativo certificato nella configurazione di ''apache''; in tal caso ''apache'' attender&agrave; ad ogni avvio che venga inserita la ''pass phrase'' relativa alla chiave utilizzata. Vista la scomodit&agrave; di tale soluzione, si pu&ograve; 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>


====Debian Way====
{{ Warningbox | la chiave priva di ''pass phrase'' non &egrave; protetta, quindi assicurarsi che abbia i permessi opportuni.}}


[[Intel PRO/Wireless 2200BG]]
===Generazione di una Certificate Signing Request (CSR)===
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>litio:# openssl req -config /etc/ssl/openssl.cnf -new -key private/server.key -out server.csr
Enter pass phrase for private/server.key:</pre>


''(by ckale)''
Impartito il comando, &egrave; richiesta in input una serie di informazioni tra cui la pi&ugrave; importante &egrave; quella relativa all'opzione ''commonName'' in cui va specificato l'''FQDN'' del server che utilizzer&agrave; il certificato, al fine di evitare problemi di "fiducia" coi client.


Per evitare, in parte, di fare il passaggio 1 e 2  (vedi sotto), installate attraverso apt-get il "[[Pagina di manuale di module-assistant|module-assistant]]". Questo vi consentir� di recuperare, pachettizzare ed installare il modulo per il ipw2200. Una volta installato, con <tt>apt-get install module-assistant</tt> modifichiamo anche il source.list di apt che si trova <tt>/etc/apt/source.list</tt> aggiungendo "non-free" e "contrib" sia per il repo "deb" che deb-src come in esempio :
===Firma della CSR===
Quando disponiamo di una ''CSR'' &egrave; necessario spedirla alla ''CA'' scelta affinch&ecaute; 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>
# 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:</pre>


deb http://debian.fastweb.it/debian/ stable main non-free contrib
Il risultato del precedente comando &egrave; 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 &egrave; pi&ugrave; necessario.
deb-src http://debian.fastweb.it/debian/ stable main non-free contrib
Il risultato dell'operazione &egrave; il certificato per mezzo del quale il server https cifrer&agrave; i dati scambiati con i client.


Un volta fatto ci� aggiorniamo apt-get update e lanciamo module-assistant.
==Configurazione Web Server==
Ricordiamoci pero' di copiare i file firmware nella cartella <tt>/usr/lib/hotplug/firmware/</tt> (con il [[Udev e Debian|nuovo udev]] il percorso � <tt>/lib/firmware</tt>).
Prendo in considerazione solo la configurazione relativa ad ''apache'' , in particolare ad ''apache-ssl''. Utilizzando ''apache'' con ''mod-ssl'' si dovrebbero ottenere risultati analoghi.


A questo punto proviamo a caricare il modulo con modprobe ipw2200
===Direttive apache-ssl===
Importanti sono le seguenti direttive:
; SSLCACertificatePath: indica la directory dove sono contenuti certificati e CRL.
Esempio: <tt>SSLCACertificatePath /etc/ssl</tt>
; 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: <tt>SSLCertificateFile server.crt</tt>
; 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|Certificato lato server]].
Esempio: <tt>SSLCertificateKeyFile server.key</tt>
; SSLVerifyClient: definisce la certificazione di cui i client necessitano per autenticarsi.
Esempio: <tt>SSLVerifyClient 2  #The client must present a valid certificate.</tt>
; SSLVerifyDepth: nel nostro caso va impostata a 1 in quanto ci fidiamo solo di certificati firmati dalla nostra CA locale.
Esempio: <tt>SSLVerifyDepth 1</tt>
;SSLUseCRL: i certificati client sono controllati basandosi sull'appropriata ''CRL''. La ''CRL'' deve essere in formato ''PEM''. &Egrave; necessario un link simbolico alla ''CRL'' posto all'interno del percorso indicato dalla direttiva '''SSLCACerificatePath'''. Non prende argomenti. Il percorso della ''CRL'' e' 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 XXX spiega come creare link simbolici di tale tipo.
Esempio: <tt>SSLUseCRL</tt>
; SSLOnRevocationSetEnv: se il client presenta un certificato revocato, la sessione SSL &egrave; stabilita e la variabile indicata &egrave; impostata. L'idea &egrave; di gestire con uno script questo tipo d'errore. Per la descrizione delle altre direttive del tipo ''SSLOn*SetEnv'' riferisi alla documentazione di ''apache''.
Esempio: <tt>SSLOnRevocationSetEnv SSL_REVOKED</tt>


Una volta caricato il modulo procediamo con l'installazione delle utility wireless, apt-get install wireless-utility. Con il comando iwconfig possiamo vedere le interfacce di rete wifi.  
===Apache e CRL===
Questa sezione tratta della configurazione di ''apache-ssl'' per l'uso di ''CRL''. Riferirsi a [sec:Revoca-di-un] e in particolare a [sec:Creazione-e-aggiornamento di una CRL].


{{Warningbox|Se non funziona controllate il log del modprobe e verificate che il modulo cerchi il driver corretto, mi � capitato che lui cercasse un file con un nome diverso, naturalmente mi � bastato rinominare i firmware ;)}}
Affinch&eacute; ''apache-ssl'' sia informato sulla validit&agrave; dei certificati, &egrave; 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''.


====Old Style====
La ''CRL'' deve essere puntata da un link simbolico della forma <tt><hash>.r<number></tt> presente all'interno del percorso indicato dalla direttiva '''SSLCACertificatePath''' (p.e. '''/etc/ssl'''):
''(by jockerfox)''
<pre>
# cd /etc/ssl
# hash=`openssl crl -hash -in crl/crl.pem -noout`
# ln -sf crl/crl.pem $hash.r0
# ls -l $hash.r0


1) Dal sito Sourceforge.net
lrwxr-xr-x  1 root  root  11 2004-09-24 10:41 bb6e3a6b.r0 -> crl/crl.pem
scaricate i seguenti pacchetti :
</pre>


http://ipw2200.sourceforge.net/#downloads il driver "ipw2200-1.0.4.tgz"
===CA, certificati e CRL per virtual host===
http://ipw2200.sourceforge.net/firmware.php il firmware "v1.0.4-current firmware"
Tutte le direttive elencate nella sezione [[#Direttive apache-ssl|Direttive apache-ssl]] possono essere utilizzate nei contesti ''server config'' e ''virtual host''.


Con Synaptic scaricare i seguenti pacchetti:
La prima conseguenza &egrave; che si possono specificare ''CA'', ''CRL'' e certificati distinti per ogni singolo host virtuale.
:1: kernel-headers-2.6.8-2-686 (in automatico scaricher� anche kernel-headers-2.6.8-2 e kernel-kbuild-2.6-3)
La seconda conseguenza &egrave; che si pu&ograve; creare confusione tra le direttive nei contesti ''server config'' e ''virtual host''. Si consideri una configurazione del tipo seguente:
:2: net-tools
<pre>
[...]
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>
</pre>
Quando è revocato un certificato client relativo al virtual host <tt>x.y.z.w</tt>, il risultato potrebbe non corrispondere a quanto voluto. Se si visitasse l'URL <tt>https://x.y.z.w</tt> con il browser in cui è installato il certificato revocato , si noterebbe che l'accesso non verrebbe impedito. Questo accade perch&eacute; '''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.


2) Fatto cio':
==Configurazione Client Browser==
:* scompattare "ipw2200-1.0.4.tgz" in una directory qualsiasi e da SU (#) fate un "make", poi "make install"
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]].
:* scompattare in una diversa directory "v1.0.4-current firmware" e copiare tutto in /usr/lib/hotplug/firmware/


'''P.S.''': non occorre copiare i file tipo "LICENZE" e varie... che non servono a nulla.
===Creazione chiave (client)===
Prima di tutto generiamo la chiave. La ''pass phrase'' utilizzata servir&agrave; all'utente finale per autenticarsi nelle zone protette del server web.
<pre>
# openssl genrsa -des3 -out private/client1.key 1024
Enter pass phrase for private/client1.key:
</pre>


3) aprite una Konsole e da SU scrivete "nano /etc/network/interfaces" e aggiungete prima di eth0:
===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>
auto eth1
# openssl ca -config /etc/ssl/openssl.cnf -policy policy_anything -keyfile private/ca.key \
iface eth1 inet dhcp
> -cert ca.crt -in client1.csr -out certs/client1.crt
Enter pass phrase for private/ca.key:
</pre>
</pre>


4) reboot ... e funziona !!
a questo punto il file '''client1.csr''' non e' più necessario. Infine '''client1.crt''' e '''client1.key''' vanno messi in un unico file:
<pre>
# cat private/client1.key > private/client1.pem
# cat certs/client1.crt >> private/client1.pem
</pre>


{{Warningbox|Ricordate di mettere il router senza chiave WEP (o varie cifrature) per essere sicuru che tutto funzioni come da dovere... dopo di che' abilitate allora la Key WEP nel router (vedi sotto per Debian)}}
quindi generare il file ''PKCS'' da importare nel browser dell'utente finale:
<pre>
# 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:
</pre>


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


No problem !
===Importazione dei certificati===
I certificati da importare nel browser secondo quanto fin qui descritto sono:
# '''ca.crt''' - certificato della ''CA'' locale, da importare nella sezione "Autorit&agrave;". Serve per dare "fiducia" al sito web della LAN.
# '''client1.p12''' - certificato dell'utente finale da importare nel browser.


A.S.: Il KWiFIManager e' utile, ma non per configurare la chiave WEP!!!
==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.


;Importante: In primis, abilitate la chiave WEP nel router (esempio io la ho abilitata in 128 bit)
Per un elenco esaustivo consultare la pagina del manuale ''openssl CA(1)''.
e '''scrivetevi il codice esadecimale''' in un foglio senza sbagliare !!
# Da Konsole digitate : network-admin (lo trovate anche nel menu' K) e vi chiedera' la password di amministratore.. inseritela !
# Una volta "entrati dentro", cliccate sull'icona del Wireless, e poi cliccate sull'icona "modifica" (e' un'icona con una chiave inglese) e inserite la chiave WEP in esadecimale (ex:ABF0D3...); non occorre aggiungere "0x" avanti alla chiave, (0xABFoD3...NO!!) digitatela direttamente in esadecimale (ABF0D3...SI!)
# selezionate la casellina "questo dispositivo e' configurato"
# le altre opzioni se volete... tipo ESSID Dopo premete OK (due volte) e reboot !!!


Sperando di non essermi dimenticato qualcosa... ciao!
il seguente comando revoca il certificato certs/client1.crt:
 
<pre>
Fine .
# openssl ca -config openssl.cnf -revoke certs/client1.crt -crl_reason superseded
(by jockerfox)
Enter pass phrase for private/ca.key:
 
===VIDEO===
 
====Utilizzare i driver Ati di default====
 
I driver Ati di default sono parzialmente accelerati. Dalla mia esperienza � possibile usarli tranquillamente (io ci modellavo con Blender con qualche problema, ad esempio durante le selezioni dei poligoni o vertici nella vista 3D). E' sufficiente avere le librerie mesa (<tt>libglu1-mesa libgl1-mesa-glx libgl1-mesa-dri</tt>) e modificare il file <tt>/etc/X11/xorg.conf</tt> o <tt>/etc/X11/XF86config-4</tt>. Riporto solo le sezioni da aggiungere o modificare:
<pre>Section "Module"
        Load    "dri"
        Load    "extmod"
        SubSection  "extmod"
          Option  "omit xfree86-dga"
        EndSubSection
        Load    "glx"
        Load    "GLcore"
EndSection
 
Section "Device"
        Identifier      "ATI Technologies, Inc. RV350 [Mobility Radeon 9600 M10]"
        Driver          "ati"
        BusID          "PCI:1:0:0"
EndSection
 
Section "DRI"
        Mode    0666
EndSection</pre>
'''Ma se si vuole sfruttare al pieno il processore grafico...'''<br/>
La guida � qui: [[Installazione driver proprietari Ati]].
Comunque per abilitare l'accelerazione hardware 3D, bisogna:
*installare i sorgenti del kernel (sono sufficienti anche solo gli header del kernel);
*scaricare gli ultimi driver proprietari della ATI (al 20/09/2006 gli 8.28.8 , circa 50 MB) dal sito della Ati.
<u>Prima di far partire l'installer salvate una copia di <tt>/etc/X11/xorg.conf</tt> , che in caso di problemi andra' sostituita a quella nuova (creata dal configurer).</u>
 
{{ Warningbox | Prima di far partire l'installazione di nuovi driver, assicuratevi che non siano presenti vecchie versioni di driver:
 
* Verificate che non sia presente la cartella <tt>/usr/share/fglrx/</tt>. Se � presente, significa che sono installati dei vecchi driver fglrx. Per rimuoverli:
<pre># cd /usr/share/fglrx/
# sh ./fglrx-uninstall.sh</pre>
e seguite le istruzioni.
* Fate un '''<tt>aptitude purge</tt>''' di vecchi pacchetti di vecchi driver, se sono installati. }}
 
Per quanto riguarda l'intallazione di quelli nuovi, esistono essenzialmente 2 metodi alternativi:
# usare l'eseguibile Ati
# creare i pacchetti .deb partenddo dal eseguibile Ati
# (''Installare i driver dai repository. Valido solo per Etch e Sid, vedi in fondo'').
 
 
Come � noto i driver ATI soffrono di una difficile installazione e configurazione. Sfortunatamente (o forse no) esistono molteplici configurazioni hardware che ostacolano l'installazione dei driver. Spesso, anche seguendo un guida perfetta, (non questa, occhio!) non si riesce ad attivare l'accelerazione 3D al primo colpo (molto raramente si hanno anche problemi di visualizzazione nel desktop). Solamente con i successivi tentativi (variando anche il metodo, o la guida) solitamente si raggiunge lo scopo prefisso. Il mio modesto consiglio � di non disperarsi, magari tirare cazzotti pesanti al case, ma provare finch� non si riesce.
 
====Installare i driver usando l'eseguibile Ati====
 
Da un terminale spostatevi nella cartella dove avete scaricato il file e date i permessi di esecuzione:
<pre>$ chmod +x ati-driver-installer-8.26.18-x86.run</pre> quindi, da root:
<pre># sh ./ati-driver-installer-8.26.18.x86.run</pre>
e seguite le istruzioni.
Poi, sempre con i permessi di root, aggiornate il file di configurazione <tt>xorg.conf</tt>:
<pre># cd /etc/X11/
# aticonfig --initial
# aticonfig --overlay-type=Xv</pre>
e se volete settare meglio la configurazione:
<pre># aticonfig</pre>
il quale ci dar� un lungo output con la descrizione di tutte le opzioni che possiamo usare con <tt>aticonfig</tt>.
 
Per fare qualcosa (ad esempio impostare i monitor) anche in modalit� grafica, usando il limitatissimo e stupido pannello di controllo Ati, dobbiamo fare qualche capriola.
Creiamo un collegamento simbolco della libreria <tt>libfglrx_pp.so.1.0</tt> in <tt>/usr/lib/</tt>.
Da root:
<pre># ln -s /usr/lib/fglrx/libfglrx_pp.so.1.0 /usr/lib/</pre>
Dobbiamo avere i permessi di root per lavorare su <tt>/etc/X11/xorg.conf</tt> ma il Pannello di Controllo Ati non parte se abbiamo i privilegi. Quindi creiamo un copia del file, ad esempio, in <tt>/home/utente/cartella_temp/</tt>.
Quindi, senza i privilegi di root:
<pre>$ cp /etc/X11/xorg.conf /home/utente/cartella_temp/
$ cd /home/utente/cartella_temp/
$ fireglcontrolpanel</pre>
Settiamo le magre opzioni riguardo ai monitor, applichiamo e diamo Ok. Copiamo il file al suo posto, da root:
<pre># cp /home/utente/cartella_temp/xorg.conf /etc/X11/</pre>
'''Riavviamo X.'''
Tutto dovrebbe essere a posto. Fihiuu...
 
====Installare i driver usando i pacchetti .deb creati con l'eseguibile Ati====
 
Con i privilegi di root, rimuoviamo i vecchi sorgenti del modulo fglrx, se presenti:
<pre># rm /usr/src/fglrx-kernel*.deb</pre>
E' necessario installare i seguenti pacchetti:
<pre># apt-get install module-assistant build-essential fakeroot dh-make debconf libstdc++5 gcc-3.4-base</pre>
Spostiamoci nella cartella dove abbiamo scaricato l'eseguibile Ati e diamogli i permessi di esecuzione:
<pre>$ chmod +x ati-driver-installer-8.26.18-x86.run</pre>
Poi, per creare i 5 pacchetti .deb:
<pre>$ sh ./ati-driver-installer-8.26.18-x86.run --buildpkg Debian/[release]</pre>
Ad esempio:
<pre>$ sh ./ati-driver-installer-8.26.18-x86.run --buildpkg Debian/testing</pre>
Per installarli (installiamo solo quelli fondamentali):
<pre>$ su
Password:
# dpkg -i fglrx-driver_8.26.18-1_i386.deb
# dpkg -i fglrx-kernel-src_8.26.18-1_i386.deb
# dpkg -i fglrx-control_8.26.18-1_i386.deb</pre>
 
=====Il modulo fglrx=====
 
Adesso va compilato il modulo <tt>fglrx</tt>, con <tt>module-assistant</tt> (m-a):
<pre># m-a prepare
# m-a update
# m-a build fglrx
# m-a install fglrx
# depmod -a</pre>
Quindi muoviamoci in <tt>/etc/X11/</tt>:
<pre># cd /etc/X11/</pre>
e aggiorniamo il file di configurazione di X:
<pre># aticonfig --initial
# aticonfig --overlay-type=Xv</pre>
Naturalmemte � possibile modificare <tt>etc/X11/xorg.conf</tt> anche a manina (per fare questo consultate...uhm, forse c'� qualche cosa in <tt>man xorg.conf</tt>) oppure consultando e usando <tt>aticonfig</tt>.
 
'''Riavviamo X'''.
 
{{ Warningbox | Ad ogni aggiornamento del kernel bisogna ricompilare il modulo <tt>fglrx</tt>. }}
 
====Accelerazione e logs====
 
Per verificare se abbiamo installato tutto correttamente:
<pre>$ fglrxinfo</pre>
dovrebbe dare un output simile a questo:
<pre>display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: MOBILITY RADEON 9700 Generic
OpenGL version string: 2.0.5879 (8.26.18)</pre>
Se al posto di ATI compare Mesa, c'� qualcosa che non va. L'installazione non � andata a buon fine.
 
Per testare l'accelerazione:
<pre>$ fgl_glxgears</pre>
Dovrebbe comparire un cubo rotante con sulle sei faccie degli ingranaggi rotanti e, sul terminale la conta dei frame:
<pre>Using GLX_SGIX_pbuffer
1610 frames in 5.0 seconds = 322.000 FPS
1640 frames in 5.0 seconds = 328.000 FPS
2093 frames in 5.0 seconds = 418.600 FPS</pre>
Se invece compaiono 4-5 righe di errori, c'� qualcosa che non va. L'installazione non � andata a buon fine. Ritenta, forse sarai pi� fortunat*.
 
Per testare l'accelerazione � possibile utilizzare anche i tools di Mesa:
<pre># apt-get install mesa-utils
$ glxgears -printfps</pre>
Appaiono tre ingranaggi rotanti e la conta dei fotogrammi:
<pre>14045 frames in 5.0 seconds = 2808.862 FPS
14115 frames in 5.0 seconds = 2822.858 FPS
14196 frames in 5.0 seconds = 2839.177 FPS</pre>
 
Il file di log principale � '''<tt>/var/log/Xorg.0.log</tt>''' e seguenti. Da spulciare, analizare, bruciare, supplicare. Insomma qui c'� di tutto di pi�. Ma a volte si pu� anche non trovare nulla di anomalo e magari <tt>fgl_glxgears</tt> non funziona lo stesso. 8�(
 
Se abbiamo installato i driver con l'installer Ati, esiste anche questo piccolo log:  <tt>/usr/share/fglrx/fglrx-install.log</tt>
 
====xorg.conf (XF86Config-4)====
 
Questo e' il mio xorg.conf:
<pre># /etc/X11/xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the /etc/X11/xorg.conf manual page.
# (Type "man /etc/X11/xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
#  sudo dpkg-reconfigure -phigh xserver-xorg
 
Section "ServerLayout"
Identifier    "Default Layout"
Screen      0  "aticonfig-Screen[0]" 0 0
InputDevice    "Keyboard"
InputDevice    "Mouse"
InputDevice    "Touchpad"
EndSection
 
Section "Files"
# path to defoma fonts
FontPath    "/usr/share/fonts/X11/misc"
FontPath    "/usr/share/fonts/X11/100dpi/:unscaled"
FontPath    "/usr/share/fonts/X11/75dpi/:unscaled"
FontPath    "/usr/share/fonts/X11/Type1"
FontPath    "/usr/share/fonts/X11/100dpi"
FontPath    "/usr/share/fonts/X11/75dpi"
FontPath    "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection
 
Section "Module"
Load  "synaptics"
Load  "bitmap"
Load  "ddc"
Load  "dri"
Load  "extmod"
Load  "freetype"
Load  "glx"
Load  "int10"
Load  "type1"
Load  "vbe"
#      Load  "GLcore"
EndSection
 
Section "InputDevice"
Identifier  "Keyboard"
Driver      "kbd"
Option     "CoreKeyboard"
Option     "XkbRules" "xorg"
Option     "XkbModel" "pc105"
Option     "XkbLayout" "it"
EndSection
 
Section "InputDevice"
Identifier  "Mouse"
Driver      "mouse"
Option     "CorePointer"
Option     "Device" "/dev/input/mice"
Option     "Protocol" "ExplorerPS/2"
Option     "Emulate3Buttons" "true"
EndSection
 
Section "InputDevice"
Identifier  "Touchpad"
Driver      "synaptics"
Option     "Device" "/dev/psaux"
Option     "Protocol" "auto-dev"
Option     "LeftEdge" "1700"
Option     "RightEdge" "5300"
Option     "TopEdge" "1700"
Option     "BottomEdge" "4200"
Option     "FingerLow" "25"
Option     "FingerHigh" "30"
Option     "MaxTapTime" "180"
Option     "MaxTapMove" "220"
Option     "VertScrollDelta" "100"
Option     "MinSpeed" "0.10"
Option     "MaxSpeed" "0.30"
Option     "AccelFactor" "0.0150"
Option     "SHMConfig" "on"
        Option      "AlwaysCore" "true"
EndSection
 
### Alternative Touchpad Configuration ###
#
#  Section "InputDevice"
#    Identifier  "Touchpad"
#    Driver      "mouse"
#    Option      "Device" "/dev/input/mice"
#    Option      "Name" "AlpsPS/2 ALPS GlidePoint"
#    Option      "Protocol" "explorerps/2"
#    Option      "Vendor" "Sysp"
#    Option   "LeftEdge" "1700"
#    Option   "RightEdge" "5300"
#    Option      "TopEdge" "1700"
#    Option   "BottomEdge" "4200"
#    Option   "FingerLow" "25"
#    Option   "FingerHigh" "30"
#    Option   "MaxTapTime" "180"
#    Option   "MaxTapMove" "220"
#    Option   "VertScrollDelta" "100"
#    Option   "MinSpeed" "0.10"
#    Option   "MaxSpeed" "0.30"
#    Option   "AccelFactor" "0.0150"
#    Option   "SHMConfig" "on"
#  EndSection
#
###
 
Section "Monitor"
Identifier  "aticonfig-Monitor[0]"
HorizSync    30.0 - 70.0
VertRefresh  50.0 - 100.0
Option     "VendorName" "ATI Proprietary Driver"
Option     "ModelName" "Generic Autodetecting Monitor"
Option     "DPMS" "true"
EndSection
 
Section "Monitor"
Identifier  "aticonfig-Monitor[1]"
Option     "DPMS" "true"
EndSection
 
Section "Device"
Identifier  "aticonfig-Device[0]"
Driver      "fglrx"
Option     "VideoOverlay" "on"
Option     "OpenGLOverlay" "off"
Option     "DesktopSetup" "horizontal,reverse"
BusID      "PCI:1:0:0"
EndSection
 
Section "Screen"
Identifier "aticonfig-Screen[0]"
Device    "aticonfig-Device[0]"
Monitor    "aticonfig-Monitor[0]"
DefaultDepth    24
SubSection "Display"
Viewport  0 0
Depth    24
Modes    "1280x800" "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection
EndSection
 
Section "DRI"
Mode        0666
EndSection
 
### End Of File ###
</pre>
</pre>
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.


====Note====
===Creazione e aggiornamento di una CRL===
 
Per conoscere quali certificati sono stati revocati, &egrave; necessario generare una ''CRL'' (''Certificate Revocation List''):
* Una cosa importante, ma che resta comunque strana, � scrivere, in <tt>/etc/X11/xorg.conf</tt>, i moduli <tt>dri</tt>, <tt>glx</tt> e <tt>GLcore</tt>, in questo ordine. Se ad esempio si mette <tt>GLcore</tt> per primo, l'accelerazione non andr� e il log <tt>/var/log/Xorg.0.log</tt> riporter� una serie di errori, tra cui warning sulla libreria <tt>/usr/lib/xorg/modules/extensions/libGLcore.so</tt> e  un errore verso la fine, tristemente incorniciato. Questo errore non so se sia circoscritto alla mia configurazione o se sia un cosa generale. L'unica cosa � fare un po' di test.
<pre># openssl ca -config openssl.cnf -gencrl -out crl/crl.pem</pre>
* A volte si ottengono risultati migliori installando i driver con '''X non avviato.'''.
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&ugrave; certificati sono revocati.
* Se i driver sono molto recenti il modulo <tt>GLcore</tt> non bisognerebbe inserirlo in <tt>/etc/X11/xorg.conf</tt> : viene caricato automaticamente.
* Aggiornando le librerie Mesa (<tt>libgl1-mesa-dri</tt> oppure <tt>libgl1-mesa-glx</tt> ad esempio), ahim�, pu� capitare che l'accelerazione sparisca all'improvviso. L'unica cosa da fare probabilmente � disinstallare i driver e installarli di nuovo.
* Per quanto riguarda le trasparenze di KDE, credo non siano supportate a livello hardware. Io non sono riuscito ad attivarle, infatti se aggiungo a <tt>/etc/X11/xorg.conf</tt> la sezione:
<pre>Section "Extensions"
Option "Composite" "Enable"
EndSection</pre>
l'accelerazione 3D non viene caricata.
 
===AUDIO===
 
Bisogna installare i paccheti ALSA:
<pre># apt-get install alsa-base alsa-utils</pre>
Poi fare un bel:
<pre># alsaconf</pre>
seguire le istruzioni e poi:
<pre># alsamixer</pre>
per settare i volumi.
 
===Touchpad===
 
La guida � qui: [[Synaptics touchpad]].
 
'''Nota:''' Se utilizzate ksynaptics come tool di configurazione del touchpad, abilitate l'opzione ''ALPS touch pad''.
 
===PCMCIA===
 
Su internet ho trovato che l'adattatore PCMCIA, su questo modello, � riconosciuto con il modulo <tt>yenta_socket</tt>.


===Gestione energetica===
Dopo aver aggiornato una ''CRL'', &egrave; sempre necessario riavviare ''apache-ssl'' per rendere effettivi i cambiamenti.


Per quanto riguarda il risparmio energetico, il centro di controllo di KDE dice che:
Per la configurazione di ''apache-ssl'' relativa all'uso delle ''CRL'' vedere la sezione [[#Configurazione Web Server|Configurazione Web Server]].
''Il computer ha l'installazione ACPI parziale, bisogna abilitare "AC adaptor" e "Control method battery". Quindi ricompilare il kernel.''
 
Date un'occhiata qui: [[Cpufreqd: Cpuscaling per Intel Pentium M]]
 
Io, per risolvere, ho attivato i seguenti moduli:
<pre>acpi-cpufreq
ac
battery
button
fan
processor
thermal
cpufreq_userspace
freq_table</pre>
� possibile farlo con <tt>modconf</tt>.
Comunque molti sono gia' attivati.
Inoltre vanno installati:
<pre>acpi cpufreqd cpufrequtils</pre>
Aggiungete le applet (se avete Gnome) "Variazione frequenza CPU" e "Carica batteria" e siete a posto.
 
Con il comando:
<pre>cpufreq-set</pre>
potete cambiare la frequenza del processore. Esempio:
<pre>cpufreq-set -f 1.2GHz</pre>
oppure ottenere info con:
<pre>cpufreq-info</pre>
 
Se vi intendete di liguaggio C, o avete lavorato per Microsoft o Intel, potete provare a ricompilarvi la DSDT (Differentiated System Description Table). Questo vi permetter�, forse, di ottenere prestazioni migliori, di correggere qualche errore o di aggiungerne di nuovi. La guida � qui: [[ACPI e DSDT]].
 
===Sensori===
 
Guida: [[I2c e lm-sensors]]
 
Anche se questo laptop dovrebbe avere i sensori per le temperature e la ventola, <tt>lm-sensors</tt> non sembra rilevarli.
 
===Note===
 
Il mio mouse (Logitech Optical USB) � riconosciuto subito; il touchpad va cofigurato in /etc/X11/XF86config-4 .
Totem d� un messaggio di errore quando si cerca di riprodurre un file audio o video. Dopo la (re)installazione dei pacchetti ALSA funziona. Le altre applicazioni multimediali vanno bene, tranne XMMS che va solo se non sono in esecuzione altri media player.
 
Una buona guida all'installazione a Debian Sarge � qui:
[http://fabrizio.ciacchi.it/guide.php?pagina=sarge Guida veloce]
 
==Debian Etch==
 
Il comando di boot per installare � questo:
<pre>install acpi=yes vga=771</pre>
Installando da zero la testing ho risolto alcuni problemi, tra cui la gestione energetica e il controllo della batteria.
Durante il processo di installazione ho scelto: ambiente desktop, sistema base e portatile.
 
Per quanto riguarda il PCMCIA, durante l'installazione di etch non si hanno blocchi di sistema.
 
===Video===
 
E' possibile installare i driver video proprietari ATI usando a scelta uno dei tre metodi, analogamente a chi ha Debian Sid: [[#Installare i driver usando l'eseguibile Ati|metodo 1]], [[#Installare i driver usando i pacchetti .deb creati con l'eseguibile Ati|metodo 2]] e [[#Debian Sid|metodo 3]].
 
==Debian Sid==
 
===Video===
 
Fortunatamente sui repository ufficiali di Sid ci sono i pacchetti necessari per attivare l'accelerazione 3D. Con un po' di fatica (sono ancora un po' inesperto) ci sono riuscito; non tanto ad installarli, ma a configurare correttamente Xorg. Oll�!
 
Innanzi tutto installiamo i pacchetti necessari:
<pre># apt-get install fglrx-control fglrx-driver fglrx-driver-dev fglrx-kernel-src</pre>
Siccome il modulo di cui abbiamo bisogno (<tt>fglrx</tt>) � sotto forma di sorgenti (<tt>fglrx-kernel-src</tt>), lo compiliamo e lo installiamo utilizzando <tt>module-assistant</tt>, come descritto [[#Il modulo fglrx|qui]]
 
In teoria abbiamo finito, bisogna solamente configurare [[#xorg.conf (XF86Config-4)|/etc/X11/xorg.conf]] e riavviare X.
 
====Note====
 
* Consultate anche il manuale di <tt>fglrx</tt> (Etch e Sid).
* Naturalmente sono validi anche i metodi sopra riportati: [[#Installare i driver usando l'eseguibile Ati|metodo 1]] e [[#Installare i driver usando i pacchetti .deb creati con l'eseguibile Ati|metodo 2]] .
 
==Ubuntu Dapper==
 
===Video===
 
Chi ha installato Ubuntu, Kubuntu o Xubuntu, pu� installare i driver video Ati proprietari usando a scelta uno dei tre metodi, analogamente a chi ha Debian Sid: [[#Installare i driver usando l'eseguibile Ati|metodo 1]], [[#Installare i driver usando i pacchetti .deb creati con l'eseguibile Ati|metodo 2]] e [[#Debian Sid|metodo 3]].
 
Per quanto riguarda il terzo metodo, ovviamente i pacchetti avranno nomi diversi da quelli disponibili per Debian. Inoltre, sempre per il terzo metodo, se avete una scheda grafica non troppo recente, '''probabilmente''' non servir� compilare il modulo <tt>fglrx</tt>, in quanto presente nel pacchetto <tt>linux-restricted-modules-x.y.z-a-b-c</tt> (che quindi va installato se non lo � gi�), dove <tt>x.y.z-a-b-c</tt> rappresentano la versione e l'architettura del vostro kernel, visibile con il comando:
<pre>$ uname -r</pre>
Ne consegue che aggiornando il kernel, quindi anche il pacchetto linux-restricted-modules, non dovrete ricompilare il modulo <tt>fglrx</tt> , a differenza di chi ha dovuto compilarlo fin dall'inizio.
 
----
----
 
Chiunque volesse contribuire a questa guida � benvenuto (soprattutto e a maggior ragione se ho detto cose '''poco esatte''').


----
----
 
: [[Utente:Nicsar|Nicsar]]
Autore: [[Utente:Superflieriam|Superflieriam]]
[[Categoria:Laptop]]

Versione delle 16:09, 30 ott 2006

Document-page-setup.png Attenzione: questo articolo è ancora incompleto e in fase di scrittura da parte del suo autore.

Sentitevi liberi di contribuire, proponendo modifiche alla guida tramite l'apposita pagina di discussione, in modo da non interferire con il lavoro portato avanti sulla voce. Per altre informazioni si rimanda al template.


Introduzione

L'utilizzazione di una 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 di una LAN con server https: l'utilizzo di una CA locale evita tutti quei noiosi avvisi da parte dei client che lamentano l'incertezza dell'origine del certificato del server https. Un altro scenario è quello in cui sia necessario un sistema di autenticazione web basato su certificati: affinché ogni client possa autenticarsi è necessario che esso presenti il certificato richiesto.

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/sslopenssl.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, 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 XXX per maggiorni 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 utilizzata da 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 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:

È 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:

litio:# 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&ecaute; 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.

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 e' 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 XXX 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 riferisi 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 [sec:Revoca-di-un] e in particolare a [sec: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.

Configurazione Client Browser

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 e' 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):

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


Nicsar