Superflieriam

→‎Il mio weblog: cambiato blog
(aggiunto contributo driver Ati)
(→‎Il mio weblog: cambiato blog)
Riga 1: Riga 1:
{{stub}}
{{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.


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.
Uno dei primi passi da affrontare subito dopo l' installazione della nostra Debian dovrebbe essere quello di accertarsi quali sono i servizi e i demoni che vengono lanciati dal sistema. Questa operazione permette un controllo migliore della sicurezza della nostra macchina ed una minore esposizione a rischi legati ad intrusioni.


Illustrerò come generare una CA locale, come usarla per creare certificati
In questa breve guida vedremo come controllare i servizi attivi, come eliminare quelli non necessari e come rendere pi� sicuri quelli che intendiamo utilizzare.
lato server e lato client, infine mostrer� come revocare un certificato.


==Installazione e Configurazione di Openssl==
Buona lettura & happy Debian!
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:
<pre>apt-get install openssl</pre>


Per minimizzare la quantit� di informazioni richieste durante la creazione di chiavi e certificati, pu&ograve;
=Concetti di base=
essere utile modificare il file '''/etc/ssl/openssl.cnf''' per esempio alla seguente sezione:
==Servizi & Demoni==
<pre>
In un sistema operativo si definisce "servizio" (o anche "demone") un processo in background che gira autonomamente, senza intervento da parte dell' utente, o comunque con una interazione ridotta al minimo. Un esempio di servizo &egrave; il server web Apache: il server viene controllato dal demone "httpd" che gira in background, resta in ascolto sulla porta indicata e serve le pagine richieste.
[ req_distinguished_name ]


countryName            = Country Name (2 letter code)
=Strumenti=
countryName_default    = IT
GNU/Linux fornisce una nutrita schiera di programmi che ci permettono di interagire con i servizi attivi sulla nostra macchina. Di seguito riporto quelli pi� usati nell' amministrazione di un sistema Debian.
...
stateOrProvinceName            = State or Province Name (full name)
stateOrProvinceName_default    = Italy
...


0.organizationName              = Organization Name (eg, company)
==netstat==
0.organizationName_default      = Azienda SpA
...
</pre>


==Generazione di una CA locale==
Netstat � uno dei programmi pi� utili ed utilizzati: permette di elencare tutta una serie di informazioni (socket aperti, routing tables, processi, ecc...). Per il nostro scopo utilizzeremo netstat per ottenere un elenco di tutte le connessioni di rete aperte sulla nostra macchina. Ottenere queste informazioni � il primo passo per conoscere nel dettaglio cosa succede all' interno del nostro sistema operativo.  
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)===
Ora cerchiamo tutte le connessioni di rete in ascolto (stato LISTEN) sul nostro sistema.
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''.
<pre># netstat -l |grep tcp
tcp        0      0 *:netbios-ssn          *:*                    LISTEN
tcp        0      0 *:5900                  *:*                    LISTEN
tcp        0      0 *:www                  *:*                    LISTEN
tcp        0      0 *:sieve                *:*                    LISTEN
tcp        0      0 *:ssh                  *:*                    LISTEN
tcp        0      0 localhost.localdom:8118 *:*                    LISTEN
tcp        0      0 *:ipp                  *:*                    LISTEN
tcp        0      0 localhost.localdom:smtp *:*                    LISTEN
tcp        0      0 *:microsoft-ds          *:*                    LISTEN</pre>


{{ warningbox | vista l'importanza della chiave privata a livello sicurezza, dare gli opportuni permessi alla directory '''/etc/openssl/private''' e a '''ca.key'''. }}
Ho scelto di limitare l' output alle sole connessioni in attesa di connessione. Potete anche provare ad utilizzare i comandi '''netstat -a''', '''netstat -l''', '''netstat -l |grep tcp''', ecc...


===Generazione del certificato (root CA)===
Le colonne da prendere in esame sono (in questo esempio) la terza e la quarta. La terza colonna riporta l' accoppiata indirizzo+porta su cui � un ascolto il servizio.  
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)|Creazione della chiave (root CA)]], per generare un certificato root CA '''ca.crt''' con validit&agrave; di un anno:
Se osserviamo la prima linea dell' output, la terza colonna indica come coppia indirizzo+porta il testo '''*:netbios-ssn''': questo significa che � attivo un servizio in ascolto per qualsiasi (*) indirizzo di rete configurato sulla macchina e che questo servizio � associato alla porta '''netbios-ssn'''.
<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.
Nelle altre righe possiamo notare che, nella colonna degli indirizzi, oltre al "*" (che indica ''qualsiasi indirizzo'') compare anche ''localhost.localdomain''. Netstat tenta di risolvere gli indirizzi ip e reperisce questo hostname dal file '''/etc/hosts''', per cui localhost.localdomain corrisponde (nel mio esempio) all' indirizzo dell' interfaccia di loopback (127.0.0.1), come possiamo verificare con un semplice


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>$ cat /etc/hosts |grep localhost.localdomain
127.0.0.1 localhost.localdomain localhost debby</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.
&Egrave; interessante notare come per alcune porte venga riportato un valore numerico, mentre per altre un valore alfanumerico.


==Certificato lato server==
Valore numerico:
Questo &egrave; il certificato che il server utilizza per cifrare i dati scambiati con i vari client. Un tipico esempio � un server ''https''.
<pre>tcp        0      0 *:5900                  *:*                    LISTEN</pre>
Valore alfanumerico:
<pre>tcp        0      0 *:netbios-ssn          *:*                    LISTEN</pre>


====Creazione della chiave (server)====
Questo comportamento di netstat � presto spiegato: quando il programma rileva un servizio in ascolto su una porta (ad esempio la porta 5900), cerca una corrispondenza con la stessa all' interno del file ''/etc/services''.
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:
Il file ''services'' � un file testuale che associa un numero di porta numerico alla descrizione alfanumerica del servizio associato alla stessa.
<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.}}
Se vogliamo vedere a quale porta corrisponda il dato ''netbios-ssn'' dell' esempio precedente, � sufficiente cercarlo all' interno del file services:


===Generazione di una Certificate Signing Request (CSR)===
<pre>$ cat /etc/services |grep netbios-ssn
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:
netbios-ssn    139/tcp                        # NETBIOS session service
<pre>litio:# openssl req -config /etc/ssl/openssl.cnf -new -key private/server.key -out server.csr
netbios-ssn    139/udp</pre>
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.
Nel nostro esempio, dato che la porta era di tipo TCP, il valore cercato � il primo ottenuto.


===Firma della CSR===
Agendo sul file services possiamo quindi assegnare un valore descrittivo alle porte riportate solo con il valore numerico. Ad esempio tornando alla porta 5900, probabilmente vorremo associarla al servizio ad essa associata (vnc).
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.
Sar� quindi sufficiente editare il file services ed aggiungere la linea:
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==
<pre>vnc-server      5900/tcp        vnc-server      # TightVNC Server</pre>
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===
A questo punto avremo realizzato l' associazione porta/descrizione:
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===
<pre>~# netstat -l |grep tcp
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]].
[...]
tcp        0      0 *:vnc-server            *:*                    LISTEN
[...]</pre>
 
Per quanto riguarda la quarta colonna, nell' esempio precedente possiamo vedere che il valore � identico per tutti i servizi e cio� '''*:*'''. Questo significa che il servizio � pronto a ricevere connessioni da qualsiasi indirizzo ip e da qualsiasi porta ad esso associata.
 
Notiamo a questo punto che alcuni dei servizi avviati sono in ascolto su qualsiasi indirizzo ip configurato sulla nostra macchina (*), mentre alcuni sono legati (si dice anche binding) all' indirizzo ''localhost.localdomain'' che abbiamo visto prima corrispondere all' indirizzo di loopback (127.0.0.1).
 
Quando un servizio � in ascolto unicamente sull' interfaccia di loopback significa che sar� raggiungibile unicamente attraverso quell' interfaccia. Questo ci garantisce che l'unico host in grado di contattare il servizio � la stessa macchina che lo ha in esecuzione.
 
Nell' esempio di prima i servizi raggiungibili unicamente dall' interfaccia di loopback sono '''smtp''' e '''8118'''. Come impareremo a verificare pi� tardi, si tratta rispettivamente del server di posta '''exim''' e del proxy '''privoxy'''.
 
==lsof==
 
Se con '''netstat''' siamo in grado di monitorare quali servizi sono in ascolto sulla nostra macchina, � anche indispensabile sapere quale programma abbia lanciato e controlli ogni singolo servizio.
 
Una caratteristica peculiare dei sistemi operativi derivati da Unix (tra cui appunto GNU/Linux) � che qualsiasi elemnto del sistema viene visto come se fosse un file. Abbiamo files veri e propri (ad es.: pippo.txt), abbiamo i dispositivi hardware (si trovano in /dev, e sono rappresentati da file veri e propri) ed abbiamo le connessioni di rete (anche queste sono veri e propri file).
 
Approfittando di questa caratteristica di GNU/Linux, possiamo investigare in maniera approfondita sui nostri servizi: se per il sistema operativo si tratta di files allora possiamo sapere chi li ha creati e chi li ha aperti.
 
Lo strumento principe per questo scopo � '''lsof'''. Come per la maggior parte dei comandi GNU, lsof � una abbreviazione (in questo caso ricorsiva!) della descrizione del comando: lsof = '''LS O'''pen '''F'''iles, cio� '''L'''i'''S'''t '''O'''pen '''F'''iles (elenca i files aperti).
 
Dato che le connessioni di rete sono rappresentate da veri e propri files, possiamo usare lsof per ottenere informazioni su di esse.
 
Poniamo il caso di voler ottenere informazioni sul servizio:
 
<pre>tcp        0      0 *:netbios-ssn          *:*                    LISTEN</pre>


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''.
Sar� sufficiente utilizzare lsof:


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># lsof -i |grep netbios-ssn
<pre>
smbd      4089        root  21u  IPv4  8082      TCP *:netbios-ssn (LISTEN)</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
In questo modo possiamo vedere che il servizio in ascolto sulla porta associata a '''netbios-ssn''' (la porta 139) � controllato dal programma '''smbd'''.
</pre>


===CA, certificati e CRL per virtual host===
Allo stesso modo possiamo fare con '''www''' e '''smtp''', ecc...
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.
<pre># lsof -i |grep www
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:
apache    4342        root  16u  IPv4  8423      TCP *:www (LISTEN)
<pre>
apache    4349    www-data  16u  IPv4  8423      TCP *:www (LISTEN)
[...]
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==
# lsof -i |grep smtp
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]].
exim4    3901 Debian-exim    3u  IPv4  7625      TCP localhost.localdomain:smtp (LISTEN)</pre>


===Creazione chiave (client)===
==Apt System==
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===
Ora che sappiamo quale programma controlla un determinato servizio, abbiamo la possibilit� di risalire a quale pacchetto Debian lo contiene per - eventualmente - rimuoverlo, oppure ottenere versioni pi� aggiornate, ricompilarlo con patches specifiche, ecc...
<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===
Il sistema pi� semplice ed allo stesso pi� potente per individuare quale pacchetto Debian contiene un file, consiste nell' utilizzare il programma '''apt-file'''. Per l' installazione e l' utilizzo di apt-file, vi rimando all' ottima guida [[Apt-file: ricerca all'interno dei pacchetti]], scritta da MaXeR.
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:
Nel contesto a noi necessario utilizzeremo la funzione di ricerca di apt-file per risalire a quale pacchetto contiene il programma che lancia un particolare demone.
<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:
Continuiamo a utilizzare come esempio il servizio in ascolto sulla porta '''netbios-ssn'''. Per adesso siamo riusciti a risalire al fatto che il servizio netbios-ssn corrisponde alla porta 139 e che � controllato da '''smbd'''.
<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.
Ora vedremo cosa sia '''smbd'''. Prima di tutto verifichiamo quale script o programma si preoccupa di lanciare smbd


===Importazione dei certificati===
<pre># lsof |grep smbd |grep txt
I certificati da importare nel browser secondo quanto fin qui descritto sono:
smbd      4089        root  txt      REG        3,3  2805852      34840 /usr/sbin/smbd
# '''ca.crt''' - certificato della ''CA'' locale, da importare nella sezione "Autorit&agrave;". Serve per dare "fiducia" al sito web della LAN.
smbd      4094        root  txt      REG        3,3  2805852      34840 /usr/sbin/smbd</pre>
# '''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)''.
Ora vediamo quale pacchetto contiene /usr/sbin/smbd:


il seguente comando revoca il certificato certs/client1.crt:
<pre># apt-file search /usr/sbin/smbd
<pre>
samba: usr/sbin/smbd
# openssl ca -config openssl.cnf -revoke certs/client1.crt -crl_reason superseded
samba-dbg: usr/lib/debug/usr/sbin/smbd</pre>
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===
Controlliamo quale di essi sia presente nel nostro sistema:
Per conoscere quali certificati sono stati revocati, &egrave; necessario generare una ''CRL'' (''Certificate Revocation List''). Una ''CRL'' &egrave; una lista che dichiara quali certificati sono stati revocati e la motivazione della revoca.
<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.
<pre># dpkg -l samba*
Desiderato=sconosciUto/Installato/Rimosso/P:eliminato/H:bloccato
| Stato=Non/Installato/file Config./U:spacchett./conf. Fallita/H:inst.parzial.
|/ Err?=(nessuno)/H:bloc./necess.Reinst./X=entrambi (Stato,Err: maiusc.=grave)
||/ Nome          Versione      Descrizione
+++-==============-==============-============================================
ii  samba          3.0.14a-6      a LanManager-like file and printer server fo
un  samba-client  <non definita> (descrizione non disponibile)
ii  samba-common  3.0.14a-6      Samba common files used by both the server a
un  samba-doc      <non definita> (descrizione non disponibile)</pre>


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)
[[Utente:Keltik|Keltik]] 05:26, Giu 23, 2005 (EDT)
[[Categoria:Sistema]]
[[Categoria:Networking]]
127

contributi