Driver AMD proprietari: differenze tra le versioni

Nessun cambiamento nella dimensione ,  1 nov 2006
m
Riga 1: Riga 1:
{{stub}}
== Scrivere su file system ntfs ==
==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 in cui si voglia realizzare un sistema di autenticazione web basato su certificati: per autenticarsi i client devono presentare il certificato richiesto.
Finalmente possiamo scrivere, creare cartelle, copiare testi e immagini su file system ''ntfs''. Occorrono due programmi ''fuse'' e ''ntfs-3g''.
Iniziamo, scarichiamo ''fuse''


Illustrerò come generare una CA locale, come usarla per creare certificati
http://fuse.sourceforge.net
lato server e lato client, infine mostrer� come revocare un certificato.


==Installazione e Configurazione di Openssl==
lo estraiamo e ci portiamo nella cartella estratta
Per installare la libreria SSL e gli applicativi necessari alla creazione di chiavi e certificati dare il comando:
<pre>apt-get install openssl</pre>


Per minimizzare la quantit� di informazioni richieste durante la creazione di chiavi e certificati, pu&ograve;
<pre> tar xzvf fuse-2.5.3.tar.gz
essere utile modificare il file '''/etc/ssl/openssl.cnf''' per esempio alla seguente sezione:
cd fuse-2.5.3 </pre>
<pre>
[ req_distinguished_name ]


countryName            = Country Name (2 letter code)
installiamo, col kernel 2.6.17 il modulo ''fuse'' � gi� abilitato nel kernel, quindi
countryName_default    = IT
...
stateOrProvinceName            = State or Province Name (full name)
stateOrProvinceName_default    = Italy
...


0.organizationName              = Organization Name (eg, company)
<pre> ./configure--enable-kernel-module </pre>
0.organizationName_default      = Azienda SpA
...
</pre>


==Generazione di una CA locale==
Ora scarichiamo ntfs-3g
Per mezzo di questa autorit&agrave; di certificazione saranno creati tutti gli altri certificati: quello del server e quelli dei client.


===Creazione della chiave (root CA)===
http://mlf.linux.rulez.org/mlf/ezaz/ntfs-3g-download.html
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'':
<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>


La chiave sar&agrave; generata dopo aver immesso la ''pass phrase''.
estraiamo e ci portiamo nella cartella


{{ warningbox | vista l'importanza della chiave privata a livello sicurezza, dare gli opportuni permessi alla directory '''/etc/openssl/private''' e a '''ca.key'''. }}
<pre> cd ntfs-3g-20070920-BETA
./configure
make
make install #ovviamente da root </pre>


===Generazione del certificato (root CA)===
{{Box|AGGIORNAMENTO|'''<tt>ntfs-3g</tt>''' � entrato in <tt>unstable</tt> quindi chi ha i repository abilitati pu� saltare
Prima di procedere assicurarsi che '''/etc/ssl/index.txt''' sia vuoto e che '''/etc/ssl/serial''' contenga il valore 01.
la parte superiore e usare <tt>apt</tt> per installarlo. Per il resto proseguire normalmente.}}


Utilizziamo la chiave creata nella sezione [[#Creazione della chiave (root CA)|Creazione della chiave (root CA)]], 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>


Il certificato appena creato sar&agrave; utilizzato esclusivamente per firmare tutti gli altri certificati generati in seguito.
OK, se non si sono ricevuti errori, bisogna montare la partizione per poterla utilizzare, creiamo la dir


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 [[#Certificato lato client | Certificazione lato client]] per ottenere maggiorni informazioni.
<pre> mkdir /media/windows </pre>


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 &egrave; utilizzato in uno script.
e la montiamo


==Certificato lato server==
<pre> ntfs-3g /dev/hda1 /media/windows -o locale=it_IT.utf8 </pre>
Questo &egrave; 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)====
se si vuole la partizione montata in auto, editare ''/etc/fstab'' ed aggiungere la seguente riga
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># openssl genrsa -des3 -out private/server.key 1024
Enter pass phrase for private/server.key:
Verifying - Enter pass phrase for private/server.key:</pre>


&Egrave; molto 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> /dev/hda1 /media/windows ntfs-3g defaults 0 0 </pre>
<pre># openssl rsa -in private/server.key -out private/server.key.unsecure
Enter pass phrase for private/server.key:
writing RSA key</pre>


{{ Warningbox | la chiave priva di ''pass phrase'' non &egrave; protetta, quindi assicurarsi che abbia i permessi opportuni.}}
Bene ora possiamo usare la partizione con file system ''ntfs''.


===Generazione di una Certificate Signing Request (CSR)===
'''P.S.''' Potrebbe essere utile installare <tt>fuse-utils</tt> e <tt>ntfsprogs</tt> direttamente con <tt>apt</tt>.
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>


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.
== link esterni ==


===Firma della CSR===
http://wiki.linux-ntfs.org/doku.php?id=ntfs-3g
Quando disponiamo di una ''CSR'' &egrave; necessario spedirla alla ''CA'' scelta affinch&eacute; 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>


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.
ciao
Il risultato dell'operazione &egrave; il certificato per mezzo del quale il server https cifrer&agrave; i dati scambiati con i client.


==Configurazione Web Server==
:[[Utente:Xtow|Xtow]]
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: <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 <tt><hash>.r<number>, dove <hash></tt> &egrave; l'hash del file contenente la ''CRL''. La sezione [[#Apache e CRL | Apache e CRL]] 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>
 
===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]].
 
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''.
 
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'''):
<pre>
# 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
</pre>
 
===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''.
 
La prima conseguenza &egrave; che si possono specificare ''CA'', ''CRL'' e certificati distinti per ogni singolo host virtuale.
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:
<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.
 
==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&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>
 
===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>
# 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>
 
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>
 
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>
 
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.
 
===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.
 
==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:
<pre>
# openssl ca -config openssl.cnf -revoke certs/client1.crt -crl_reason superseded
Enter pass phrase for private/ca.key:
</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.
 
===Creazione e aggiornamento di una CRL===
Per conoscere quali certificati sono stati revocati, &egrave; necessario generare una ''CRL'' (''Certificate Revocation List''):
<pre># openssl ca -config openssl.cnf -gencrl -out crl/crl.pem</pre>
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.
 
Dopo aver aggiornato una ''CRL'', &egrave; 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|Configurazione Web Server]].
 
----
: [[Utente:Nicsar|Nicsar]] 05:00, 1 Nov 2006 (CST)
127

contributi