Certificati digitali - Sicurezza su reti 2
annuncio pubblicitario
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
