IFlug: la PKI del LUG
From ImoLUGPedia
Contents |
Certificati x509 all'interno del LUG
Preambolo
Dalle prime riunioni tecniche per la fondazione del LUG è subito emerso il bisogno di avere un portale sia con pagine pubbliche che con pagine private per ottemperare ad alcuni doveri istituzionali legati alla natura dell’associazione. Non dispiaceva altresì mantenere integro e riservato il contenuto di alcune sessioni di collegamento al portale. Tenendo presente lo scopo statutario di divulgazione, mi è parso interessante sperimentare la soluzioine descritta in questo documento. Ritengo personalmente che l’utilizzo di una tecnologia emergente come questa possa conferire lustro all’associazione e favorire l’approccio di persone incuriosite dalla soluzione tecnica adottata. La struttura della PKI Realizzare una Public Key Infrastructure [RFC2459] è un obiettivo decisamente ambizioso anche perché congiunge la necessità di definire una modalità operative alla complessità tecnologica connaturata ai concetti di chiave privata e certificati x509. Nonostante questo, le esigenze a mio avviso non troppo onerose espresse dal LUG, mi portano a pensare che ci sia la possibilità di ridurre tali asperità. In seguito considererò acquisito il concetto di chiave asimmetrica e degli algoritmi che lo possono implementare. Per colmare eventuali lacune rimando alla bibliografia. RA e CA
Lo scopo ora è quello di liofilizzare gli elementi ed i concetti che sviluppano un sistema PKI senza sminuire la sicurezza della struttura. Registration Authority (RA) Pensiamo a questo elemento come una interfaccia con l’utente. Certification Authority (CA) In questa unità logica sono racchiuse tutte le funzioni di controllo e generazione dei certificati x509, di aggiornamento dei certificati revocati, di rinnovo di certificati scaduti. Questi due elementi realizzano una struttura a due livelli in cui l’utente interagisce solo con l’RA più prossima a lui. Mentre gli eventuali supervisori piloteranno le decisioni autorizzative colloquiando direttamente con la CA. Il sistema lo si può considerare sicuro nella misura in cui viene riconosciuta affidabile la CA stessa. Nel mondo reale le CA vengono certificate a enti certificatori istituzionali paritetiche di ACTALIS, ma pensare di agganciarci a questi canali è sicuramente una scelta troppo onerosa rispetto ai possibili vantaggi. Ci si potrebbe accontentare di pubblicare il fingerprint del certificato della CA sul portale, in modo da consentire un controllo manuale al navigatore prudente. Per un esempio reale di PKI si consulti [1].
Ambiente del test
macchina virtuale xen 65MB ram SUSE LINUX 10.1 (i586) Linux 2.6.16.21-0.25-xen nome_macchina openLDAP
- compilato e installato openSSL-0.9.8d da www.openssl.org.
- in /usr/local/ssl, oltre alla directory scripts c’è l’installazione di openssl.
- nella directory scripts...
openLDAP:/usr/local/ssl/scripts # ls -lrt total 56 -rw-r--r-- 1 root root 7816 Mar 21 00:12 openssl.model -rw-r--r-- 1 root root 217 Mar 28 01:34 card.input -rw-r--r-- 1 root root 152 Mar 28 00:14 caext.txt -rw-r--r-- 1 root root 127 Mar 28 00:20 clientext.txt -rwx------ 1 root root 536 Mar 28 00:45 start -rwxr-xr-x 1 root root 10218 Mar 28 01:31 ca-gen.sh
card.input: per rendere più umana la compliazione burocratica degli elementi della CA ho creato questo file contiene i tutti e soli i valori da personalizzare all’atto della generazione di una nuova CA. Ad esempio:
openLDAP:/usr/local/ssl/scripts # cat card.input HOSTNAME = openLDAP DOMAIN = imolug.it NAMECA = IFlug CN = "LUG" ONU = "Imola-Faenza LinuxUserGroup" PN = "via Macchiavelli 8 40026 Imola BO" N = "IT" EMAIL = "info@imolug.it" DAYS = 3650 SITE = "www.imolug.it" CRLFREQ = 1
openssl.model: funge da template del file di configurazione da passare ad openssl, i valori di default verranno sostituiti, a tempo debito con le personalizzazioni contenute in card.model e saranno salvate stabilmente all’interno della directory della CA.
caext.txt e clientext.txt: sono due personalizzazioni delle politiche di gestione, la prima specifica per la generazione di certificati per CA la seconda per l’emissione di certificati client. Nel nostro caso:
openLDAP:/usr/local/ssl/scripts # cat caext.txt subjectAltName = DNS :[] basicConstraints = critical,CA:TRUE,pathlen:0 nsCertType = sslCA,emailCA,objCA nsComment = "Certificate of the private CA4LUG" openLDAP:/usr/local/ssl/scripts # cat clientext.txt subjectAltName = email:[] basicConstraints = critical,CA:FALSE nsCertType = client,email nsComment = "Certificate Client 4LUG"
ca-gen.sh: la libreria con le primitive necessarie alla gestione della CA
start: uno script di generazione della CA che sfrutta la libreria di cui sopra.
Generazione CA
Prima di tutto genero la struttura di directory pertinente ad una CA:
...
mkdir -p ${CATOP}
mkdir -p ${CATOP}/certs
mkdir -p ${CATOP}/crl
mkdir -p ${CATOP}/newcerts
mkdir -p ${CATOP}/private
chmod 700 ${CATOP}/certs ${CATOP}/crl ${CATOP}/newcerts ${CATOP}/private
echo "01" > ${CATOP}/serial
touch ${CATOP}/index.txt
chmod 600 ${CATOP}/serial
chmod 600 ${CATOP}/index.txt
...
Poi genero una stringa che utilizzero come seme per generare la password di accesso alla chiave privata della CA:
dd if=/dev/urandom of=${CATOP}/private/.pwd bs=1k count=2
chmod 600 ${CATOP}/private/.pwd
In particolare posso calcolare la password facendo:
export var=$(md5sum ${CATOP}/private/.pwd|awk ' { print $1 } ')
Genero finalmente la chiave privata della CA con algoritmo 3DES a 1024bit:
openssl genrsa -des3 -out ${CATOP}/private/$CAKEY -passout env:var 1024
Creo la Certification Signing Request correlata con la chiave appena generata:
openssl req -new -batch -passin env:var -key ${CATOP}/private/$CAKEY -out ${CATOP}/$CACSR
Ora mi autofirmo la richiesta generando il certificato della CA:
openssl x509 -req $DAYSCA -in ${CATOP}/$CACSR -signkey ${CATOP}/private/$CAKEY<br>
-extfile ./caext.txt -out ${CATOP}/$CACERT -passin env:var
Per pulizia estraggo la versione CRT del certificato:
openssl x509 -in ${CATOP}/cacert.pem -out ${CATOP}/cacert.crt
Inizializzo la Certification Revocation List:
openssl ca -passin env:var -gencrl -out ${CATOP}/crl/cacrl.pem
Genero gli oggetti ed i link per terminare la configurazione della CA:
cp ${CATOP}/cacert.pem ${SSLCERT}/00.pem
cd ${SSLCERT}
ln -s 00.pem `openssl x509 -hash -noout -in 00.pem`.0
ln -s ../crl/cacrl.pem `openssl x509 -hash -noout -in 00.pem `.r0
Questa CA ora è funzionante!
Generazione Certificati Server
Supponiamo di voler generare la chiave privata ed il certificato, firmato dalla nostra CA per il server https con virtual host valorizzato a www.iflug.it.
openssl req -new -batch -nodes -out ${SSLREQ}/req-server-www.iflug.it.csr<br>
-keyout ${SSLCERT}/key-server-www.iflug.it.pem $DAYS<br>
-subj /commonName="www.iflug.it"/emailAddress="info@iflug.it"
A differenza di una chiave privata normale, quella dei server non deve essee protetta da password, altrimenti all’avvio del servizio http mi verrebbe richiesta la password... questa particolarità la ottengo introducendo la flag -nodes.
Ora devo firmare la richiesta:
openssl x509 -req -passin env:var $DAYS<br>
-in ${SSLREQ}/req-server-www.iflug.it.csr<br>
-CA ${CATOP}/${CACERT} -CAkey ${CATOP}/private/${CAKEY}<br>
-out ${SSLCERT}/cert-www.iflug.it.pem -Cacreateserial
cd ${SSLCERT}
ln -s cert-$2.pem $(openssl x509 -noout -hash -in cert-$2.pem).0
Generazione Certificati Client
Supponiamo di voler generare un certificato client per l’utente pvb265 e di volerlo firmare con la nostra CA. Per farlo, prima di tutto generiamo una chiave privata 3DES a 1024bit e la proteggiamo con una password:
openssl genrsa -des3 -out ${SSLREQ}/pvb265.key -passout env:P 1024
Generiamo la CSR derivante dalla chiave:
openssl req -new -batch -passin env:P -key ${SSLREQ}/pvb265.key<br>
-out ${SSLREQ}/req-pvb265.csr $DAYS<br>
-subj /commonName="pvb265"/emailAddress="valerio.balbi@iflug.it"
Firmo la richiesta generando il certificato client desiderato:
openssl x509 -req -days 365 -CA ${CATOP}/cacert.pem<br>
-CAkey ${CATOP}/private/cakey.pem -in ${SSLREQ}/req-pvb265.csr<br>
-extfile ./clientext.txt -out ${SSLCERT}/cert-pvb265.pem<br>
-passin env:var -CAcreateserial
cd ${SSLCERT}
ln -s cert-$2.pem $(openssl x509 -noout -hash -in cert-$2.pem).0
In realtà, per poterlo utilizzare devo poter impacchettare la chiave privata ed il certificato appena generati in una struttura riconosciuta da browser, vpnclient, client-mail... Inoltre per accedere agli elementi del pacchetto sarà necessario inserire la nuova password Q.
Il formato designato è il PKCS12:
openssl pkcs12 -passin env:P -passout env:Q -in ${SSLCERT}/cert-pvb265.pem<br>
-inkey ${SSLREQ}/pvb265.key -out ${SSLCERT}/cert-pvb265.p12<br>
-export -name pvb265
Implementazione della RA
Implementazione della RA ancora da verificare.
Dovrebbe ricalcare l’esperienza dell’università di Modena ed essere un modulo del portale del LUG. Eviterei di lasciare la gestione delle revoche, attività prossima alle funzioni della CA, su questo modulo.
Utilizzo
Partiamo dal presupposto che il server https sia stato configurato correttamente.
Navigare in HTTPS
Per navigare su un sito protetto da certificato ssl (leggasi accesso al sito in https) non serve altro che il vostro browser preferito. Mi immagino che il sito della vostra banca sia protetto con questi paradigmi e mi immagino che il certificato utilizzato sia stato firmato da una CA ufficialmente riconosciuta.
Se andiamo a scorrere la lista delle CA conosciute dal nostro browser... ovviamente mancherà quella appena generata del LUG.
Questa mancanza è la causa della finestra di popup che il browser vi presenterà navigando sul link https://www.iflug.it.
Per sanare questa situazione una volta per tutte basta importare il certificato della CA del LUG all’interno del vostro browser.
Ad esempio, in Firefox 2.0.0.1, si va in
Modifica → Preferenze → Mostra certificati → Autorità → Importa
Scegliere cacert.pem e potrete visualizzare questo:
Navigare in HTTPS utilizzando il Certicato Client
Per quei siti protetti da ssl per i quali sia richiesta il controllo di un certificato client, basterà importare il pacchetto pkcs12 contenenti la chiave privata ed il certificato firmato dalla CA. Alla fine dell’import vi troverete qualcosa di simile a questo panel:
Navigare in HTTPS - Screencast
Utilizzo del Certificato Client nella posta elettronica
Alla stessa maniera, è possibile importare il certificato client all’interno del client di posta. Per esempio Thunderbird 2 beta 1.
Edit → Preferences
View Certificates → Import
Utilizzo del Certificato Client per documenti OpenOffice
Su un sistema Linux, per dire ad OpenOffice, dove andare a prendere i certificati bisogna esportare la variabile:
MOZILLA_CERTIFICATE_FOLDER=~/.mozilla/firefox/xr34w2ib.default
cartella contenente i certificati di firefox per esempio... Fatto questo potrete includere il vostro certificato al documento Utilizzo del Certificato Client per firmare e crittografare File
Di solito siamo abituati ad usare PGP o GPG per crittografare un file. Queste due modalità sono imperniate sul concetto di anello delle chiavi. Con i certificati x509 la firma e la crittografia vengono veicolate dalla CA.
In questo senso dovrebbe essere possibile utilizzare il pacchetto PKCS12 come sorgente per firmare e criptare i nostri file dati.
A tal proposito ho trovato riferimenti al binomio KGPG e Kleopatra...
