Simulazione di una Certification Authority

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 panorma 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:

1. Il nome a cui è intestato il certificato non corrispone 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 divalidità 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 si "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à.

torna su

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.

torna su

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:
  • il soggetto ha cambiato nome;
  • un impiegato lascia la compagnia che ha emesso il certificato;
  • 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 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).

torna su

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.

torna su

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.

torna su

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.

torna su

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).

Struttura del certificato

La struttura di un certificato digitale X.509 v3 è la seguente:

• Certificato
  • Versione
  • Numero seriale
  • ID dell'algoritmo
  • Ente emettitore
  • Validità
    • Non prima
    • Non dopo
  • Soggetto
  • Informazioni sulla chiave pubblica del soggetto
    • Algoritmo per l'utilizzo della chiave pubblica
    • Chiave pubblica
  • Codice identificativo univoco dell'emittente (facoltativo)
  • Codice identificativo univoco del soggetto (facoltativo)
  • 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 contententi 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 - vedi .p7c
• .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.

torna su

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, ammeno 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
  

  torna su

  Sequenza di installazione

  1. Scaricare il file ISO dal link precedente
  2. Masterizzare l'immagine del CD
  3. Modificare il boot di avvio dal bios in modo da priorizzare il CD-ROM
  4. Inserire il CD nel driver e riavviare il PC
  5. A questo punto partirà uno script di configurazione automaticamente che permette di personalizzare la propria CA

torna su

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 la nuova release 9.3rc1 la quale 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;
• Firestarter: 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.

torna su

Sequenza di installazione

Tralascio al riguardo l'installazione di tutti i software necessari e mi soffermo in prevalenza sull'installazione di OpenCA.

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-httpd-user=ca --with-httpd-group=users --with-ca-organization="CaGroup" --with-ca-locality=Salerno --with-ca-country=IT --with-service-mail-account=ca@isp1.org --with-hierarchy-level=ra --with-module prefix=/usr/local/OpenRA/modules --with-openssl-prefix=/etc/ssl --with-hhtpd-fs-prefix=/etc/apache2 --with-language=it_IT --disable-rbac --enable-ocspd --with-openca-prefix=/usr/local/OpenRA/OpenCA --with-etc-prefix=/usr/local/OpenRA/OpenRA/etc --with-httpd-fs-prefix=/usr/local/OpenRA/httpd --with-node-prefix=ra-node
  

• --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
• --with-service-mail-account=ca@isp1.org 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

• --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

• make per compilare
• make install-offline per installare tutti i moduli per la CA

• 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 openca to openca per garantire all'utente openca tutti i permessi di accesso al database openca

Una volta compeltata questa fase

# 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
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'harddisk e che alcune direstory 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
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 scritp configure_etc.sh il quale configurerà la nostra CA e RA su come abbiamo settato il file config.xml.

torna su

Configurazione SendMail

Ora bisogna settare SendMail per permettegli di mandare le email. Per prima cosa bisogna create 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:

ca: ca@isp1.org
root: ca@isp1.org
news: ca@isp1.org

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:

kill `head -1 /var/run/sendmail.pid`
/usr/bin/sendmail -bd -os

torna su

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

torna su

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:
   1. Encryption algorithm (des,des3,idea):des3
   2. Asymmetric algorithm (rsa, dsa):rsa
   3. 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 mostrarà 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.
    Clicca su OK

torna su

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"
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.

torna su

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 cerificato (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.

torna su

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

torna su

Certificati utenti

Sottomissione di una richiesta di certificato

L’OpenCA, per come l'abbiampo 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

torna su

Approvazione del certificato

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”.

torna su

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.

torna su

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->)

   torna su

Ottenere il certificato root

1. Connettiti a openca-livecd.dhcp-subdomain.your.domain/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.

torna su

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.

torna su

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

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 è 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 e-mail.

Cliccando su Request a certificate viene visualizzata una form nella quale inserire tutti i dati

Dopo aver compilato e sottomessa la form, viene visualizzata una schermata riassuntiva

Infine viene presentata la schermata conclusiva che da all'utente la possibilità di spampare tutti i dati.

torna su

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.

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;

• 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 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:

  • i certificati validi (tramite il link Valid) di cui vengono specificati il seriale, il nome, l’e-mail ed il ruolo;

  • i certificati scaduti (tramite il link Expired) di cui sono specificati il seriale, il nome, l’e-mail ed il ruolo;

  • la lista dei certificati sospesi (tramite il link Suspended) dei quali sono specificati il seriale, il nome, l’e-mail ed il ruolo;

  • 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:

  • inizializzazione del database (vengono mostrate le istruzioni sql);

  • 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);

  • inizializzazione della richiesta (permette di stabilire i campi necessari per una richiesta di certificazione alla CA);

  • setup del certificato;

  • 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:

  • generare una nuova richiesta;

  • modificare la richiesta;

  • rilasciare il certificato;

  • scaricare il certificato.

• 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:

  • generare una nuova richiesta;

  • modificare la richiesta;

  • rilasciare il certificato;

  • 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.

torna su

Tuning

Servizi Richiesti

La CA necessitava della registrazione del dominio “https://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.

torna su

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 email a ISP2 ca@isp1.org.

torna su

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.

torna su

Prima commessa

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.

torna su

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.

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.

torna su

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.

  

• 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.

  

• Servizi di directory replicati: in questo 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.

  

• 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.

torna su

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, 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

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

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 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 
interfacce e porta 389
       -n <nome_servizio>
Specifica il nome del servizio.Default=slapd
       -l <syslog-utente-locale>
Specifica l’utente abilitato al syslog

torna su

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.

torna su

Autenticazione con LDAP usando openLDAP e PAM

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

torna su

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.

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

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.

torna su

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     pam_unix.so

account    required     pam_unix.so

password   required     pam_unix.so

session    required     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.
Per effettuare dei cambiamenti occorre modificare  il file /etc/pam.d/ssh.

auth       required     /lib/security/pam_nologin.so

auth       sufficient   /lib/security/pam_ldap.so

auth       required     /lib/security/pam_pwdb.so shadow nodelay

account    sufficient   /lib/security/pam_ldap.so

account    required     /lib/security/pam_pwdb.so

password   required     /lib/security/pam_cracklib.so

password   required     /lib/security/pam_pwdb.so shadow nullok use_authtok

session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022

session    required     /lib/security/pam_pwdb.so

torna su

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    3 redsteel users        1024 Feb 27 05:44 redsteel

drwxr-sr-x    5 rob      users        1024 May 27 13:54 rob

drwxr-sr-x    2 robert   users        1024 Sep 12  1999 robert

drwxr-sr-x    5 rslomkow users        1024 Jul 15 19:40 rslomkow

drwxr-sr-x    3 10002    users        1024 Jun 22  1999 sam

drwxr-sr-x   85 10011    users        7168 Jul 24 12:09 simon

drwxr-sr-x    2 10301    users        1024 Jun 30 17:53 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    3 redsteel users        1024 Feb 27 05:44 redsteel

drwxr-sr-x    5 rob      users        1024 May 27 13:54 rob

drwxr-sr-x    2 robert   users        1024 Sep 12  1999 robert

drwxr-sr-x    5 rslomkow users        1024 Jul 15 19:40 rslomkow

drwxr-sr-x    3 sam      users        1024 Jun 22  1999 sam

drwxr-sr-x   85 simon    users        7168 Jul 24 12:09 simon

drwxr-sr-x    2 stephane users        1024 Jun 30 17:53 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.

torna su

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

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.

torna su

Architettura del server LDAP

L’architettura del server LDAP  è strutturata nel seguente modo :

• daemon LDAP chiamato slapd
• Scelta dei database
• SHELL  : interfaccia db per comandi UNIX
• PASSWORD : semplice file di paswd
• SQL  : che mappa sql a ldap
• Più instanza di database
• Controllo degli accessi

Figura 13

torna su

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.

torna su

Installazione

Prerequisiti
L’applicazione server richiede le librerie SSL e le librerie LDAP
Mysql
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/iplanet-ldap-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  --enable-rewrite   --enable-dav
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  --with-ldap-dir=/usr/local/iplanet-ldap-sdk.5/
# make
# make install

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

torna su

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

torna su

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  creare la directory e settare i permessi usando il seguente comando :

# cd /usr/local/apache
  # mkdir var
  # chmod -R 755 var/
  # chown -R nobody var/
# chgrp -R nobody var/

torna su

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
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>

torna su

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:

torna su

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

torna su

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 .

torna su

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.

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>

torna su

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.

torna su

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.
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.6-1.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 --enable-shared=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 --with-apxs=/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

torna su

Creazione e installazione certificato

1. 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:
   installare il modulo mod_ssl (di solito già presente nelle distribuzioni classiche) o installare la versione Apache-SSL.
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
   Country Name IT
   State or Province Name <enter>
   Locality Name <enter>
   Organization Name caGroup
   Organizational Unit Name <enter>
   Common Name nome DNS completo del server o del virtual host
   Email Address il vostro indirizzo

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

   - 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.
   

torna su

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
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 la stessa sorgente per ogni nuova connessione:
SSLRandomSeed connect builtin
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
Usa i semafori di sistema:
SSLMutex sem

torna su

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:
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-CBC3-MD5: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-DES-CBC-SHA: EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:
EXP1024-RC4-MD5:EDH-RSA-DES-CBC-SHA: EDH-DSS-DES-CBC-SHA:DES-CBC-SHA: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-RC4-MD5
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

torna su

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.

torna su

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

torna su

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
   

torna su