Indice Guide: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Indice Guide (visualizza wikitesto)

Versione delle 18:58, 1 nov 2006

22 byte rimossi ,  1 nov 2006
→‎Xorg / Xfree: tolto stub guida ATI
(→‎Xorg / Xfree: tolto stub guida ATI)
Riga 1: Riga 1:
{{stumb}}
{{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.


==Intro==
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.
Questa e' la traccia della guida che scrivero'<br>


=== Installazione PVM ===
Illustrer&ograve; come generare una CA locale, come usarla per creare certificati
*Installare pvm e pvm-dev
lato server e lato client, infine mostrer� come revocare un certificato.
root@insanelab-cluster:apt-get install pvm
root@insanelab-cluster:apt-get install pvm-dev


*modificare /etc/profile aggiungendo: <br>
==Installazione e Configurazione di Openssl==
Per installare la libreria SSL e gli applicativi necessari alla creazione di chiavi e certificati dare il comando:
<pre>apt-get install openssl</pre>


#variable for PVM
Per minimizzare la quantit� di informazioni richieste durante la creazione di chiavi e certificati, pu&ograve;
PVM_ROOT=/usr/lib/pvm3
essere utile modificare il file '''/etc/ssl/openssl.cnf''' per esempio alla seguente sezione:
export PVM_ROOT<br>
<pre>
PVM_ARCH=`$PVM_ROOT/lib/pvmgetarch`
[ req_distinguished_name ]
export PVM_ARCH<br>
PVM_RSH=/usr/bin/ssh
export PVM_RSH<br>
PVM_TMP=/tmp
export PVM_TMP<br>
#Add pvm binary to PATH
PATH=$PVM_ROOT/bin:$PATH
export PATH<br>


*Modificare il file LINUX.def inserendo il modo che usiamo per connetterci (ssh)
countryName            = Country Name (2 letter code)
countryName_default    = IT
...
stateOrProvinceName            = State or Province Name (full name)
stateOrProvinceName_default    = Italy
...


nano /usr/lib/pvm3/conf/LINUX.def
0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Azienda SpA
...
</pre>


#LINUX.def
==Generazione di una CA locale==
ARCHCFLAGS      =       -DSYSVSIGNAL -DNOWAIT3 -DRSHCOMMAND=\'''"/usr/bin/ssh\"''' \
Per mezzo di questa autorit&agrave; di certificazione saranno creati tutti gli altri certificati: quello del server e quelli dei client.
                                -DNEEDENDIAN -DFDSETNOTSTRUCT -DHASERRORVARS \
                                -DCTIMEISTIMET -DSYSERRISCONST


=== Configurazione sistema ===  
===Creazione della chiave (root CA)===
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>


*Editare /etc/hosts '''commentatando localhost''' e aggiungendo i nodi
La chiave sar&agrave; generata dopo aver immesso la ''pass phrase''.


#/etc/hosts
{{ warningbox | vista l'importanza della chiave privata a livello sicurezza, dare gli opportuni permessi alla directory '''/etc/openssl/private''' e a '''ca.key'''. }}
#127.0.0.1      localhost.localdomain  localhost      insanelab-cluster
  192.168.100.69 insanelab-cluster
  192.168.100.3  node3
  192.168.100.5  node5
  192.168.100.2  node2


*Creare un utente per ogni nodo
===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.
root@nodeX:adduser user


=== Evitare la password con ssh ===
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:
*Bisogna generare una chiave nel server (edalab-cluster)
<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>


user@insanelab-cluster: ssh-keygen -t rsa
Il certificato appena creato sar&agrave; utilizzato esclusivamente per firmare tutti gli altri certificati generati in seguito.


*entrare nella directory /home/user/.ssh/
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.


user@insanelab-cluster: cd /home/user/.ssh
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.


*copiare id_rsa.key in tutti i nodi
==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''.


user@insanelab-cluster: scp id_rsa user@nodeX://home/user/.ssh
====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)|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># openssl rsa -in private/server.key -out private/server.key.unsecure
Enter pass phrase for private/server.key:
writing RSA key</pre>


*Loggarsi nei nodi
{{ Warningbox | la chiave priva di ''pass phrase'' non &egrave; protetta, quindi assicurarsi che abbia i permessi opportuni.}}


ssh user@nodeX
===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>


*Entrare nella directory .ssh e copiare la chiave in authorizedkey2
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.


cd .ssh
===Firma della CSR===
cat id_rsa.key >> authorizedkey2
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]]:
rm id_rsa.key
<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>


*Riavviare ssh ed e' fatta!
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.
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==
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: <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)
Superflieriam
127

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/14082"

Menu di navigazione