Università degli Studi di Salerno
Corso di Sicurezza su Reti II
RELAZIONE FINALE CA GROUP
SIMULAZIONE DI UNA CERTIFICATION
AUTHORITY
Prefazione:
Questo documento è stato stilato per il progetto di sicurezza su reti II e ha lo scopo di spiegare il
lavoro fatto dal gruppo di certification authority.
Membri del gruppo (in ordine alfabetico):
Marino Pasquale
Marra Maria Cristina
Molaro Alfonso
Rullo Esterino
_______________________________________________________________________________
1
INDICE
Certification authority .......................................................................................................................... 4
Doveri del gioco ................................................................................................................................... 6
Doveri di una CA ............................................................................................................................. 6
Servizi offerti ................................................................................................................................... 6
Doveri del sottoscrittore ................................................................................................................... 7
Doveri di terze parti coinvolte ......................................................................................................... 7
Certificati digitali ................................................................................................................................. 8
X.509 ................................................................................................................................................ 8
Storia ................................................................................................................................................ 8
Certificati X.509............................................................................................................................... 8
Struttura del certificato..................................................................................................................... 9
Installazione ....................................................................................................................................... 10
Primo step ...................................................................................................................................... 10
Sequenza di installazione ........................................................................................................... 11
Secondo step .................................................................................................................................. 11
Sequenza di installazione ........................................................................................................... 11
Configurazione SendMail .......................................................................................................... 15
Creazione di uno script per l’avvio dei servizi .......................................................................... 17
Configurazione di OpenCA ............................................................................................................... 18
Fase 1 : Inizializzazione della Certification Authority .................................................................. 18
Fase 2 : Creazione dell’amministratore ......................................................................................... 18
Fase 3 : Creazione del certificato RA ............................................................................................ 19
Inizializzazione di RA .................................................................................................................... 19
Certificati utenti ............................................................................................................................. 19
Sottomissione di una richiesta di certificato .............................................................................. 19
Approvazione del certificato ...................................................................................................... 20
Il certificato ................................................................................................................................ 20
Ottenere il certificato ................................................................................................................. 20
Ottenere il certificato root .......................................................................................................... 20
Manuale d'uso .................................................................................................................................... 21
Utente ............................................................................................................................................. 21
Amministratore .............................................................................................................................. 25
Tuning ................................................................................................................................................ 29
Servizi Richiesti ............................................................................................................................. 29
Richieste effettuate ......................................................................................................................... 29
Richieste ricevute ........................................................................................................................... 29
Prima commessa ................................................................................................................................ 30
Studio di fattibilità su LDAP: Panoramica sulla situazione attuale ............................................... 30
Progetto della soluzione ................................................................................................................. 30
Funzionamento di LDAP ............................................................................................................... 31
Specifiche generali del sistema .................................................................................................. 31
Modalità di realizzazione ........................................................................................................... 32
Analisi costi benefici ...................................................................................................................... 36
Autenticazione con LDAP usando openLDAP e PAM (Pluggable Authentication Module) ....... 36
Aggiungere informazioni utente al database LDAP .................................................................. 37
Settare i moduli PAM ................................................................................................................ 38
Settare le librerie nsswitch ......................................................................................................... 39
Settare nss_ldap.......................................................................................................................... 39
Architettura del server LDAP .................................................................................................... 41
Apache basato su server WebDAV con LDAP ............................................................................ 42
2
Installazione ............................................................................................................................... 42
Configurare e settare WebDAV services ................................................................................... 45
Creare una directory per DAVLockDB ................................................................................... 45
Usare DAV ................................................................................................................................. 45
Creare una Directory chiamata DAVtest .................................................................................. 46
Gestione del server WebDAV.................................................................................................... 47
Limitare l’accesso alle condivisioni DAV ................................................................................. 47
Limitare l’accesso basato su UID .............................................................................................. 47
Appendice A: come richiedere e installare certificati WebServer ..................................................... 49
Certificati per server Apache ......................................................................................................... 49
Compilazione di mod_ssl ........................................................................................................... 49
Creazione e installazione certificato .......................................................................................... 50
Configurazione avanzata di mod_ssl - Server Level Configuration .......................................... 52
Configurazione avanzata di mod_ssl - Per Directory configuration .......................................... 54
SSL e VirtualHost ...................................................................................................................... 55
Evitare la rinegoziazione di protocollo fra server https e client ................................................ 55
Certificati per applicazioni Java ..................................................................................................... 56
3
Certification authority
In crittografia, una Certificate Authority o Certification authority (in breve CA) è una entità che
rilascia certificati digitali verso terze parti. Le Certification authority sono caratteristiche di una
infrastruttura PKI.
Le CA come soluzione per il problema dell'associazione fra una chiave pubblica e la persona che
possiede la relativa chiave privata; chiariamo il concetto con un esempio: Alice e Bob vogliono
scambiarsi messaggi firmati e crittografati; a tale scopo entrambi creano la loro coppia di chiavi e le
pubblicano su un keyserver. Quindi Alice scrive un messaggio per Bob, lo firma con la sua chiave
privata (di Alice) e lo cripta con la chiave pubblica di Bob, quindi il messaggio viene inviato. In
ricezione Bob decripta il messaggio con la sua chiave privata (di Bob) e verifica la firma con la
chiave pubblica intestata ad Alice.
Bob a questo punto Bob sa due cose:
il messaggio era diretto a lui perché è riuscito a decifrarlo con la sua chiave privata
il messaggio è stato firmato con la chiave privata relativa alla chiave pubblica che lui ha
usato per verificare la firma.
Notiamo che Bob non ha alcuna garanzia che la chiave sia realmente di proprietà di Alice.
Continuando l'esempio, supponiamo che una terza persona, Mallory, riesca ad intercettare la
comunicazione in cui Bob ottiene la chiave di Alice e riesca a sostituirla con la sua (di Mallory)
chiave pubblica in cui si spaccia per Alice. Bob non ha alcun modo per scoprire l'inganno.
Per risolvere situazioni di questo tipo nascono le CA che si fanno carico di verificare e garantire la
corrispondenza fra chiave e proprietario. Quando un utente richiede un certificato, la CA verifica la
sua identità, quindi crea un documento elettronico in cui sono contenuti:
i dati personali dell'utente
la chiave pubblica dell'utente
gli estremi della CA che ha rilasciato il certificato
gli indirizzi a cui può essere trovata la CRL.
Il documento viene firmato con la chiave pubblica della CA e pubblicato. Nell'esempio precedente
supponiamo che Alice e Bob si facciano firmare le loro chiavi da una CA che entrambi ritengono
attendibile. In questo caso l'attacco di Mallory non è più possibile in quanto non è in grado di
riprodurre la firma della CA.
Le Certification Authority commerciali sono sottoposte ad una rigida regolamentazione e
supervisione da parte dello Stato proprio a causa della sensibilità dei dati personali che gestiscono.
Le CA sono delle organizzazioni molto importanti nel panorama attuale del web; in genere tutti i
siti che si occupano di e-commerce o di transazioni on-line, perlomeno all'atto dell'autenticazione
dell'utente trasferiscono la comunicazione dal protocollo HTTP al protocollo HTTPS; all'atto della
negoziazione il client richiede il certificato del server e quindi viene instaurata la connessione
protetta. Quando un browser (ma anche un client di posta, ecc...) riceve un certificato, lo valida: Nel
processo di validazione verifica che tutto l'albero delle CA collegate al certificato sia fidato; un
certificato può non essere attendibile per diversi motivi, tra cui:
4
1. Il nome a cui è intestato il certificato non corrisponde al nome di chi lo ha presentato ( p.e. il
dominio www.miodomino.com deve presentare un certificato che sia intestato a
www.miodominio.com).
2. la data corrente non appartiene all'intervallo di validità del certificato.
3. Non tutte le CA che sono state coinvolte nel rilascio del certificato sono considerate
attendibili.
In genere i browser o i sistemi operativi contengono un elenco delle CA di primo livello e di livello
intermedio che sono ritenute attendibili e quindi sì "fidano" di quelle CA. Se tutte le CA coinvolte
nel rilascio del certificato in esame sono fidate, il certificato è ritenuto valido altrimenti viene
chiesto all'utente cosa fare, ossia se accettarlo o meno. Il problema di fidarsi o meno del certificato e
quindi dell'entità che lo ha presentato viene passato all'utente. Per cui il problema della fiducia
rimane a completo carico dell'utente. È automatico, quindi, che i siti o le infrastrutture utilizzino
certificati da CA molto famose e note per la loro affidabilità.
5
Doveri del gioco
Doveri di una CA
Considerando che la RA ha il compito di fornire, in quanto Autorità di Registrazione,
l’autenticazione dell’identità del soggetto, la convalida della corrispondenza tra una chiave pubblica
e l’identità del richiedente, la conferma di tale convalida nei confronti della CA, si è deciso, in
seguito alla visione dei dovuti documenti, di far rivestire tali compiti alla CA stessa; per cui i
principali doveri di una CA sono:
autenticare l’identità del soggetto;
convalidare la corrispondenza tra una chiave pubblica e l’identità del richiedente, attraverso
un metodo di verifica opportuno;
gestire le richieste di certificazione e l’emissione di nuovi certificati;
accettare e confermare le richieste di certificazione da parte di entità richiedenti un
certificato;
rilasciare certificati sulla base delle richieste autenticate;
rendere pubblicamente disponibili i certificati emessi;
occuparsi delle richieste di revoca dei certificati e della revoca degli stessi;
accettare e confermare le richieste di revoca da parte di entità richiedenti;
rendere le CRL pubblicamente disponibili.
Servizi offerti
Registrazione: questo è il processo attraverso il quale il richiedente si presenta alla CA, per
cercare di ottenere un certificato; durante la procedura viene richiesto al soggetto di fornire i
propri attributi, come il nome, l’indirizzo e-mail, il numero di telefono ed altre informazioni,
seguendo le specifiche CPS (Certification Practices Statement) della CA; quindi la CA
segue le linee guida specificate nel CPS, per verificare che i dettagli forniti dal soggetto
siano corretti, prima di emettere il certificato;
Certificazione: è il processo attraverso il quale la CA emette un certificato che contiene la
chiave pubblica del soggetto, lo pubblica in un repository pubblico ed accessibile a tutti
permettendo di scaricarlo;
Revoca o annullamento: nella maggior parte dei casi, un certificato rimane valido fino a
quando non viene raggiunta la data di scadenza. Ci sono, comunque, un certo numero di
situazioni in cui è necessaria una revoca prematura del certificato, ad esempio:
o il soggetto ha cambiato nome;
o un impiegato lascia la compagnia che ha emesso il certificato;
o si è verificata una compromissione (o una sospetta compromissione) della chiave
privata.
Il metodo stabilito per la revoca dei certificati include l’uso di una Certificate Revocation List
(CRL), che raccoglie i certificati revocati (normalmente ogni certificato è identificato da un numero
seriale unico, assegnato nel momento dell’emissione) ed è firmata, con tanto di data, dalla CA; la
CA pubblica la CRL ad intervalli regolari, nello stesso repository pubblico. Un certificato la cui
corrispondente chiave privata sia stata compromessa deve essere revocato il più presto possibile,
subito dopo che la compromissione è stata scoperta; altrimenti, se la CRL non venisse pubblicata
per molti giorni, dopo la revoca del certificato, gli utenti non sarebbero a conoscenza del problema e
6
potrebbero accettare messaggi firmati da un intruso con la chiave privata rubata; comunque, anche
se la CRL fosse pubblicata immediatamente dopo la revoca, non ci sarebbe garanzia che gli utenti
ne vengano a conoscenza in tempo. Una CRL permette ai clienti ed ai server di controllare se
l’entità con cui stanno dialogando possiede un certificato valido. Il CRL è un file binario che
contiene le seguenti informazioni:
lista di certificati revocati e ragione della revoca;
emissario della CRL;
data di emissione della CRL;
data di pubblicazione della prossima versione della CRL.
È importante specificare che quando la CA, che aveva originariamente emesso il certificato, lo
revoca, firma digitalmente la CRL: in questo modo, l’utente finale che controlla la CRL può essere
sicuro dell’attendibilità delle informazioni che la CRL contiene. Si accede ad una CRL quando si ha
bisogno di usare un certificato contenente una chiave pubblica per crittografare dati da inviare ad un
particolare destinatario, o per verificare la firma digitale presente in un messaggio ricevuto. Quando
si ha una qualsiasi di queste due necessità, si eseguono le seguenti operazioni:
si ottiene il certificato digitale richiesto;
si ottiene il numero seriale del certificato;
si ottiene la CRL (si accede al proprio repository locale di CRL);
si controlla la firma digitale della CRL, la data di pubblicazione e la data di prossima
pubblicazione;
si controlla la CRL per determinare se il certificato che si intende usare è stato revocato o
sospeso (basandosi sul numero seriale del certificato).
Doveri del sottoscrittore
Un utente deve comportarsi nel rispetto della Certification Practice Statements (CPS) della CA
addetta al rilascio di certificati. Tale accordo prevede:
lettura e rispetto delle procedure concordate;
opportuna custodia della propria chiave privata, in quanto unico possessore, nel caso in cui
la sottoscrizione si riferisca a un singolo utente. Nel caso, invece, di una chiave privata
rilasciata per un componente hardware o software, la custodia ed il controllo della chiave
possono essere affidati alla responsabilità di più di una persona autorizzata;
autorizzazione al trattamento ed alla conservazione dei dati personali;
immediata notifica alla CA in caso di compromissione della chiave privata.
Doveri di terze parti coinvolte
Una parte coinvolta deve venire a conoscenza della CPS e della policy utilizzata, prima di trarre
alcuna conclusione sulla fiducia da riporre nell’utilizzo di un certificato emesso da una CA
conforme. Essa, inoltre, deve controllare le CRL, al momento di convalidare l’utilizzo dello stesso
certificato.
7
Certificati digitali
Un certificato digitale è un documento elettronico che associa l'identità di una persona ad una
chiave pubblica. Viene emesso da una autorità di certificazione riconosciuta secondo standard
internazionali (X.509) e viene firmato con la chiave privata dell'autorità. Gli enti che fanno da
autorità devono sottostare a regole rigidissime per quanto riguarda la gestione dei dati personali,
pertanto si possono considerare sicuri.
I certificati garantiscono la tutela delle informazioni personali su Internet e consentono di
proteggere il sistema da programmi software non sicuri. Un certificato è un attestato che consente di
verificare l'identità di una persona o la protezione di un sito Web.
X.509
In crittografia, X.509 è uno standard ITU-T per le infrastrutture a chiave pubblica (PKI). X.509
definisce, fra le altre cose, formati standard per i certificati a chiave pubblica ed un certification
path validation algorithm.
Storia
X.509 venne presentato per la prima volta nel 1988 e il suo sviluppo cominciò insieme allo standard
X.500. La prima versione presupponeva uno stretto sistema di gerarchie di certificate authority
(CA) per presentare e garantire un certificato, in contrasto con il modello della rete di fiducia (web
of trust), utilizzato da PGP, dove chiunque (non solo CA particolari) può firmare e quindi attestare
(certificare) la validità delle chiavi altrui.
La Versione 3 di X.509 include flessibilità tipiche di altre tipologie di reti e filtri: può essere
utilizzato in una rete di fiducia peer-to-peer come quella di OpenPGP, anche se raramente è
implementata in questo modo. Il sistema X.500 non è mai stato totalmente implementato, e l'IETF
ed i public-key infrastructure working group hanno adattato lo standard con una struttura più
flessibile adatta ad internet. Infatti il termine certificato X.509 si riferisca generalmente al profilo di
certificato PKI e di revoca del certificato (CRL) dell'IETF dello standard X.509 v3, come descritto
nella RFC 3280.
Certificati X.509
Nel sistema X.509, una CA rilascia un certificato che accoppia una chiave pubblica ad un Nome
Distintivo(Distinguished Name) seguendo la tradizione del X.500, oppure ad un Nome
Alternativo(Alternative Name) come potrebbe essere un indirizzo e-mail o un record DNS.
Un root certificate fidato di un'azienda può essere distribuito a tutti i dipendenti, per far si che
possano usare la PKI aziendale. Browser come Internet Explorer, Netscape/Mozilla ed Opera
vengono distribuiti con alcuni root certificate preinstallati, rendendo possibile il funzionamento dei
certificati SSL di alcuni grossi distributori che hanno pagato per questo servizio; in pratica chi
sviluppa il browser determina quali CA sono terze parti fidate. Nonostante questi root certificate
possano essere eliminati o disabilitati, raramente gli utenti lo fanno.
X.509 include anche gli standard per le implementazioni di certificate revocation list (CRL, liste di
revoca di certificati), un aspetto spesso sottovalutato dei sistemi PKI. La modalità di controllo della
validità di un certificato approvata dall'IETF si chiama Online Certificate Status Protocol (OCSP).
8
Struttura del certificato
La struttura di un certificato digitale X.509 v3 è la seguente:
Certificato
o Versione
o Numero seriale
o ID dell'algoritmo
o Ente emettitore
o Validità
Non prima
Non dopo
o Soggetto
o Informazioni sulla chiave pubblica del soggetto
Algoritmo per l'utilizzo della chiave pubblica
Chiave pubblica
o Codice identificativo univoco dell'emittente (facoltativo)
o Codice identificativo univoco del soggetto (facoltativo)
o Estensioni (facoltativo)
Algoritmo di firma del certificato
Firma del certificato
I codici identificativi univoci dell'emettitore e del soggetto sono stati introdotti nella versione 2, le
"Estensioni" nella versione 3.
Estensioni comuni per i file contenenti i certificati X.509:
.CER - certificato codificato con DER, a volte sequenze di certificati;
.DER - certificato codificato con DER;
.PEM - certificato codificato con Base64, racchiuso tra "-----BEGIN CERTIFICATE-----" e
"-----END CERTIFICATE-----";
.P7B .P7C - struttura SignedData PKCS#7 senza dati, solo il/i certificato/i o la/le CRL (Certificate
revocation list);
.PFX - vedi .p12
.P12 - PKCS#12, può contenere certificati e chiavi pubbliche e private (protette da
password);
PKCS #7 è uno standard per la firma o la crittazione (viene chiamata "imbustamento",
"incapsulazione", "enveloping" in inglese) dei dati. Poiché è necessario un certificato per verificare
i dati firmati, è possibile includerli in una struttura SignedData. Un file .P7C non è altro che una
struttura SignedData "degenere" (senza dati firmati).
PKCS #12 è nato dallo standard PFX (Personal inFormation eXchange) ed è usato per scambiarsi
oggetti pubblici e privati all'interno dello stesso file. Un file .PEM può contenere certificati o chiavi
private, racchiusi tra le apposite linee BEGIN/END.
9
Installazione
Primo step
I software installati sono:
Knoppix: sistema operativo;
OpenCA: software principale per la realizzazione della CA;
Firestarter: firewall usato per impedire accessi indesiderati;
Apache: nel toolkit OpenCA, Apache agisce da interfaccia, in locale, ai programmi di
supporto sull’host CA. Tale versione è stata scelta per motivi legati alla sicurezza.
mod_ssl: fornisce un’eccellente crittografia per il web server Apache tramite SSL e TLS,
servendosi del toolkit OpenSSL;
OpenSLL: toolkit crittografico che implementa SSL (acronimo di Secure Socket Layer) e
TLS (acronimo di Transport Layer Security) ed i relativi standard crittografici da essi
richiesti. OpenSSL consente l’autenticazione alle applicazioni client-server (tramite
crittografia a chiave pubblica); garantisce la riservatezza della comunicazione; cifra i dati
prima di inviarli su canale pubblico (tramite crittografia a chiave simmetrica), fornisce
l’integrità dell’informazione e la possibilità di negoziazione della cipher_suite fra client e
server, oltre alla gestione dei certificati digitali x509;
OpenLDAP: server utilizzato per la pubblicazione dei certificati;
Perl: fornisce un’interfaccia al database MYSQL, si presta bene a sviluppare applicazioni
web perché può gestire dati cifrati, incluse le transazioni di commercio elettronico sicuro;
MySQL: usato come Data Base Management System.
Sendmail: usato per inviare mediante e-mail, all’atto della generazione del certificato, il
CRIN (codice per la revoca del certificato) al richiedente del certificato.
Per motivi di licenze sono stati utilizzati esclusivamente prodotti software freeware; ciò ha
facilitato non solo il reperimento del software ma anche l’utilizzo, essendo tali prodotti
utilizzati da gran parte della comunità telematica, che dissemina attraverso forum e siti web
notevoli informazioni sulle installazioni, sui conflitti, sulla risoluzione di problemi di
qualsiasi
tipo.
La nostra scelta è ricaduta sul software Dartmouth OpenCa-LiveCD, il quale tramite pochi e
semplici passaggi permette di installare tutto il software necessario per un Certification
Authority, in modo tale da rendere il sistema veloce e leggero all'avvio.
Dartmouth OpenCa-LiveCD è un CD bootable con uno script di installazione che aiuta le
persone ad avere una Certification Authority OpenCA pronta per essere installata in pochi
minuti. Questo CD può essere utilizzato sulla maggior parte delle architetture Intel
indipendente dal sistema operativo installato sul HDD. L'installazione non modificherà
alcun contenuto dell'HDD, a meno che non sia richiesto esplicitamente dall'installatore.
L'immagine del CD può essere scaricata da
http://media.dartmouth.edu/~deploypki/openca-livecd.iso
e la documentazione disponibile da
http://www.dartmouth.edu/~deploypki/CA/OpenCA-LiveCD.html
10
Sequenza di installazione
1.
2.
3.
4.
5.
Scaricare il file ISO dal link precedente
Masterizzare l'immagine del CD
Modificare il boot di avvio dal bios in modo da priorizzare il CD-ROM
Inserire il CD nel driver e riavviare il PC
A questo punto partirà uno script di configurazione automaticamente che permette di
personalizzare la propria CA
Secondo step
Dopo aver concluso la fase di setup, quella di tuning e dopo aver quasi concluso la prima commessa
il 10 di ottobre del 2006, sul sito www.openca.org è stata presentata una nuova release la 0.9.3rc1
che risolveva numerosissimi problemi riscontrati nell'utilizzo della precedente versione. Per questo
motivo si è scelto di re-installare tutto da capo svolgendo per la seconda volta la fare di setup e
quella di tuning.
Questa volta i software installati sono cambiati:
Suse Linux 10.1: sistema operativo;
OpenCA: software principale per la realizzazione della CA;
SuseFirewall: firewall usato per impedire accessi indesiderati;
Apache2: Apache agisce da interfaccia, in locale, ai programmi di supporto sull’host CA RA
e loro connessi. Tale versione è stata scelta per motivi legati alla sicurezza.
mod_ssl: fornisce un’eccellente crittografia per il web server Apache tramite SSL e TLS,
servendosi del toolkit OpenSSL;
OpenSLL: toolkit crittografico che implementa SSL (acronimo di Secure Socket Layer) e
TLS (acronimo di Transport Layer Security) ed i relativi standard crittografici da essi
richiesti. OpenSSL consente l’autenticazione alle applicazioni client-server (tramite
crittografia a chiave pubblica); garantisce la riservatezza della comunicazione; cifra i dati
prima di inviarli su canale pubblico (tramite crittografia a chiave simmetrica), fornisce
l’integrità dell’informazione e la possibilità di negoziazione della cipher_suite fra client e
server, oltre alla gestione dei certificati digitali x509;
OpenLDAP: server utilizzato per la pubblicazione dei certificati;
Perl: fornisce un’interfaccia al database PostgreSQL, si presta bene a sviluppare applicazioni
web perché può gestire dati cifrati, incluse le transazioni di commercio elettronico sicuro;
PostgreSQL: usato come Data Base Management System; questa volta abbiamo scelto di
utilizzare questo tipo di DBMS in quanto si è rilevato essere più robusto.
Sendmail: usato per inviare mediante e-mail, all’atto della generazione del certificato, il
CRIN (codice per la revoca del certificato) al richiedente del certificato.
moduli Perl: per la comunicazione tra PostgreSQL e OpenCA.
Sequenza di installazione
Tralascio al riguardo l'installazione di tutti i software necessari e mi soffermo in prevalenza
sull'installazione di OpenCA.
11
Prima di tutto serve scaricare l'ultima release di OpenCA dal sito www.openca.org (nel nostro caso
il file openca-0.9.3-rc1.tar.gz).
Scompattare il file con il comando: tar xvf openca-0.9.2-RC4.tar
posizionarsi nella directory scompattata e impartire questo comando: make distclean che
permette di ripulire tutte le configurazioni preimpostate.
A questo punto cominciamo col settare le configurazioni per la sezione Registration
Authority con
./configure --with-prefix=/usr/local/OpenRA --with-web-host=www.ca.org --with-httpduser=ca --with-httpd-group=users --with-ca-organization="CaGroup" --with-calocality=Salerno --with-ca-country=IT [email protected] --withhierarchy-level=ra --with-module prefix=/usr/local/OpenRA/modules --with-opensslprefix=/etc/ssl --with-hhtpd-fs-prefix=/etc/apache2 --with-language=it_IT --disable-rbac -enable-ocspd --with-openca-prefix=/usr/local/OpenRA/OpenCA --with-etcprefix=/usr/local/OpenRA/OpenRA/etc --with-httpd-fs-prefix=/usr/local/OpenRA/httpd -with-node-prefix=ra-node
Ora analiziamo in dettaglio tutti i comandi:
--with-prefix=/usr/local/OpenRA: designa la directory di installazione
--with-web-host=www.ca.org : setta l'url del sito
--with-httpd-user=ca: setta l'utente apache
--with-httpd-group=users: setta il gruppo dell'utente apache
--with-ca-organization="CaGroup" : setta l'organizzazione
--with-ca-locality=Salerno : setta la località in cui si trova la RA
--with-ca-country=IT : setta lo stato
[email protected] setta la mail dalla quale inviare e alla quale è
possibile inviare mail
--with-hierarchy-level=ra setta la gerarchia
--with-module-prefix=/usr/local/OpenRA/modules setta la directory di destinazione dei
moduli
--with-openssl-prefix=/etc/ssl setta la directory dove si trova openssl
--with-hhtpd-fs-prefix=/etc/apache2 setta la directory dove si trova Apache
--with-language=it_IT setta la lingua di default
--disable-rbac disabilita il modulo rbac
--enable-ocspd abilita il modulo ocspd
--with-openca-prefix=/usr/local/OpenRA/OpenCA setta la directory di destinazione della
CA per la RA
--with-etc-prefix=/usr/local/OpenRA/OpenRA/etc setta la directory etc per la RA
--with-httpd-fs-prefix=/usr/local/OpenRA/httpd setta la directory di destinazione dei file per
il sito
--with-node-prefix=ra-node setta il nodo RA
Una volta fatto questo imparitre i comandi
make per compilare il tutto
make install-online per installare
Alla fine di tutto impartire il comando make distclean per ripulire dai settaggi e rfare lo stesso per il
modulo CA. Quello che cambia sono solo i comandi
12
--with-prefix=/usr/local/OpenCA per indicare la directory della CA
--with-hierarchy-level=ca per impartire la nuova gerarchia
--with-module-prefix=/usr/local/OpenCA/modulesper specificare la directory di insallazione
dei moduli
--with-openca-prefix=/usr/local/OpenCA/OpenCA per specificare la directory della CA
--with-etc-prefix=/usr/local/OpenCA/OpenCA/etc per specificare la directory etc per la CA
--with-httpd-fs-prefix=/usr/local/OpenCA/httpd per specificare la directory del sito per la
CA
--with-node-prefix=ca-node per specificare il nodo ca
A questo punto impartire i comandi
make per compilare
make install-offline per installare tutti i moduli per la CA
Ora bisogna settare tutti i parametri per il database postgreSQL
createuser openca per creare l'utente openca che accederà ad DB. A questo utente bisogna
dare tutti i permessi sia di creazione che di modifica delle tabelle e db
createdb openca per creare il database openca nel quale sarenno salvati tutti i dati della CA
psql openca. Per accedere al DB openca
grant all privileges on database openca to openca per garantire all'utente openca tutti i
permessi di accesso al database openca
Una volta completata questa fase
bisogna settare dei parametri per Apache in modo tale da indicargli le nuove directory e per fare ciò
bisogna modificare il file HTTP.conf che si trova nella directory di apache (nel nostro caso
/etc/apache2). Aprire il file e inserire questi comandi
# OpenCA Mods
# CA Aliases
Alias /ca /usr/local/openca/httpd/htdocs/ca/
Alias /ca-node /usr/local/openca/httpd/htdocs/ca-node/
ScriptAlias /cgi-bin/ca/ /usr/local/openca/httpd/cgi-bin/ca/
ScriptAlias /cgi-bin/ca-node/ /usr/local/openca/httpd/cgi-bin/ca-node/
# OpenCA Mods
# RA Aliases
Alias /ra /usr/local/openra/httpd/htdocs/ra/
Alias /pub /usr/local/openra/httpd/htdocs/pub/
Alias /ra-node /usr/local/openra/httpd/htdocs/ra-node/
ScriptAlias /cgi-bin/ra/ /usr/local/openra/httpd/cgi-bin/ra/
ScriptAlias /cgi-bin/pub/ /usr/local/openra/httpd/cgi-bin/pub/
ScriptAlias /cgi-bin/ra-node/ /usr/local/openra/httpd/cgi-bin/ra-node/
# OpenCA Mods
<Directory "/usr/local/openca/httpd/cgi-bin/">
AllowOverride None
Options ExecCGI
Order allow,deny
13
Allow from all
</Directory>
<Directory "/usr/local/openra/httpd/cgi-bin/">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
<Directory "/usr/local/openca/httpd/htdocs/">
AllowOverride None
Options FollowSymLinks Indexes
Order allow,deny
Allow from all
</Directory>
<Directory "/usr/local/openra/httpd/htdocs/">
AllowOverride None
Options FollowSymLinks Indexes
Order allow,deny
Allow from all
</Directory>
# OpenCA Mods
<Directory "/usr/local/openra/httpd/cgi-bin/pub">
AllowOverride None
Options FollowSymLinks Indexes
Order allow,deny
Allow from all
</Directory>
Questi comandi impartiscono degli alias per indicare dove si trovano le directory sull'hard-disk e
che alcune directory contengono dei file script da dover interpretare im maniera differente da quelli
html. Infine sono stati settati i permessi per l'accesso alle directory varie.
A questo punto bisogna configurare il file config.xml che si trova sia in
/usr/local/OpenCA/OpenCA/etc che in /usr/local/OpenRA/OpenRA/etc. Le modifiche da apportare
sono legate ai parametri di configurazione del DataBase e dello scambio di dati fra CA e RA.
#general options
ca_organization
ca_locality
ca_country
service_mail_account (mattere la email)
dbmodule -> DBI per PostgreSQL database
db_type-> postgre
db_name -> openca
db_host -> localhost
db_port -> la porta che si è settato
db_user -> openca
14
db_passwd -> XXX
<name>dataexchange_device_up</name>
<value>/usr/local/openca/openca/var/tmp/ca-up</value>
</option>
<option>
<name>dataexchange_device_down</name>
<value>/usr/local/openca/openca/var/tmp/ca-down</value>
</option>
<option>
<name>dataexchange_device_local</name>
<value>/usr/local/openra/openca/var/tmp/ra-local</value>
Dopo aver fatto tutto questo basta lanciare lo script configure_etc.sh il quale configurerà la nostra
CA e RA su come abbiamo settato il file config.xml.
Configurazione SendMail
Ora bisogna settare SendMail per permettergli di mandare le e-mail. Per prima cosa bisogna creare
un file: /usr/sbin/sendmail-cf/cf/config.mc contenente:
# start of config.mc
include(`../m4/cf.m4')dnl
OSTYPE(`linux')dnl
define(`SMTP_MAILER_FLAGS', `e9')dnl
FEATURE(redirect)dnl
FEATURE(nocanonify)dnl
FEATURE(always_add_domain)dnl
FEATURE(local_procmail)dnl
GENERICS_DOMAIN(localhost.localdomain localhost localhost)
FEATURE(genericstable)
FEATURE(masquerade_envelope)dnl
define(`confCF_VERSION',`dede's cf - 22/05/98')dnl
define(`confCON_EXPENSIVE',`True')dnl
define(`confME_TOO',`True')dnl
define(`confCOPY_ERRORS_TO',`Postmaster')dnl
define(`confDEF_CHAR_SET',`ISO-8859-1')dnl
define(`confMIME_FORMAT_ERRORS',`True')dnl
define(`SMART_HOST',`smtp8:[out.isp2.org]')dnl
define(`confTO_QUEUEWARN',`24h')
MAILER(local)
MAILER(smtp)
# End of config.mc
Create anche /etc/genericstable:
15
ca: [email protected]
root: [email protected]
news: [email protected]
Vericate che /etc/aliases contenga almeno:
MAILER-DAEMON: postmaster
postmaster: root
Modificate o create /etc/nsswitch.conf come segue:
passwd: files
shadow: files
group: files
hosts: files dns
services: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
netgroup:
publickey:
automount: files
aliases: files
Generate /etc/sendmail.cf con:
m4 config.mc > /etc/sendmail.cf
e impostatene i permessi come segue:
-rw------- 1 root root 26468 mai 12 22:52 /etc/sendmail.cf
Generate il database di conversione degli indirizzi:
/usr/bin/sendmail -bi -oA/etc/genericstable
Dovrebbe essere stato creato il file /etc/genericstable.db.
Rileggete la tabella degli alias:
newaliases
Il file /etc/hosts dovrebbe contenere una linea simile a:
127.0.0.1 localhost.localdomain localhost localhost
riavviate sendmail:
16
kill `head -1 /var/run/sendmail.pid`
/usr/bin/sendmail -bd -os
Creazione di uno script per l’avvio dei servizi
A questo punto è stato creato uno script che permette l’avvio automatico di OpenCA lato
Certification Authority e lato Registration Authority.
#! /bin/sh
#
#
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
NAME=openca
DESC="OpenCA"
set -e
case "$1" in
start)
echo -n "Starting $DESC for CA: "
cd /usr/local/OpenCA/OpenCA/etc
openca_start
echo "DONE"
echo -n "Starting $DESC for RA: "
cd /usr/local/OpenRA/OpenRA/etc
openca_start
echo "DONE"
;;
stop)
echo -n "Stopping $DESC for CA: "
cd /usr/local/OpenCA/OpenCA/etc
openca_stop
echo "DONE"
echo -n "Stopping $DESC for RA: "
cd /usr/local/OpenRA/OpenRA/etc
openca_stop
echo DONE"
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop}" >&2
exit 1
;;
esac
exit 0
Tale script poi è stato posizionato nella directory /etc/init.d per permettere poi la modifica del run
level 5 così da avviare i servizi automaticamente.
17
Configurazione di OpenCA
1. Connettiti alla ca http://localhost/ca/ , saranno visibili una serie di tabs. Seleziona il tab
Generale e l’oggetto Initialization all’interno. Viene visualizzata la pagina "OpenCA Init"
con una serie di link organizzati in tre fasi:
Fase 1 : Inizializzazione della Certification Authority
2. Clicca su Initialize the Certification Authority. Viene visualizzata la pagina "Init
Certification Authority"
3. Clicca su Initialize Database. Ritorna alla pagina "Init Certification Authority" usando il
bottone Back
4. Clicca su Generate new CA secret key. Questo link conduce alla pagina "Get Additional
Parameters".
I valori di default sono:
a. Encryption algorithm (des,des3,idea):des3
b. Asymmetric algorithm (rsa, dsa):rsa
c. CA key size (in bits):4096
Clicca su OK
5. Inserisci la password CA Certificate Private Key nella pagina di login di CA. Questa
password proteggerà CA private key e deve essere inserita per lavorare con CA. Dopo aver
inserito la password clicca su OK. Il server crearà un paio di chiavi basate sui parametri che
hai inserito; questa operazione può richiedere alcuni minuti. Quando la generazione della
chiave è completata, uno screen mostrerà la chiave. Clicca su OK. Ritorna alla pagina "Init
Certification Authority".
6. Clicca su Generate new CA Certificate Request . Riempi i campi con i parametri necessari
per l’installazione. Clicca OK e conferma il DN generato dai parametri Si indicherà di
inserire le credenziali, cioè la private key password generata nel passo precedente. Ritorna
alla pagina "Init Certification Authority"
7. Clicca su Generate new CA Certificate Request . Riempi i campi con i parametri necessari
per l’installazione. Clicca OK e conferma il DN generato dai parametri Si indicherà di
inserire le credenziali, cioè la private key password generata nel passo precedente. Ritorna
alla pagina "Init Certification Authority"
8. Clicca su Self Signed CA Certificate. Si indicherà di inserire il periodo valido per la CA, e
di confermare le credenziali (private key password). Ritorna a "Init Certification Authority"
9. Clicca su Rebuild CA Chain. Dovresti avere una risposta di conferma.
10. Clicca su Export Configuration.
11. Clicca su OK.
Fase 2 : Creazione dell’amministratore
11. Clicca su Create the initial CA certificate. Questo link conduce alla pagina "Init First User".
Viene creato un certificato (e una coppia di chiavi) per identificare il CA Administrator
12. Clicca su Create a new request. Compila i dati utente/certificato come desideri. Il ruolo
dovrebbe essere "CA Operator"..Il PIN sarà usato per proteggere la chiave privata del
certificato sul server. Dai la conferma. Ritorna alla pagina "Init First User".
13. Clicca su Edit the request. Clicca su "Submit the changed request". Clicca su "Issue
Certificate". Si indicherà di confermare le credenziali. Ritorna alla pagina "Init First User"
18
14. Clicca su Handle the request.. Seleziona "Certificate and Keypair" come p12 nella sezione
"Operations"e clicca su "Download". Si indicherà la password per la chiave privata per
questo certificato, che era stata generata come il PIN sopra. p12 sarà salvato e può essere
importato nel browser per usarlo dopo.
Fase 3 : Creazione del certificato RA
15. Clicca su Create the initial RA certificate. Questo link conduce alla pagina "Init First User".
Questo passo permette di creare un certificato (e una coppia di chiavi) per identificare
l’amministratore RA
16. Clicca su Create a new request. Riempi i dati utente / certificato come desideri. Il ruolo
dovrebbere essere "RA Operator". Il PIN sarà usato per proteggere la chiave privata del
certificato sul server. Dai la conferma. Non c’è bisogno di stampare le informazioni. Ritorna
alla pagina "Init First User"
17. Clicca su Edit the request. Clicca su "Submit the changed request" e poi su "Issue Certificate
e conferma. Ritorna alla pagina "Init First User".
18. Clicca su Handle the request.. Seleziona "Certificate and Keypair" come p12 nella sezione
"Operations"e clicca su "Download".Si indicherà la password per la chiave privata per
questo certificato, che era generata come il PIN. p12 sarà salvato e può essere importato nel
browser per usarlo dopo.
Inizializzazione di RA
19. Connettiti a : http://localhost/ra-node/. Saranno visibili una serie di tabs. Seleziona
Administration e l’oggetto Server Init all’interno. Sarà visibile la pagina "Init New Node"
con due link.
20. clicca su Import Configuration in "PKI Setup". Questo passaggio consente di rendere il
certificato CA disponibile a RA e utenti pubblici
Certificati utenti
Sottomissione di una richiesta di certificato
L’OpenCA, per come l'abbiamo settato risponderà all'indirizzo www.ca.org. Se questa operazione
fallisce occorre farlo attraverso l’indirizzo IP, digitando il comando ifconfig nella shell dei
comandi.
1. Connetti a www.ca.org/pub
2. Seleziona il tab User e l’oggetto Request a Certificate. Si visualizza la pagina "Basic
Certificate Request"
3. Clicca su Request a certificate with automatic browserdetection. Appare la pagina "Basic
Certificate Request"
4. Compila la pagina "Basic Certificate Request", selezionando il ruolo "User". Clicca su
"Continue". Conferma la richiesta. La keysize deve essere riselezionata.. Cosa accade dopo
dipende dal browser. Mozilla chiede di confermare la keysize e di inserire la master keystore
password, che è la password che protegge la chiave private dell’utente. IE chiederà di
selezionare il sistema di crittografia, possibilmente passando attraverso alcune decisioni che
riguardano la chiave. Prendi nota del numero seriale della richiesta, lo userai per recuperare
il certificato.
19
Approvazione del certificato
Tutti questi passi devono essere eseguiti dalla console.
1. Connettiti alla ra http://localhost/ra/. Seleziona il tab Active CSRs e il nuovo item dentro di
esso. Viene visualizzata una pagina di ricerca. Se non hai bisogno di modificare i livelli di
sicurezza, puoi usare i parametri di ricerca di default. Clicca su "Search".
2. Dovrebbe comparire una lista di richieste. Clicca sul numero seriale della richiesta che
vorresti effettuare.
3. Conferma che la richiesta che appare è quella che desideri e clicca su "Approve Without
Signing”.
Il certificato
1. Connettiti a http://localhost/ca/. Seleziona Usual Operations e Approved Certificate
Requests.
2. Sono visualizzate una lista di richieste. Clicca sul numero seriale della richiesta che desideri.
3. Conferma che la richiesta che appare è quella che desideri e clicca su "Issue the Certificate".
Conferma la richiesta con la private key password.
Ottenere il certificato
1. Connettiti a www.ca.org/pub
2. Seleziona il tab User e l’oggetto Get Requested Certificate. Inserisci il numero seriale e
seleziona "Request's Serial" dal box di selezione "Type of Serial".
Clicca su OK.
3. Conferma che il certificato è presente :
con Mozilla digita (Edit->Preferences->Privacy and Security->Certificates->Manage
Certificates)
con Windows digita (Tools->Internet Options->Content->Certificates->)
Ottenere il certificato root
1. Connettiti a www.ca.org/pub
2. Seleziona il tab CA Infos e l’oggetto Get CA Certificate.
3. Seleziona "CA-certificate in format CRT ". Con Mozilla / Netscape devono essere eseguiti i
seguenti passi:
confidare in questa CA per identificare siti web
confidare in questa CA per identificare emails di utenti
confidare in questa CA per identificare sviluppatori software
Clicca su OK.
Gli utenti di Internet Explorer su Windows devono seguire questi passi :
1. Sulla finestra di dialogo che appare clicca su "Open".
2. Clicca su 'Install Certificate...' nella finestra che appare.
3. accetta la Certificate Installation Wizard.
20
Manuale d'uso
Utente
L’utente si deve collegare al sito https://www.ca.org/; il browser visualizza la pagina mostrata in
Figura 1, con le tab GENERAL, CA Infos, User, Certificates, Requests, Language. In GENERAL
vengono visualizzati i diversi moduli installati con le rispettive versioni
Figura 1
Cliccando su CA Infos compaiono i seguenti link:
Policy;
Get CA Certificate: se cliccato, vengono visualizzati i link per scaricare il certificato della
CA nei formati desiderati (CRT, PEM, DER, CER, TXT);
Certificate Revocation Lists: se cliccato, compaiono i link per visualizzare la lista dei
certificati revocati nei diversi formati.
Cliccando su User compaiono i seguenti link:
Request a Certificate: cliccando su di esso, compaiono i link che consentono di richiedere un
certificato. Viene chiesto all’utente di compilare un form inserendo i propri dati e di
confermare la sottomissione. Dopo aver completato la richiesta, l’utente deve recarsi dalla
RA scelta (nel nostro caso dalla CA) per l’approvazione della richiesta;
Get Requested Certificate (scarica il certificato richiesto): cliccando su di esso, viene chiesto
all’utente di inserire il numero seriale del certificato per poterlo scaricare. Se il certificato è
21
stato generato dalla CA, l’utente può scaricarlo, altrimenti viene visualizzato un messaggio
di errore;
Test Certificate: cliccando su di esso, vengono riportati i dati principali del certificato
presentato dal browser;
Revoke Certificate: cliccando su di esso, viene visualizzato all’ utente un form richiedente il
numero seriale del certificato da revocare con il CRIN precedentemente ricevuto tramite email.
Figura 2
Cliccando su Request a certificate viene visualizzata una form nella quale inserire tutti i dati
22
Figura 3
Dopo aver compilato e sottomessa la form, viene visualizzata una schermata riassuntiva
Figura 4
23
Infine viene presentata la schermata conclusiva che da all'utente la possibilità di stampare tutti i
dati.
Figura 5
24
Amministratore
Per accedere alla sezione amministrativa di OpenCA l’amministratore si deve collegare al sito
"http://localhost ”; appare una schermata in cui viene richiesto l’inserimento di login e password.
Figura 6
Dopo la procedura di autenticazione appare la schermata generale dell’interfaccia CA in cui
vengono visualizzati i seguenti link: General, Usual Operations, Active CSRs, Active CRRs,
Information, Language, Initialization, Configuration, Node Mangement, Logout.
Cliccando su General vengono visualizzati modulo e versione dei software utilizzati e richiesti da
OpenCA. Cliccando su Usual Operation appaiono i seguenti link:
Approved Certificate Requests: cliccando su di esso, è possibile visualizzare la lista delle
richieste di certificazione approvate dalla CA; per ogni richiesta sono riportati diversi dati,
come il nome del richiedente ed il numero seriale della richiesta;
Approved Revocation Requests: cliccando su di esso, è possibile visualizzare la lista delle
richieste di revoca approvate dalla CA; per ogni richiesta sono riportati diversi dati, come il
nome del richiedente ed il numero seriale della richiesta;
Issue New CRL: cliccando su di esso, appare una schermata in cui viene richiesto di inserire
dei parametri addizionali per la funzionalità richiesta, cioè viene settato il periodo di validità
(in giorni) della CRL (Control Revocation List) e le eventuali estensioni;
Issue Certificates (Automaticly): attraverso questo link viene consentito di selezionare il tipo
di ruolo dell’operatore ed il ruolo richiesto per l’emissione del certificato e viene data la
possibilità di confermare i dati, inserendo la password, o di effettuarne il reset;
25
Revoke Certificates (Automaticly): attraverso questo link viene consentito di selezionare il
tipo di ruolo dell’operatore ed il ruolo richiesto per la revoca del certificato e viene data la
possibilità di confermare i dati, inserendo la password, o di effettuarne il reset.
Cliccando su Active CSRs appaiono, invece, i seguenti link:
New: cliccando su di esso, appare la lista delle nuove richieste di certificazione. Per ogni
richiesta vengono visualizzati il numero seriale della richiesta, i dati del richiedente, la data
della richiesta, il ruolo richiesto ed il livello di affidabilità richiesto;
Cliccando sul seriale della richiesta è possibile visualizzare tutte le informazioni relative alla
richiesta e l’amministratore può decidere di modificare la richiesta (Edit Request),
cancellare la richiesta (Delete Request), rilasciare il certificato (Issue Certificate).
Se l’amministratore clicca su Edit Request è possibile modificare la richiesta nei suoi singoli campi.
Se l’amministratore clicca su Issue Certificate viene richiesto di immettere la password della CA e,
dopo la sottomissione, viene rilasciato il certificato;
Renewed: cliccando su di esso, appare la lista delle richieste rinnovate di cui vengono
specificati alcuni dati come l’operatore, il numero seriale, ecc…;
Pending: cliccando su di esso, appare la lista delle richieste pendenti, cioè quelle in attesa di
approvazione, delle quali viene specificato il numero seriale, il richiedente, la data, il ruolo
richiesto ed il livello di affidabilità richiesto;
Cliccando sul seriale della richiesta è possibile modificare la richiesta (cliccando su Edit
Request), rilasciare il certificato (cliccando su Issue Certificate), oppure cancellare la
richiesta (cliccando su Delete Request).
Waiting for additional assignature: cliccando su di esso, viene mostrata la lista dei certificati
già firmati che hanno bisogno di un’ulteriore firma;
Approved: cliccando su di esso, appare le lista delle richieste di certificazione approvate di
cui vengono visualizzate varie informazioni come l’operatore, il numero seriale, ecc…;
Cliccando su Active CRRs appaiono i seguenti link:
New: cliccando su di esso, appare la lista delle nuove richieste di revoca dei certificati. Per
ogni richiesta vengono visualizzati il numero seriale della richiesta, i dati del richiedente, la
data della richiesta, il ruolo richiesto ed il livello di affidabilità richiesto;
Pending: cliccando su di esso, appare la lista delle richieste di revoca pendenti, cioè quelle
in attesa di approvazione, delle quali viene specificato il numero seriale del certificato, il
richiedente e la data di richiesta;
Waiting for additional assignature: cliccando su di esso, viene mostrata la lista delle
richieste di revoca che hanno bisogno di un’ulteriore firma; per ogni richiesta vengono
visualizzati campi come l’operatore, il seriale del certificato, il nome del richiedente, la data
della firma, il ruolo richiesto;
Approved: cliccando su di esso, appare la lista delle richieste di revoca approvate di cui
vengono visualizzati i seguenti campi: operatore, seriale del certificato, nome del
richiedente, data di approvazione.Cliccando sul seriale del certificato viene visualizzata una
pagina nella quale si ha la possibilità di revocare il certificato cliccando sul bottone Revoke
26
Certificate ed inserendo la password della CA. Nel momento in cui la richiesta di revoca
viene approvata, il certificato passa dallo stato di validità a quello di sospensione;
Cliccando su Information appaiono i seguenti link:
Certificate Requests: cliccando sul link Archived viene visualizzata la lista delle richieste di
certificazione archiviate , mentre cliccando su Deleted viene visualizzata la lista delle
richieste di certificazione cancellate;
Revocation Requests: permette di visualizzare le richieste di revoca;
Certificates: cliccando su di esso, è possibile visualizzare:
o i certificati validi (tramite il link Valid) di cui vengono specificati il seriale, il nome,
l’e-mail ed il ruolo;
o i certificati scaduti (tramite il link Expired) di cui sono specificati il seriale, il nome,
l’e-mail ed il ruolo;
o la lista dei certificati sospesi (tramite il link Suspended) dei quali sono specificati il
seriale, il nome, l’e-mail ed il ruolo;
o la lista dei certificati revocati (tramite il link Revoked).
Ca Certificates: tramite questo link è possibile visualizzare i certificati validi e quelli scaduti
della CA; inoltre, cliccando sul seriale del certificato è possibile scaricarlo scegliendo il
formato desiderato;
CRLs: permette di visualizzare la lista di tutti i certificati revocati.
Cliccando su Language è possibile scegliere la lingua desiderata.
Cliccando su Initialization appare una schermata che permette di inizializzare l’infrastruttura a
chiave pubblica attraverso tre fasi.
Prima fase: Initialize the Certification Authority. Questo link viene usato quando si esegue
OpenCA per la prima volta (quindi si deve inizializzare la stessa CA) o quando si deve
importare il certificato approvato dalla root CA. Ci sono diversi link che permettono di
effettuare:
o inizializzazione del database (vengono mostrate le istruzioni sql);
o inizializzazione delle chiavi (permette di generare una nuova chiave segreta della
CA. Si deve specificare l’algoritmo per la generazione delle chiavi, l’algoritmo per la
cifratura della chiave e la lunghezza della chiave);
o inizializzazione della richiesta (permette di stabilire i campi necessari per una
richiesta di certificazione alla CA);
o setup del certificato;
o ultimi passi.
Seconda Fase: Create the initial administrator. Questo link serve ad inizializzare il primo
utente dell’infrastruttura a chiave pubblica che è l’amministratore. A tal fine vengono
visualizzati i passi da seguire:
o generare una nuova richiesta;
o modificare la richiesta;
o rilasciare il certificato;
o scaricare il certificato.
27
Terza Fase: Create the initial RA Certificate. Questo link viene utilizzato per creare il primo
certificato server dell’infrastruttura a chiave pubblica e l’utente dovrebbe essere un web
server. A tal fine vengono visualizzati i passi da seguire:
o generare una nuova richiesta;
o modificare la richiesta;
o rilasciare il certificato;
o scaricare il certificato.
Cliccando su Configuration compaiono i seguenti link:
Roles: cliccando su di esso, appare la lista dei ruoli disponibili nell’ infrastruttura a chiave
pubblica, in cui si può anche aggiungere un ruolo;
Rights: cliccando su di esso, vengono mostrati i diritti, identificati dal modulo, operatore,
operazione, proprietario. E’ permesso cancellare un singolo diritto o aggiungere nuovi
diritti;
Modules: cliccando su di esso, vengono mostrati i moduli disponibili nell’infrastruttura a
chiave pubblica, identificati dal numero, descrizione ed è possibile anche cancellarli;
Sign the configuration: cliccando su di esso, viene permesso di approvare la configurazione
inserendo la password;
Cliccando su Logout viene permesso di uscire dalla sessione.
28
Tuning
Servizi Richiesti
La CA necessitava della registrazione del dominio “https://www.ca.org/”, effettuata dal gruppo
NIC. Collegandosi a tale dominio un qualsiasi utente può effettuare diverse richieste (la richiesta di
un certificato o della sua revoca). Il gruppo NIC, oltre a fornire la registrazione del dominio,
fornisce anche il servizio di “whois”, cioè tramite software, NIC, permette di riconoscere l’identità
dell’intestatario del dominio ed in più permette la sincronizzazione con il loro CLOCK.
Richieste effettuate
Collegandosi ad https://www.nic.org/abbiamo compilato il form di richiesta registrazione utente, ci
siamo autenticati con i dati di ingresso ed abbiamo effettuato la richiesta del nuovo dominio
www.ca.org.
Inoltre abbiamo richiesto un indirizzo e-mail a ISP1 [email protected] .
In più per l’abilitazione del protocollo HTTPS è stato necessario creare due certificati firmati dalla
CA per web server. In appendice aggiungiamo una guida su come abilitare HTTPS sotto apache.
Richieste ricevute
La CA ha rilasciato, in seguito all’apposita richiesta di certificazione, due certificati al gruppo NIC
uno in qualità di USER e l'altro in qualità di WEB SERVER; due certificati al gruppo ISP1 in
qualità di OPERATOR, WEB SERVER. Tali certificati sono tutti ancora validi, sia perchè il loro
periodo di validità non è ancora terminato, sia perché nessun gruppo ne ha richiesto la revoca.
29
Prima commessa
Studio di fattibilità su LDAP: Panoramica sulla situazione attuale
Con la nascita ed evoluzione di Internet e con il notevole incremento dei suoi utenti, sono sorti
problemi di sicurezza:
La suite di protocolli TCP/IP non prevede nessun meccanismo che garantisce confidenzialità
e privacy tra gli utenti.
Gli scenari e le applicazioni in cui è richiesta confidenzialità e privacy delle connessioni
sull'inter-rete sono molteplici.
Accedere in maniera privata ad una directory remota dislocata su di un server è uno di questi
possibili scenari.
Una directory è un database specializzato per la lettura e la ricerca, con la possibilità di contenere
informazioni basate su attributi o descrizioni, offrendo supporto di sofisticate capacità di ricerca
attraverso dei filtri e risposte veloci ad operazioni di consultazione o di ricerca su volumi di dati
enormi.
Alcuni servizi di directory sono locali: forniscono servizi ad un ristretto contesto, ad esempio una
singola macchina. Altri servizi sono globali: forniscono servizi ad un contesto più ampio, quale ad
esempio l’intera Internet. I servizi globali sono distribuiti: i dati contenuti sono memorizzati in
diverse macchine, ognuna delle quali provvede al servizio di directory.
Progetto della soluzione
LDAP è un acronimo che sta per LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL. È un
protocollo leggero per accedere ai servizi di directory, basati sul protocollo X.500. Opera su TCP/IP
o su altre connessioni orientate ai servizi di trasferimento. Il modello di informazioni di LDAP è
basato sulle entry che sono collezioni di attributi che hanno un unico nome globale: il Distinguished
Name (DN). Ogni attributo della entry ha un tipo ed uno o più valori, che sono stringhe
mnemoniche, come cn per i common name, oppure mail per gli indirizzi di posta elettronica.
Le entry di una directory sono strutturate come in una struttura gerarchica ad albero: la entry che
rappresenta il paese si trova alla radice dell’albero, al di sotto di essa ci sono quelle che
rappresentano stati e organizzazioni nazionali e infine seguono poi altri tipi di entry che possono
rappresentare organizzazioni, persone, stampanti, documenti, ecc.
30
Figura 7
Il protocollo LDAP definisce servizi per accedere e aggiornare una directory; l’operazione più usata
è quella di ricerca di informazioni all’interno della directory e LDAP fornisce un efficiente
algoritmo di ricerca. Molti servizi di directory non prevedono protezione per i dati e le
informazioni. LDAP include un meccanismo nel quale un client si può autenticare, o provare la sua
identità ad un directory server, infine consente servizi di privacy e di integrità delle informazioni.
Funzionamento di LDAP
Il servizio di directory LDAP è basato su un modello client – server: uno o più server LDAP
contengono i dati che servono a costruire l’albero delle informazioni di una directory, il DIT
(Directory Information Tree). Il client si connette al server e gli chiede informazioni, il server
replica con risposte precise e/o con un puntatore ad eventuali informazioni addizionali, infine il
client LDAP può comunicare sia con un server X.500 sia con un server LDAP.
Specifiche generali del sistema
Ora esplicitiamo le varie configurazioni delle directory
Servizi di directory locali: in questa configurazione, esiste un unico server che offre servizi
di directory solo in un unico dominio.
Figura 8
31
Servizi di directory locali con riferimento: in questa configurazione, si imposta un server che
offre servizi di directory per il dominio locale e lo si configura per ritornare riferimenti ad
un servizio superiore capace di occuparsi di richieste esterne al dominio locale; è usata se si
vogliono fornire servizi di directory locali e partecipare alla "Directory Globale" tramite
Internet.
Figura 9
Servizi di directory replicati: in questa situazione è usato un demone per propagare
cambiamenti da un server master del servizio ad uno o più server slave; può essere usata
assieme ad altre in situazioni dove un solo server non offre l'affidabilità richiesta.
Figura 10
Servizio di directory locale distribuito: in questa configurazione, il servizio globale è
partizionato in servizi più piccoli ognuno dei quali può essere replicato e unito a riferimenti
superiori e subordinati.
Modalità di realizzazione
Per installare OpenLDAP è possibile scaricarlo dal sito http://www.openldap.org/. Una volta
ottenuto il pacchetto in formato compresso lo si deve decomprimere con il comando:
gunzip -c openldap-VERSION.tgz | tar xf –
sostituendo VERSION con la versione corrente del pacchetto. Lo stesso pacchetto è disponibile
anche in versione RPM per le versioni di Linux che supportano tale standard (RedHat, Suse,
32
Mandrake).
Per il corretto funzionamento di OpenLDAP occorre installare software di terze parti: Kerberos per
la gestione della sicurezza nel processo di autenticazione, librerie SASL di Cyrus per offrire
servizi di autenticazione sicuri e ulteriori servizi di sicurezza
Slapd è il demone che gestisce le richieste dei client del servizio, esso supporta i TCP Wrappers per
la gestione degli accessi a livello IP e per funzionalità di firewalling. La parte di backend del
demone slapd richiede la presenza della libreria per la gestione di database SleepyCat Software
Berkeley DB.Berkeley DB è disponibile dal mirror Sleepycat alla pagina
http://www.sleepycat.com/download.html.
Lo script di configurazione configure supporta diverse opzioni e la gestione di flags e variabili
d'ambiente. Per avere accesso a ulteriori informazioni sulla configurazione digitare il comando:
./configure --help
Inoltre lo script configure comprende la gestione di variabili d'ambiente per l'impostazione di
particolari opzioni.
Successivamente fare il build del pacchetto; se la fase di configurazione è andata a buon fine sarà
possibile generare le dipendenze per la compilazione, ciò avviene tramite il comando:
make depend
Il building dell'applicazione deve essere eseguito con il comando:
make
facendo attenzione all'output prodotto per vedere se sono stati generati errori durante tale fase.
Una volta che l'applicazione è stata configurata e compilata è possibile fare il testing dei file
generati con il comando:
make test
Dopo aver testato i file generati in fase di building è ora possibile procedere all'installazione vera e
propria. Innanzitutto è necessario verificare di essere in possesso dei privilegi di scrittura nelle
directory specificate in fase di configurazione. Per default OpenLDAP è installato nella directory
/usr/local/.Tipicamente la fase di installazione richiede i privilegi del superuser. Ottenuti i privilegi
di root, dalla directory d'installazione di OpenLDAP si esegue il comando:
make install
prestando sempre attenzione all'output generato, nel caso siano presenti errori.
Slapd gestisce le richieste dei client del servizio. Spesso è in esecuzione su più macchine della rete
per aumentare la disponibilità del servizio con una copia di parte o tutta la struttura dell’albero di
directory
33
Figura 11
Possono esistere più istanze di slapd (slave) che fanno riferimento ad un'istanza master. L'istanza
master mantiene un file di log con le informazioni che il demone slurpd passerà alle istanze slave
Figura 12
La configurazione del demone slapd avviene mediante il file slapd.conf solitamente posto nella
directory /etc/openldap . Il file slapd.conf consiste di tre sezioni per la configurazione: global,
backend specific e database specific.
Le informazioni della sezione global sono le prime ad essere specificate all'interno del file,
successivamente sono definite le direttive della sezione di backend ed infine quelle di database. Le
34
direttive globali possono essere sovrascritte da quelle di backend e/o di database , e le direttive di
backend possono essere annullate dalle direttive di database.
Struttura di slapd.conf : Esempio
Le righe di commento iniziano con il simbolo #.La struttura di slapd.conf è simile alla seguente:
# Direttive di configurazione globali <global config directives>
# Definizioni di backend backend <typeA> <backend-specific directives>
# Definizione di direttive di database e tipo database <typeA> <database-specific directives>
# Seconda definizione di direttive di database database <typeB> <database-specific directives>
# Successive direttive di backend, database e di configurazione ...
access to attr=userPassword
by self write
by anonymous auth
by dn.base="cn=Admin, dc=example, dc=com" write
by * none
Specifica che l’amministratore può modificare l’attributo userPassword di qualsiasi entry, che ogni
entry può modificare il suo attributo userPassword e che tutti gli altri non hanno permesso di lettura
e di scrittura.
access to *
by dn.base="cn=Admin, dc=example, dc=com"
write
by * read
Specifica che l’amministratore ha permesso di scrittura su qualsiasi oggetto e tutti hanno permesso
di lettura su tutti gli oggetti.
Slapd è stato progettato per essere eseguito come server stand-alone. I comandi per avviare slapd
variano a seconda del tipo di installazione che è stata fatta, se da file RPM oppure da sorgenti.
Per installazioni da RPM digitare da riga di comando:
#/etc/init.d/slapd start
Per installazioni da sorgenti:
#/usr/local/etc/libexec/slapd start
Anche la terminazione varia a seconda del tipo di installazione che è stata fatta.
Per installazioni da RPM:
#/etc/init.d/slapd stop
Per installazioni da sorgenti:
#kill –INT ‘cat /usr/local/var/slapd.log’
Per quanto riguarda la procedura di avvio è possibile specificare opzioni della riga di comando.Le
più utili sono:
-f <nome_file>
Specifica il percorso del file di configurazione
-h <URL>
Specifica configurazioni alternative per il listener.
quella di defaul è ldap:// che implica LDAP su TCP su tutte le
35
interfacce e porta 389
-n <nome_servizio>
Specifica il nome del servizio.Default=slapd
-l <syslog-utente-locale>
Specifica l’utente abilitato al syslog
Analisi costi benefici
Le politiche di sicurezza assumono un’importanza quanto mai vitale in un contesto di
autenticazione/autorizzazione. In realtà aziendali dove concetti quali sicurezza dei dati,
certificazione e privacy sono ormai di primaria importanza, l’esistenza di protocolli intrinsecamente
insicuri non può essere che relegata a casi del tutto eccezionali. L’identità del server LDAP è
garantita dal suo certificato, che deve essere distribuito a tutti i client. Oltre alla sicurezza delle
transazioni, è stata dedicata particolare attenzione alla sicurezza dei dati residenti nel server LDAP,
che rappresenta a tutti gli effetti il repository vero e proprio delle informazioni. A questo scopo,
esiste un unico amministratore che a sua volta definisce le politiche di accesso ai dati in base
all’utenza.
Tipicamente un utente deve essere in grado di poter leggere i suoi dati personali, modificare la
propria password, e leggere dati pubblici. Ogni accesso ad altri dati viene negato. In generale, le
performance di un sistema di autenticazione possono essere valutate basandosi sui tempi medi di
risposta ad un tentativo di login. In un architettura basata su LDAP, i tempi di risposta sono
mediamente superiori, specialmente con server LDAP particolarmente popolati.
Sono inoltre disponibili funzionalità di load balancing, con la possibilità di mantenere sottorami
dell’albero LDAP in server diversi. Un semplice meccanismo di linking permette di mantenere
l’effettiva univocità logica della struttura. Il beneficio che se ne trae anche in termini di scalabilità è
notevole, soprattutto considerando il fatto che diversi server LDAP possono essere strutturati
gerarchicamente su più livelli. In scenari particolarmente complessi,LDAP può scalare per aree
geografiche. Infine può essere implementato un meccanismo di replicazione, anch’esso
estremamente semplice dal punto di vista concettuale, con lo scopo di mantenere altre copie del
server LDAP, sincronizzate col principale, in grado di sostituirlo in caso di malfunzionamento dello
stesso. La modalità di sincronizzazione può essere personalizzata, in modo da non sovraccaricare la
rete. Questo garantisce continuità del servizio sia nel caso di modifica dei dati che per
manutenzione del server.
Autenticazione con LDAP usando openLDAP e PAM (Pluggable
Authentication Module)
Nel seguito viene descritto come settare le 3 componenti necessarie per l’autenticazione attraverso
un server LDAP. Occorre :
aggiungere i campi necessari nel server LDAP
installare e configurare i moduli PAM
installare e configurare le librerie nsswitch
36
Aggiungere informazioni utente al database LDAP
Per usare LDAP autentication occorre aggiungere tutte le dipendenze al database. La migliore fonte
per questo tipo di cose sono i file /etc/passwd, /etc/group e /etc/shadow. Ci sono alcuni tool di
migrazione che trasformano :
cat /etc/passwd
...
simon:rF4x4xNEP1bA.:1000:1000:Simon
Tenant,Fish-bowl,x 245,:/home/simon:/usr/bin/zsh
...
in qualcosa del genere :
dn: uid=simon,ou=People,dc=linuxcare,dc=com
uid: simon
cn: Simon Tennant
objectClass: account
objectClass: posixAccount
objectClass: top
userPassword: {crypt}rF4x4xNEP1bA.
loginShell: /usr/bin/zsh
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/simon
gecos: Simon Tennant,Fishbowl,x 245
Questi tools sono disponibili al seguente indirizzo :
http://www.padl.com/download/MigrationTools.tgz. Vi sono una serie di script, il più importante è
migrate_passwd.pl che trasforma le entries di /etc/passwd nel formato LDIF.
Script
Migra
migrate_fstab.pl
/etc/fstab
migrate_group.pl
/etc/group
migrate_hosts.pl
/etc/hosts
migrate_networks.pl /etc/networks
migrate_passwd.pl /etc/passwd
migrate_protocols.pl /etc/protocols
migrate_rpc.pl
/etc/rpc
migrate_services.pl /etc/services
Tabella 1
Per il server LDAP occorre caricare le entries nel database LDAP.
/etc/init.d/openldapd stop
ldif2ldbm -i /tmp/converted_passwd.out -f /etc/openldap/slapd.conf
Questocomando dipende dal tipo di database che si sta utilizzando con il server
LDAP ( Nel caso della nostra guida il database è il Berkeley DB e quindi per
aggiungere le entries al DIT usiamo il comando
# ldapadd –d “cn=admin,dc=example,dc=com” –W –f passwd.ldif
/etc/init.d/openldapd start
37
e controllare che le entries aggiunte ci siano nel seguente modo :
ldapsearch -b dc=linuxcare,dc=com objectclass=posixaccount
Se invece non stiamo migrando un sistema ma costruendone uno nuovo possiamo
usare uno strumento grafico realizzato in Python chiamato LUMA che tra le varie
funzionalità ha quella di poter creare utenti in modo ‘massive’ consentendo una
popolazione iniziale del server LDAP.
Settare i moduli PAM
Linux usa PAM (Pluggable Authentication Modules) per l’autenticazione. Pam è facilmente
configurabile. I file di Pam si travano in /etc/pam.d. L’autenticazione con PAM funziona
sostituendo i moduli /etc/passwd e /etc/group con il modulo ldap.so
La configurazione di pam sshd è la seguente :
cat /etc/pam.d/ssh
#%PAM-1.0
auth
required
account
required
password
required
session
required
pam_unix.so
pam_unix.so
pam_unix.so
pam_unix.so
Per usare ladap authentication occorre scaricare un modulo che può essere sostituito per
"pam_unix.so" che controlla le passwords al server ldap.
source http://www.padl.com/download/pam_ldap.tgz
rpm at: http://rpmfind.net/linux/RPM/pam_ldap.so.html
I due file principali sono sono /lib/security/pam_ldap.so che comunicano con il server LDAP e
/etc/pam_ldap.conf che rappresenta il modulo con il quale il server ldap dovrebbe comunicare e al
quale vengono effettuate le query.
Il passo successivo consiste nel settare il file /etc/pam_ldap.conf a seconda dell’organizzazione
della struttura. Ad esempio :
cat /etc/pam_ldap.conf
# Your LDAP server.
host ldap.linuxcare.com
# The distinguished name of the search base.
base dc=linuxcare,dc=com
# Use the V3 protocol to optimize searches
ldap_version 2
# Hash password locally; required for University of
# Michigan LDAP server, and works with Netscape
# Directory Server if you're using the UNIX-Crypt
# hash mechanism and not using the NT Synchronization
# service.
pam_crypt local
Come è possibile vedere, tutte le queries vengono inviate a ldap.linuxcare.com e cercate da
dc=linuxcare,dc=com.
38
Per effettuare dei cambiamenti occorre modificare il file /etc/pam.d/ssh.
auth
auth
auth
account
account
password
password
session
umask=0022
session
required
sufficient
required
sufficient
required
required
required
required
/lib/security/pam_nologin.so
/lib/security/pam_ldap.so
/lib/security/pam_pwdb.so shadow nodelay
/lib/security/pam_ldap.so
/lib/security/pam_pwdb.so
/lib/security/pam_cracklib.so
/lib/security/pam_pwdb.so shadow nullok use_authtok
/lib/security/pam_mkhomedir.so skel=/etc/skel/
required
/lib/security/pam_pwdb.so
Settare le librerie nsswitch
Varie funzioni nella libreria C come login e passwd hanno bisogno di essere configurati per
lavorare con ldap. nsswitch permette appunto di fare questo. Un buon esempio è quando viene
effettuato un comando ls su una directory che contiene files che sono di proprietà di un utente ldap.
ls -l /home
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
3
5
2
5
3
85
2
redsteel
rob
robert
rslomkow
10002
10011
10301
users
users
users
users
users
users
users
1024
1024
1024
1024
1024
7168
1024
Feb
May
Sep
Jul
Jun
Jul
Jun
27
27
12
15
22
24
30
05:44
13:54
1999
19:40
1999
12:09
17:53
redsteel
rob
robert
rslomkow
sam
simon
stephane
Per fare questo ls ha bisogno di controllare gli uids e gids dei files nella directory. A questo
proosito si può usare nsswitch. E’ possibile istruire tutti i programmi che dipendoo dalla libreria C
di controllare per prima gli uids e gids in /etc/passwd e /etc/group e controllare il server ldap.
ls -l /home
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
drwxr-sr-x
3
5
2
5
3
85
2
redsteel
rob
robert
rslomkow
sam
simon
stephane
users
users
users
users
users
users
users
1024
1024
1024
1024
1024
7168
1024
Feb
May
Sep
Jul
Jun
Jul
Jun
27
27
12
15
22
24
30
05:44
13:54
1999
19:40
1999
12:09
17:53
redsteel
rob
robert
rslomkow
sam
simon
stephane
Con nsswitch installato è possibile chiamare ls al server ldap per gli uids che non possono essere
cercati localmente in /etc/passwd. Cosi l’uid 10002 è convertito in sam, 10011 in simon e così
via.
Settare nss_ldap
Sono disponibili dei file preconfigurati di nss per ldap sul sito http://www.padl.com
Sorgente: http://www.padl.com/download/nss_ldap.tgz
RPM: http://rpmfind.net/linux/RPM/pam_ldap.so.html
39
Dobbiamo dire a libnss-ldap da dove prendere le informazioni utente:
cat /etc/lib-nss-ldap.conf
Questo è quello che ci appare a schermo:
# Your LDAP server. Must be resolvable without using LDAP.
host ldap.linuxcare.com
# The distinguished name of the search base.
base dc=linuxcare,dc=com
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
#binddn cn=manager,dc=padl,dc=com
# The credentials to bind with.
# Optional: default is no credential.
#bindpw secret
# The hashing algorith your libc uses.
# Optional: default is des
#crypt md5
#crypt sha
#crypt des
C’è davvero poco da modificare rispetto alla configurazione di default. Sid eve
cambiare il server ldap al quale ci si intende connettere e a quale parte
dell’albero. Nell’esempio ci colleghiamo al ramo “dc=linuxcare,dc=com”.
Adesso dobbiamo dire a nsswitch di cercare gli uid e gid nell’albero ldap.
cat /etc/nsswitch.conf
# the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd:
files ldap
group:
files ldap
Questa configurazione dice a ldap di guardare prima nel file /etc/passwd e poi nel server ldap.
Per testare la configurazione ldap facciamo:
getent passwd
questo commando concatenerà il file /etc/passwd e gli utenti ldap che hanno un match positive per
la ricerca
ldapsearch -b dc=linuxcare,dc=com objectclass=posixaccount
e mostrerà l’output a schermo. Dovresti adesso vedere una lista di utenti locali e utenti presi dal
server LDAP.
stephane:nHBA0fvpJqzvk:1009:100::/home/stephane:/bin/bash
r3cgm:pCVsIxSgbsuNY:1011:1011:Christopher Mann,,,:/home/r3cgm:/usr/bin/tcsh
simon:x:15000:100:Simon Tennant (ldap test account):/home/simon:/bin/bash
Nota che adesso gli utenti ldap (in questo caso simon) non hanno una password criptata( solo una
‘x’). Questo perché la password è solo confrontata con il server, e mai inviata dal server al client.
Con questo si conclude la fase di setup del sistema e si può iniziare la fase di testing.
40
Per effettuare il testing abbiamo deciso di provare a configurare il webserver apache come client per
un server LDAP (Figura 14).
Architettura del server LDAP
L’architettura del server LDAP è strutturata nel seguente modo :
daemon LDAP chiamato slapd
o Scelta dei database
SHELL : interfaccia db per comandi UNIX
PASSWORD : semplice file di paswd
SQL : che mappa sql a ldap
o Più instanza di database
o Controllo degli accessi
Figura 13
41
Apache basato su server WebDAV con LDAP
Figura 14
L’obiettivo che ci poniamo è quello di settare Apache + mySQL + PHP + WebDAV basato su
un Web Application Server che usa LDAP per l’autenticazione. WebDAV sta per Web enabled
Distributed Authoring and Versioning. Fornisce un ambiente collaborativo per utenti per gestire
file su un web-server. Tecnicamente DAV è un’estensione del protocollo http. In seguito vi è
una breve descrizione delle funzionalità fornite da DAV :
Overwrite Protection: meccanismo lock e unlock per prevenire il problema "lost update”
Properties: Metadata (titolo, argomento, creatore, etc)
Name-space management: copia, rinomina, e cancellazione di file
Access Control: limita l’accesso alle varie risorse
Versioning: controllo di revisione per i documenti . Questa funzionaliità ancora non è
implementata.
Installazione
Prerequisiti
L’applicazione server richiede le librerie SSL e le librerie LDAP
Mysql
42
Installare mySQL é abbastanza semplice. Occorre creare un user : group per il daemon mysql e
copiare i file nelle appropriate directories.
#
#
#
#
#
groupadd mysql
useradd -g mysql mysql
cd /usr/local
gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf ln -s full-path-to-mysql-VERSION-OS mysql
In seguito occorre eseguire lo script install_db e cambiare i permessi ai files
# cd mysql
# scripts/mysql_install_db
# chown -R mysql .
Avviare Mysql
Facciamo partire il server mySQL per verificare l’installazione
# bin/mysqld_safe --user=mysql &
Arrestare Mysql
Per stoppare il server MySQL seguire le instruzioni di seguito
# cd /usr/local/mysql
# ./bin/mysqladmin -u root -p shutdown
Localizzare la Directory dei dati
il daemon mysql memorizza le informazioni in una directory chiamata "Data Directory", che
dovrebbe trovarsi sotto /use/local/mysql/data.
Apache 2.0
Occorre settare alcuni FLAGS
# export LDFLAGS="-L/usr/local/iplanet-ldap-sdk.5/lib/ -R/usr/local/iplanetldap-sdk.5/lib/:/usr/local/lib"
# export CPPFLAGS="-I/usr/local/iplanet-ldap-sdk.5/include"
UNTAR il file sorgente apache 2.0 e eseguire lo script configure
# cd /tmp/download
# gzip -d httpd-2.0.46.tar.gz
# tar -xvf httpd-2.0.46.tar
# cd httpd-2.0.46
#./configure --enable-so --with-ssl --enable-ssl
dav
--enable-rewrite
--enable-
43
Eseguire il comando make
# make
# make install
Avviare Apache
# /usr/local/apache2/bin/apachectl start
Arrestare Apache
# /usr/local/apache2/bin/apachectl stop
mod-auth-ldap
Untar modauthldap_apache2.tar.gz
cd /tmp/download
# gzip -d modauthldap_apache2.tar.gz
# tar -xvf modauthldap_apache2.tar
# cd modauthldap_apache2
Ora occorre configurare e installare mod_auth_ldap
#
./configure
--with-apxs=/usr/local/apache2/bin/apxs
dir=/usr/local/iplanet-ldap-sdk.5/
# make
# make install
--with-ldap-
PHP
Unzippare il file sorgente PHP
gzip -d php-xxx.tar.gz
tar -xvf php-xxx.tar
Esueguire il comando
cd php-xxx
./configure --with-mysql --with-apxs=/usr/local/apache2/bin/apxs
e compilare
# make
# make install
Copiare il file php nella directory appropriata
cp php.ini-dist /usr/local/lib/php.ini
44
Configurare e settare WebDAV services
Modifiche a /usr/local/apache/conf/httpd.conf
Come prima cosa occorre verificare che le seguenti direttive di Apache appaiano in
/usr/local/apache/conf/httpd.conf :
Addmodule mod_dav.c
In seguito specifichiamo dove Apache dovrebbe memorizzare il file DAVLockDB.
DAVLockDB è un db per WebDA.
Memorizza il file DAVLock sotto
/usr/local/apache/var.
Aggiungi
la
seguente
linea
a
/usr/local/apache/conf/httpd.conf per specificare che il file DAVLockDB
dovrebbe trovarsi sotto /usr/local/apache/var :
DAVLockDB
/usr/local/apache/var/DAVLock
Creare una directory per DAVLockDB
Deve essere creata una directory che può essere scritta dal web server process. Di solito il web
server process è eseguito sotto l’user 'nobody'. Occorre verificarlo con il comando:
ps -ef | grep httpd
Sotto /usr/local/apache occorre
comando :
creare
la directory e settare i permessi usando il seguente
# cd /usr/local/apache
# mkdir var
# chmod -R 755 var/
# chown -R nobody var/
# chgrp -R nobody var/
Usare DAV
Per usare DAV per una direcotory sotto Apache root occorre aggiungere la seguente direttiva nel
conteiner per quella particolare directory :
DAV On
Viene mostrata una semplice configurazione che utilizza WebDAV e authentication LDAP su
/usr/local/apache/htdocs/DAVtest.
Occorre aggiungere il seguente frammento nel file /usr/local/apache/conf/httpd.conf
DavLockDB /tmp/DavLock
<Directory "/usr/local/apache2/htdocs/DAVtest">
Options Indexes FollowSymLinks
AllowOverride None
order allow,deny
45
allow from all
AuthName "SMA Development server"
AuthType Basic
LDAP_Debug On
#LDAP_Protocol_Version 3
#LDAP_Deref NEVER
#LDAP_StartTLS On
LDAP_Server you.ldap.server.com
#LDAP_Port 389
# If SSL is on, must specify the LDAP SSL port, usually 636
LDAP_Port 636
LDAP_CertDbDir /usr/local/apache2/sslcert
Base_DN "o=SDS"
UID_Attr uid
DAV On
#require valid-user
require valid-user
#require roomnumber "123 Center Building"
#require filter "(&(telephonenumber=1234)(roomnumber=123))"
#require group cn=rcs,ou=Groups
</Directory>
Creare una Directory chiamata DAVtest
Tutte le directory DAV devono essere scrivibili sul WebServer process. In questo esempio
assumiamo che WebServer lavori sotto l’username 'nobody'.
# ps -ef | grep httpd
Occorre creare una directory test chiamata ‘DAVtest' sotto /usr/local/apache2/htdocs :
# mkdir /usr/local/apache/htdocs/DAVtest
Occorre usare il seguente comando :
# cd /usr/local/apache/htdocs
# chmod -R 755 DAVtest/
# chown -R nobody DAVtest/
# chgrp -R nobody DAVtest/
Riavviare Apache
Eseguire
# /usr/local/apache/bin/apachectl configtest
Se il configtest è stato eseguito con successo avvia il apache web-server:
# /usr/local/apache/bin/apachectl restart
46
Gestione del server WebDAV
In questa sezione si discutono i vari task di gestione, ad esempio usare LDAP per controllare gli
accessi e lavorare con il metodo DAV su Apache. La maggior parte dei cambiamenti di
configurazione per DAV saranno fatti usando il file httpd.conf. Questo file si trova sotto
/usr/local/apache/conf/httpd.conf. Prima di rendere effettivi i cambiamenti e
riavviare
apache
occorre testare la validità di httpd.conf usando il comando
/usr/local/apache/bin/apachectl configtest .
Se il risultato del comando è Syntax OK allora possiamo riavviare apache usando il comando
# /usr/local/apache/bin/apachectl restart
Limitare l’accesso alle condivisioni DAV
Nella sezione precedente abbiamo creato il DAVtest condiviso, usiamo LDAP per l’autenticazione.
Comunque chiunque può auternticarsi usando il proprio LDAP useri/passwd che permette di
accedere alla cartella . Usando la direttiva require in file httpd.conf possiamo limitare l’accesso ad
alcune persone o ad un gruppo di persone. Se osserviamo la configurazione DAVtest della
precedente sezione
<Directory /usr/local/apache/htdocs/DAVtest>
Dav On
#Options Indexes FollowSymLinks
AllowOverride None
order allow,deny
allow from all
AuthName "LDAP_userid_password_required"
AuthType Basic
<Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require valid-user
</Limit>
LDAP_Server ldap.server.com
LDAP_Port 389
Base_DN "o=ROOT"
UID_Attr uid
</Directory>
osserviamo che require è settato a valid-user. Questo significa che ciascun utente autenticato ha
accesso a questa cartella .
Limitare l’accesso basato su UID
LDAP UID può essere usato per limitare l’accesso alla cartella DAV
la direttiva require valid-user può essere cambiata in require user 334455 445566
Questo limita l’accesso alla persona con UID 334455 e 445566. Tutti gli altri non hanno il
permesso di accedere alla cartella.
47
Limitare l’accesso a un gruppo di persone
require può essere usato per restringere l’accesso a un gruppo di persone. Questo può essere fatto
usando LDAP groups o LDAP filters.
Limitare l’accesso in scrittura alle cartelle condivise
A volte si richiede che l’editing per le risorse sulle cartelle DAv condivise sia limitato solo ad
alcuni utenti. Questo può essere fatto usando il tag <Limit> nel file httpd.conf
<Directory /usr/local/apache/htdocs/DAVtest>
Dav On
#Options Indexes FollowSymLinks
AllowOverride None
order allow,deny
allow from all
AuthName "LDAP_userid_password_required"
AuthType Basic
<Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require valid-user
</Limit>
LDAP_Server ldap.server.com
LDAP_Port 389
Base_DN "o=ROOT"
UID_Attr uid
</Directory>
Limitiamo l’accesso ad alcuni utenti cambiando <limit> con
<Limit PUT POST DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
Require 334455
</Limit>
48
Appendice A: come richiedere e installare certificati
WebServer
SSL (secure Socket Layer) è un protocollo che permette l'invio di pacchetti criptati in Internet ed
possibile "abbinarlo" al normale HTTP per avere maggior sicurezza sul traffico prodotto dal server
e dal client.
Questa soluzione viene adottata in molti casi, soprattutto per siti che richiedono un elevato livello di
sicurezza come site e-commerce o siti che trattano informazioni personali. L'utilizzo del protocollo
HTTPS (HTTP Secure) non implica che il server in questione diventi invulnerabile a possibili
attacchi ma evita semplicemente (o rende molto più difficile) che il traffico possa essere
"sniffato" per dedurre informazioni come password o numeri delle carte di credito.
La procedura di criptazione dati è relativamente semplice, si basa su una chiave pubblica che il
server invia al client ad ogni connessione, per permettergli di inviare in modo sicuro la propria key.
Questi pacchetti criptati possono essere letti solo dal server che ha rilasciato la chiave pubblica
poiché sarà l'unico host a possedere la chiave privata, l'unica chiave che ha la possibilità di
decriptare le informazioni ricevute.
Il browser grazie alla chiave pubblica inviatagli dal server, e il seguente scambio di chiavi fra client
e server, permette di identificare entrambi in modo univoco per prevenire quel tipo di attacco
denominato come mimicking (man-in-the-middle attack).
Tipicamente il protocollo HTTP e HTTPS sono distinti anche per quanto rigurda le porte in cui il
servizio è tipicamente disponibile, il protocollo HTTP si usa sulla porta 80 e quello HTTPS sulla
porta 443, quindi il nostro browser quando dovrà accedere ad una risorsa con il protocollo HTTPS
la richiederà al server aprendo una connessione sulla porta 443.
Esistono molteplici soluzioni per l'implementazioni di SSL con Apache, come un progetto del core
team di Apache Apache-SSL o anche soluzioni commerciali, ma l'opzione più comune è l'uso del
modulo mod_ssl, poiché permette di astrarre le funzionalità di openssl in un modulo, e la sua
portabilità in tutti i sistemi Unix e windows lo rendono un oggetto universale.
Certificati per server Apache
Compilazione di mod_ssl
Mod_ssl è il modulo più comune per la gestione del protocollo HTTPS in Apache.
E' un progetto nato nel 1998 dalla mente di Ralf S. Engelschall, deriva da un progetto esistente
(Apache-SSL) e ormai si può definire la soluzione più utilizzata per implementare il protocollo
HTTPS in Apache.
Il progetto è stato rilasciato tramite una licenza BSD-style, quindi è utilizzabile gratuitamente sia
per scopi commerciali che non, oltre a poter essere riutilizzato autonomamente su progetti di terzi.
Semplificando, mod_ssl si può vedere come una patch del codice sorgente di Apache, e come
qualsiasi altra patch deve essere correlata alla versione corretta del package da patchare.
49
Anche in questo caso si ha una versione di mod_ssl specifica per una versione specifica di Apache.
Per esempio, se si deve patchare Apache 1.3.23, la versione di mod_ssl corretta è mod_ssl-2.8.61.3.23.
La procedura di massima per l'installazione di mod_ssl tramite sorgenti si limita al lancio dello
script configure con le opzioni per il patching dei sorgenti. Supponiamo di trovarci nella directory
scompattare del tar.gz ufficiale, parallela alla directory dei sorgenti di Apache.
[root@dido mod_ssl-2.8.6-1.3.23]# ./configure --with-apache=../apache_1.3.23/ --with
ssl=../openssl-0.9.6g
Configuring mod_ssl/2.8.6 for Apache/1.3.23
+ Apache location: ../apache_1.3.23/ (Version 1.0)
+ OpenSSL location: ../openssl-0.9.6g
+ Auxiliary patch tool: ./etc/patch/patch (local)
+ Applying packages to Apache source tree:
[...]
Now proceed with the following commands:
$ cd ../apache_1.3.23/
$ make
$ make certificate
$ make install
Infine successivamente eseguire la compilazione e l'installazione di Apache come meglio si crede.
Spostarsi nella directory in cui si trovano i suoi sorgenti e proseguire con il ./configure.
In questo caso viene abilitato il DSO mode per tutti i moduli disponibili compreso mod_ssl
[root@dido apache_1.3.23]# ./configure --with-layout=Apache --enable-module=most --enableshared=max
[root@dido apache_1.3.23]# make
[root@dido apache_1.3.23]# make certificate
[root@dido apache_1.3.23]# make install
Nel caso in cui si debba installare mod_ssl per un Apache già in esecuzione e con il supporto DSO e
EAPI abilitata bisogna appoggiarsi ad apxs.
[root@dido root]# cd /usr/src/mod_ssl-2.8.6-1.3.23/
[root@dido mod_ssl-2.8.6-1.3.23]# ./configure --with-ssl=../openssl-0.9.6g --withapxs=/usr/local/apache/bin/apxs
[...]
Installazione del modulo.
[root@dido mod_ssl-2.8.6-1.3.23]# /usr/local/apache/bin/apxs -i -a -n mod_ssl pkg.sslmod/libssl.so
Creazione e installazione certificato
Queste istruzioni sono relative alla richiesta di un certificato per l'attivazione del protocollo HTTPS
(HTTP su SSL) per un server Apache 1.3.
Prerequisiti:
1. installare il modulo mod_ssl (di solito già presente nelle distribuzioni classiche) o installare
la versione Apache-SSL.
50
2. generare la coppia di chiavi e la richiesta di certificato con OpenSSL:
Lanciate il comando:
openssl req -new -out server.csr -keyout server.pem
Verrà richiesta la PEM pass phrase; trascrivetela in un posto sicuro, perchè la chiave non è più
utilizzabile senza la pass phrase.
Alla richiesta del nome DNS del server, rispondete con il Fully Qualified Domain Name (cioé con
tutte le parti, es. www.ca.org) dell'host. Il nome DNS dev'essere quello che gli utenti usano per
collegarsi al server.
Se non potete utilizzare la configurazione fornita, i parametri sono:
server di strutture
IT
Country Name
State or Province Name <enter>
<enter>
Locality Name
caGroup
Organization Name
Organizational Unit Name <enter>
nome DNS completo del server o del virtual host
Common Name
il vostro indirizzo
Email Address
3. Per verificare il contenuto della richiesta, potete usare il comando:
openssl req -verify -noout -text -in server.csr
4. spostare il file con la chiave (server.pem) in una directory accessibile solo a root (es.
/etc/apache/keys/).
Installazione del certificato:
quando l'Autorità di Certificazione restituirà il certificato
1. salvare il file restituito (server.crt) nella directory di Apache (es. /etc/apache/);
2. poiché all'avvio di Apache viene richiesta la pass phrase, cosa che impedisce l'avvio
automatico, può essere utile decifrare la chiave privata, sempre considerando che deve
quindi essere maggiormente protetta dall'accesso degli utenti della macchina:
openssl rsa -in server.pem -out server.key
3. attivare per il virtual host il motore SSL:
- Verificare in httpd.conf se avviene il caricamento del modulo tramite le direttive
Addmodule e LoadModule.
LoadModule ssl_module
libexec/libssl.so
AddModule mod_ssl.c (Solo su Apache 1.3)
- Specificare le nuove porte a cui il servizio sarà in ascolto tramite le direttive Port o Listen:
Port 80
Listen 80
Listen 443
51
- Abilitazione del modulo mod_ssl. Occorrono tre direttive SSLEngine,
SSLCertificateKeyFile e SSLCertificateFile:
Attivazione del modulo mod_ssl
SSLEngine on
Path per la chiave privata
SSLCertificateKeyFile file.key
Path per il certificato
SSLCertificateFile cert.crt
Queste direttive possono essere specificate sia a livello di server configuration o per singolo
virtual-host, ma per redirezionare tutto il traffico della porta 80 sulla porta 443 occorre
specificare la direttiva SSLrequireSSL nel Directory container:
Redirige tutto il traffico sulla porta 443
<Directory />
SSLrequireSSL
</Directory>
Redirige sulla porta 443 le richieste che comprendono l'URL /private
<Directory /private/>
SSLrequireSSL
</Directory>
4. Riavviare Apache e verificare che tutto funzioni:
# apachectl stop
# apachectl start
# netstat -at | grep http
tcp
0
0 *:http
*:*
LISTEN
tcp
0
0 *:https
*:*
LISTEN
poi con il proprio browser richiedere pagine al server web, sia con il protocollo http e https.
Configurazione avanzata di mod_ssl - Server Level Configuration
Per avere un server funzionale non occorre una ricerca esasperata della configurazione ottimale di
mod_ssl, ma questo modulo ci mette a disposizione un insieme di direttive che ci permette di avere
un controllo totale sull'erogazione del servizio tramite il protocollo HTTPS.
Tutte le seguenti direttive dovranno essere inserite nel file di configurazione httpd.conf più
precisamente all'altezza del server level configuration, da escludere l'uso di queste direttive per i
singoli VirtualHosts.
SSLRandomSeed
La funzionalità random per SSL è fondamentale, poiché riduce al minimo la possibilità di
deduzione della "key session" scambiata tra il client e il server. Tramite questa direttiva è possibile
specificare la sorgente per questi dati casuali, la quale sarà interrogata o solo allo startup del server
o ad ogni nuova connessione, ovviamente la seconda risulta più sicura ma pregiudica un poco le
prestazioni del server. La configurazione minima per questa direttiva è:
SSLRandomSeed startup builtin
52
Questo specifica al modulo mod_ssl che ad ogni startup deve utilizzare uno pseudo-random number
generator all'interno del codice di mod_ssl, non è un vero e proprio generatore di dati casuali ma è
sempre meglio di niente.
E' possibile utilizzare sempre
SSLRandomSeed connect builtin
la
stessa
sorgente
per
ogni
nuova
connessione:
La soluzione migliore (in ambiente Unix) è quella di utilizzare i random device come /dev/random
e /dev/urandom e opzionalmente specificare il numero di bytes da estrarre, ovviamente piu sono
meglio è per quanto riguarda la sicurezza ma una richiesta potrebbe rivelarsi troppo onerosa in
ambito di risorse del sistema.
La possibilità di estrarre un numero esatto di bytes è funzionale solo per /dev/urandom:
SSLRandomSeed connect /dev/random
SSLRandomSeed connect /dev/urandom 512
Oppure si ha la possibilità di utiliizare package esterni all'OS ed al modulo mod_ssl come truerand
disponibile nella sottodirectory pkg.contrib di mod_ssl.
Più direttive SSLRandomSeed possono essere specificate di seguito per "aumentare la
randomizzazione" dei dati:
SSLRandomSeed startup builtin
SSLRandomSeed startup /dev/urandom 1024
SSLRandomSeed connect builtin
SSLRandomSeed connect /usr/local/apache/bin/truerand 32
SSLRandomSeed connect /dev/urandom 512
SSL session cache
Le sessioni SSL possono essere, opzionalmente, cacheate per una maggior performance del server
web. La direttiva che controlla il caching è SSLSessionCache con tre diverse possibilità:
Caching disabilitato, default configuration:
SSLSessionCache none
Caching tramite DBM db file:
SSLSessionCache dbm:path
Caching tramite shared memory segment stabilita da un file, con parametro opzionale per indicare
la dimensione:
SSLSessionCache shm:path[size]
Per avere un maggior controllo della cache ci si può appoggiare alle direttive
SSLSessiononCacheTimeout e SSLMutex. La prima identifica il timeout della cache e la seconda
si può vedere come un semaforo che gestisce il write lock della cache, questo per avitare che più
processi di Apache scrivino sulla stessa cache e quindi evitare sovrapposizioni e "scrambling" dei
contenuti:
Cache time out di 300 sec per ogni sessione
SSLSessiononCacheTimeout 300
Uso del semaforo per locking della cache
SSLMutex sem
Le opzioni disponibili per la direttiva SSLMutex sono:
Disabilita il mutex lock:
SSLMutex none
Usa un file per indicare cha la cache è in lock:
SSLMutex file:path
53
Usa i semafori di sistema:
SSLMutex sem
Configurazione avanzata di mod_ssl - Per Directory configuration
Lo switch on o off del modulo mod_ssl non è possibile per i singoli virtualhost o per specifiche
directory ma è possibile utilizzare due direttive SSLrequireSSL e SSLrequire per settare una
configurazione per ogni singolo virtual host o directory.
SSLrequireSSL
Direttiva che obbliga l'uso di SSL per quando si richiede una risorsa all'interno di una directory o
più semplicemnete per tutte le risorse di un virtual host. Ricordarsi che nel caso si voglia utilizzare
il file .htaccess occorre specificare AllowOverride AuthConfig.
In httpd.conf se si vuole obbligare l'uso di SSL per accedere a /private si deve avere qualcosa di
simile:
<Location /private>
SSLRequireSSL
</Location>
SSLRequire
Direttiva utilizzata per testare l'environment settato da mod_ssl ed Apache. I vari headers e variabili
possono essere estratti e si può eseguire un controllo per verificare che la sorgente possa accedere
alle risorse. La sintassi è complessa ma la sua estrema flessibilità permette di creare delle Access
List più che funzionali:
SSLRequire ( %{HTTPS}eq "on" and %{SSL_PROTOCOL}ne "SSLv2"
and %{SSL_CHIPER_USERKEYSIZE} >= 128) or %{REMOTE_ADDR}= ~ m/^192\.168/
In questo caso, si verifica che SSL venga utilizzato con il protocollo v2 e che la key utilizzata sia
almeno di 128 bit e solo se tutte le tre condizioni si sono verificate o se la sorgente abbia un IP con
indirizzo di rete 192.168 si potrà accedere alla risorsa
SSLProtocol e SSLCipherSuite
E' possibile tramite la direttiva SSLProtocol controllare il protocollo e tramite SSLCipherSuite
controllare il cipher utilizzati per la connessione.
Sono direttive che possono essere specificate anche al server level configuration.
I protocolli supportati sono:
- SSL v2 (l'implementazione originale di SSL)
- SSL v3 (di fatto lo standard odierno)
- TLS v1 (non del tutto supportato ancora).
Di default sono supportati tutti:
SSLProtocol all
ma è possibile restringere l'uso a uno o più protocolli:
SSLProtocol SSLv3
Anche in questo caso è possibile utillizzare il prefisso + e - per aggiungere o togliere protocolli
ereditati dalle direttive precedenti, per esempio:
54
SSLProtocol SSLv3 -TLSv1
Mentre per verificare i cipher supportati occorre interrogare openssl:
[neo@dido neo]$ openssl ciphers
EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3MD5:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5:RC2-CBC-MD5:RC4-MD5:
RC4-64-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-DHE-DSS-DESCBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:
EXP1024-RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBCSHA:DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:
EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC2-CBC-MD5:EXP-RC4MD5
Ci sono più di trenta possibilità, con ogni tipo di protocollo che può usare uno specifico Key
exchange algorithm, authentication method, encrypt method e digest type.
Ognuno di questi quattro componenti può essere rimosso or riordinato nella lista dei ciphers.
La direttiva SSLCipherSuite ha come argomento uno o piu componenti (separati dai ":") che
verranno aggiunti o modificati dalla lista a seconda del prefisso:
Accetta solo RSA key exchangee rifiuta l'export o la cryptazione nulla
SSLCiphersSuite RSA:!NULL:!EXP
Accetta tutti i ciphers ma da la precedenza a quelli che utilizzano SSLv2 e poi quelli SSLv3
SSLCiphersSuite ALL:+SSL2v2
Impostazione di default: accetta tutti i ciphers, tranne ADH(Diffle-Hellman Authentification), usa
rc4 encoding per la cryptazione e RSA per il key exchange dando la precedenza ai cipers con una
maggior cryptazione, con protocollo SSLv2 e l'export ciphers alla fine:
SSLCiphersSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
SSL e VirtualHost
Ci sono due possibili vie per configurare dei virtualhost con il supporto HTTPS, entrambe però
richiedono virtualhost IP-based.
- Definire un singolo certificato e chiave privata nel main host, i quali verranno utilizzati da tutti i
virtualhost.
- Definire certificati e chiavi private per singoli virtual-host.
Evitare la rinegoziazione di protocollo fra server https e client
Ad ogni richiesta fatta da Apache tramite SSL dove è configurato un particolare protocollo o cipher
a seconda della risorsa richiesta, si obbliga il client che ha eseguito la richiesta ad una nuova
negoziazione sul protocollo secondo le direttive settate sul server a seconda della risorsa richiesta.
E' possibile evitare questa rinegoziazione (che porta via tempo e risorse) del protocollo tramite la
seguente
direttiva:
SSLOption +OptRenegotiate
55
Certificati per applicazioni Java
I certificati per le applicazioni Java sono memorizzati in un file detto keystore che può essere
manipolato con il programma keytool fornito con la distribuzione Java. Un'introduzione alla
sicurezza Java è disponibile come tutorial sul sito Sun Microsistems.
Queste istruzione si riferiscono alla creazione di un nuovo keystore; sono applicabili sia alle
piattaforme Microsoft Windows sia aquelle Unix/Linux, prestando attenzione ai separatori nei
percorsi di file (/ per sistemi Linux e \ per sistemi Windows).
1. inizializzare il keystore, generando la coppia di chiavi e la richiesta di certificato:
keytool -genkey -keyalg RSA -keystore <file keystore> -alias <nome convenzionale>
Il programma richiederà due password, una generale del keystore, che serve per tutte le
operazioni che ne richiedono l'accesso, e una specifica per cifrare la chiave privata generata.
Un keystore può contenere più chiavi, purché con alias diversi.
2. estrarre la richiesta di certificato (CSR Certificate Signing Request) dal keystore:
keytool -certreq -alias <nome convenzionale> -keystore <file keystore> -file server.csr
3. per usare il keystore in applicazioni TLS/SSL client o per poter importare il proprio
certificato, occorre prima installare i certificati radice.
keytool -import -keystore <file keystore> -alias ca -file ca.crt
Enter keystore password: *******
Owner: CN=CaGroup, O=CaGroup, C=IT
Issuer: CN=CaGroup, O=CaGroup, C=IT
Serial number: 0
Valid from: Tue Dec 16 16:57:33 MET 2006 until: Mon Dec 16 16:57:33 MET 207
Certificate fingerprints:
MD5: 80:C3:59:E2:EA:05:D5:B8:67:CF:55:F6:1C:7F:AE:F6
SHA1: 82:34:F8:A2:44:B2:A9:AB:BB:15:B0:0D:7B:17:4C:98:5A:27:B9:02
Trust this certificate? [no]: yes
Certificate was added to keystore
procedendo poi allo stesso modo per il certificato della sotto CA necessaria.
4. ricevuto il certificato firmato, occorre reimportarlo nel keystore:
keytool -import -keystore <file keystore> -alias <nome convenzionale> -file server.crt
56
