Piccolo glossario

CA

La CA è l'entità (software e operatori) che firma la richiesta di certificato trasformandola in un certificato. L'identità del richiedente un certificato viene garantita da una RA.

Certificato

Un certificato digitale è una coppia di chiavi (pubblica e privata) da usare in un qualche sistema di crittografia a chiave pubblica. Spesso si usa il termine "certificato" solo per indicare la chiave pubblica, mentre il termine "chiave" indica la chiave privata.

RA

La RA è l'entità (software e operatori) che garantisce alla CA l'identità di un richiedente, attraverso un canale sicuro di comunicazione.

CRL

Una Certificate Revocation List o CRL è un elenco strutturato dei certificati digitali invalidati dalla CA che li ha firmati, prima della loro scadenza naturale. Il processo di revoca di un certificato e' irreversibile.

Richiesta di certificato

La richiesta di certificato è il file che contiene la chiave pubblica di un certificato digitale, più alcune informazioni addizionali, secondo un formato specificato in [RFC2511].

Certificati utente

Durante il processo di generazione della richiesta di certificato utente, viene chiesto all'utente di impostare una password. Poiché questa password verrà usata per attivare l'accesso in griglia, è importante che nessuno ne venga a conoscenza, salvo l'utente stesso, oppure che all'utente siano date istruzioni per cambiare questa password prima dell'uso in griglia.

La richiesta di un certificato utente procede in questo modo:

1. La RA attiva il software di richiesta del certificato, ed immette i dati richiesti (nome e indirizzo e-mail dell'utente identificato). La RA è responsabile della correttezza dei dati immessi, un eventuale errore in fase di immisione dei dati deve essere tempestivamente comunicato alla CA, la quale se ha già firmato la richiesta provvederà alla revoca del certificato. In caso di errori nell'immisione dei dati la procedura di richiesta deve essere ripetuta.

2. L'utente immette la password scelta nel software di gestione della RA.

3. Il software di gestione della RA spedisce alla CA, con una email firmata con il certificato della persona che gestisce la RA, la richiesta di certificato per l'utente. Per spedire una e-mail firmata occorre la password del certificato della persona che gestisce la RA.

4. La CA riceve la e-mail, controlla l'autenticità della firma, ed esegue i seguenti controlli addizionali:

   • verifica che l'email di richiesta è stata firmata da un utente il cui certificato appartiene all'elenco delle RA
   • verifica che subject del certificato concorda con il dominio per il quale la RA è autorizzata a richiedere certificati.

5. La RA consegna all'utente la chiave privata. La chiave privata costituisce l'elemento segreto dell'algoritmo asimmetrico di crittografia; ogni azione firmata dalla suddetta chiave privata sarà attribuibile al proprietario della stessa.

6. La CA firma la richiesta, e publica il certificato così generato all'url: www.egrid.it/gridats/ca/archivio una mail di firma avvenuta sarà inviata al richiedente il certificato ed in Cc alla RA; tale mail sarà firmata dalla CA.

Certificati host

Durante il processo di generazione della richiesta di certificato host, non viene chiesto di impostare una password.

La richiesta di un certificato host procede in questo modo:

1. La RA attiva il software di richiesta del certificato, ed immette i dati richiesti (nome DNS completo dell'host e indirizzo e-mail di una persona responsabile del funzionamento dell'host). La RA è responsabile della correttezza dei dati immessi, un eventuale errore in fase di immisione dei dati deve essere tempestivamente comunicato alla CA, la quale se ha già firmato la richiesta provvederà alla revoca del certificato. In caso di errori nell'immisione dei dati la procedura di richiesta deve essere ripetuta.

2. Il software di gestione della RA spedisce alla CA, con una email firmata con il certificato della persona che gestisce la RA, la richiesta di certificato per l'utente. Per spedire una e-mail firmata occorre la password del certificato della persona che gestisce la RA.

3. La CA riceve la e-mail, controlla l'autenticità della firma, ed esegue i seguenti controlli addizionali:

   • verifica che il nome DNS dell'host sia canonico ed abbia risoluzione diretta e inversa.
   • verifica che l'email di richiesta è stata firmata da un utente il cui certificato appartiene all'elenco delle RA
   • verifica che subject del certificato concorda con il dominio per il quale la RA è autorizzata a richiedere certificati.

4. La RA consegna all'utente la chiave privata. La chiave privata costituisce l'elemento segreto dell'algoritmo asimmetrico di crittografia; tale chiave privata deve essere leggibile esclusivamente dal servizio che certifica.

5. La CA firma la richiesta, e publica il certificato così generato all'url: www.egrid.it/gridats/ca/archivio una mail di firma avvenuta sarà inviata al responsabile dell'host indicato nella richiesta ed in Cc alla RA; tale mail sarà firmata dalla CA.

Persone abilitate alla richiesta di certificati

Nel software di richiesta dei certificati, viene mantenuto un database con i certificati (parte pubblica e privata) delle persone che possono firmare le richieste di certificato da inviare alla CA.

Il dischetto viene consegnato dalla CA ad una persona della RA, e quella persona può aggiungere le altre identità, con una opzione del menu principale del software; ogni operazione di aggiunta di altre identità al ruolo di RA deve essere comunicata alla CA che procederà ad abilitare della nuova RA.

Occorre dare comunicazione alla CA dell'abilitazione di un certo utente al ruolo di RA con una email firmata con S/MIME da una identità già nota che riveste il ruolo di RA per un certo istituto. Senza tale comunicazione le richieste dell'aspirante RA verranno rigettate.

Due persone abilitate al ruolo di RA per il medesimo dominio possono utilizzare copie distinte del software della RA; in tal caso le RA non hanno il mutuo controllo delle richieste di certificati effettuate.

Non c'è distinzione tra le identità abilitate alla firma: ciascuna ha gli stessi poteri di un'altra: può inviare richieste di certificati alla CA, e può aggiungere altre identità al novero di quelle abilitate.

Una identità è univocamente associata ad un certificato digitale valido (parte pubblica e privata); questo può essere un qualunque certificato utente emesso dalla CA di GRID@Trieste.

Configurazione del server SMTP

Per mandare e-mail verso l'esterno è necessario configurare un relay mail server che accetti connessioni SMTP dal computer in uso. Questa configurazione può essere fatta una volta per tutte: una volta terminata viene salvata sul dischetto.

Il programma di richiesta dei certificati usa il programma msmtp per inviare le e-mail; il file di configurazione ra/conf/msmtp.conf può essere modificato secondo la sintassi dei file di configurazione di msmtp; tuttavia il programma di richiesta dei certificati è in grado di leggere solo una piccola parte della sintassi di questo file e sovrascriverà il file, per cui, una volta modificato a mano, è bene non usare l'interfaccia grafica per modificarlo ancora.

Esecuzione del programma di richiesta dei certificati

Il software di gestione della RA si lancia con lo script ra-request-certificate.sh, nella directory ra/ del supporto di distribuzione. Il programma richiede il sistema grafico X Windows.

Una volta lanciato, il programma ra-request-certificate.sh esegue una serie di controlli, che a volte possono richiedere un tempo sensibile:

• che tutti i programmi necessari siano installati;
• che la rete sia attiva e che sia possibile risolvere i nomi DNS;
• che il locale corrente usi l'encoding UTF-8;

Quando questi controlli sono stati eseguiti, verrà chiesto di scegliere una delle identità personali abilitate a usare la RA; la password corrispondente alla identità qui scelta verrà chiesta al momento di firmare la richiesta di certificato per la CA. Questa scelta non può essere cambiata! L'unico modo di cambiare identità è di cambiare identità è di uscire dal programma e lanciarlo un'altra volta.

Dopo la scelta dell'identità, comparirà una finestra con un menù con le seguenti scelte; il programma è molto verboso nella sua esecuzione, e guida l'utente passo passo nella generazione dei certificati.

newuser

Per richiedere un nuovo certificato utente.

La richiesta di certificato e la chiave privata generata sono salvati nella directory ra/priv/certs/ou=people; la chiave privata dovrà essere consegnata all'utente al momento della richiesta.

newhost

Per richiedere un nuovo certificato host.

La richiesta di certificato e la chiave privata generata sono salvati nella directory ra/priv/certs/ou=host; la chiave privata dovrà essere consegnata al responsabile dell'host al momento della richiesta.

passphrase

Per cambiare la passphrase su una delle identità personali di RA, non necessariamente quella attualmente selezionata.

Attenzione! questa voce di menu non cambia l'identità attiva, anche se si cambia la passphrase per una altra identità.

import

Permette di aggiungere una nuova identità personale a quelle che possono usare il software della RA e firmare le richieste per la CA; si veda Persone abilitate alla richiesta di certificati.

netconfig

Lancia una script di configurazione dell'interfaccia di rete (funzionerà solo con il Live CD di EGRID).

smtpconfig

Configura il mailer per spedire le email di richiesta di un certificato alla CA; si veda Configurazione del server SMTP.

poweroff

Spegne il computer; funzionerà solo con il Live CD di EGRID.

exit

Termina l'esecuzione del programma ra-request-certificate.sh.

Custodia dell'archivio certificati

Nel supporto con il software viene tenuto anche l'archivio certificati; e questo è l'unico archivio completo (la CA non ha le chiavi private dei certificati emessi). Perciò è soprattutto importante tenere la copia su un mezzo affidabile (si consiglia l'utilizzo di una chiavetta USB anziche' di un floppy disk).

Ogni copia del software gestisce il suo archivio, quindi se una RA è gestita da più persone, queste possono usare lo stesso supporto per l'emissione dei certificati, oppure ciascuna avrà accesso solo ai certificati che ha richiesto.

Anche se i certificati sono protetti dalla passphrase, è bene custodire l'archivio dei certificati e tutte le sue copie di backup in un luogo sicuro e non facilmente accessibile (p.es., un cassetto sempre chiuso a chiave).

Caveats

Il dischetto con il software deve essere formattato con filesystem ext2, perché il programma msmtp richiede permessi stretti sul file di configurazione, che i filesystem di derivazione DOS (vfat) non possono garantire.

Non è possibile cambiare l'identità scelta al lancio del programma, per via di un bug nel mailer mutt ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318470 ).