6 999
contributi
Autorità di certificazione locale: differenze tra le versioni
Autorità di certificazione locale (visualizza wikitesto)
Versione delle 21:22, 27 gen 2010
, 27 gen 2010nessun oggetto della modifica
Nessun oggetto della modifica |
S3v (discussione | contributi) Nessun oggetto della modifica |
||
| Riga 8: | Riga 8: | ||
==Installazione e Configurazione di Openssl== | ==Installazione e Configurazione di Openssl== | ||
Per installare la libreria [http://it.wikipedia.org/wiki/Secure_Sockets_Layer:Link SSL] e gli applicativi necessari alla creazione di chiavi e certificati dare il comando: | Per installare la libreria [http://it.wikipedia.org/wiki/Secure_Sockets_Layer:Link SSL] e gli applicativi necessari alla creazione di chiavi e certificati dare il comando: | ||
<pre>apt-get install openssl</pre> | <pre># apt-get install openssl</pre> | ||
Per minimizzare la quantità di informazioni richieste durante la creazione di chiavi e certificati, può | Per minimizzare la quantità di informazioni richieste durante la creazione di chiavi e certificati, può | ||
| Riga 72: | Riga 72: | ||
===Generazione di una Certificate Signing Request (CSR)=== | ===Generazione di una Certificate Signing Request (CSR)=== | ||
Con la chiave creata nella sezione [[#Creazione della chiave (server)|Creazione della chiave (server)]] generiamo una richiesta di firma per il certificato lato server che stiamo creando: | Con la chiave creata nella sezione [[#Creazione della chiave (server)|Creazione della chiave (server)]] generiamo una richiesta di firma per il certificato lato server che stiamo creando: | ||
<pre> | <pre># openssl req -config /etc/ssl/openssl.cnf -new -key private/server.key -out server.csr | ||
Enter pass phrase for private/server.key:</pre> | Enter pass phrase for private/server.key:</pre> | ||
| Riga 93: | Riga 93: | ||
Importanti sono le seguenti direttive: | Importanti sono le seguenti direttive: | ||
; SSLCACertificatePath: indica la directory dove sono contenuti certificati e ''CRL'' (''Certificate Revocation List'') | ; SSLCACertificatePath: indica la directory dove sono contenuti certificati e ''CRL'' (''Certificate Revocation List'') | ||
Esempio: < | Esempio: <code>SSLCACertificatePath /etc/ssl</code> | ||
; SSLCertificateFile: indica il certificato lato server per mezzo del quale i dati vengono cifrati. Secondo quanto riportato in questa guida esso corrisponde al file /etc/ssl/certs/server.crt. | ; SSLCertificateFile: indica il certificato lato server per mezzo del quale i dati vengono cifrati. Secondo quanto riportato in questa guida esso corrisponde al file <code>/etc/ssl/certs/server.crt</code>. | ||
Esempio: < | Esempio: <code>SSLCertificateFile server.crt</code> | ||
; SSLCertificateKeyFile: indica la chiave privata del certificato lato server. Secondo quanto qui riportato essa corrisponde al file | ; SSLCertificateKeyFile: indica la chiave privata del certificato lato server. Secondo quanto qui riportato essa corrisponde al file <code>/etc/ssl/private/server.key</code>. Per maggiori informazioni vedere l'osservazione sulle chiavi private fatta nella sezione [[#Certificato lato server|Certificato lato server]]. | ||
Esempio: < | Esempio: <code>SSLCertificateKeyFile server.key</code> | ||
; SSLVerifyClient: definisce la certificazione di cui i client necessitano per autenticarsi. | ; SSLVerifyClient: definisce la certificazione di cui i client necessitano per autenticarsi. | ||
Esempio: < | Esempio: <code>SSLVerifyClient 2 #The client must present a valid certificate.</code> | ||
; SSLVerifyDepth: nel nostro caso va impostata a 1 in quanto ci fidiamo solo di certificati firmati dalla nostra CA locale. | ; SSLVerifyDepth: nel nostro caso va impostata a 1 in quanto ci fidiamo solo di certificati firmati dalla nostra CA locale. | ||
Esempio: < | Esempio: <code>SSLVerifyDepth 1</code> | ||
;SSLUseCRL: i certificati client sono controllati basandosi sull'appropriata ''CRL''. La ''CRL'' deve essere in formato ''PEM''. è necessario un link simbolico alla ''CRL'' posto all'interno del percorso indicato dalla direttiva '''SSLCACerificatePath'''. Non prende argomenti. Il percorso della ''CRL'' è specificato da '''SSLCACertificatePath.''' I link simbolici alle ''CRL'' hanno la forma < | ;SSLUseCRL: i certificati client sono controllati basandosi sull'appropriata ''CRL''. La ''CRL'' deve essere in formato ''PEM''. è necessario un link simbolico alla ''CRL'' posto all'interno del percorso indicato dalla direttiva '''SSLCACerificatePath'''. Non prende argomenti. Il percorso della ''CRL'' è specificato da '''SSLCACertificatePath.''' I link simbolici alle ''CRL'' hanno la forma <code><hash>.r<number>, dove <hash></code> è l'hash del file contenente la ''CRL''. La sezione [[#Apache e CRL | Apache e CRL]] spiega come creare link simbolici di tale tipo. | ||
Esempio: < | Esempio: <code>SSLUseCRL</code> | ||
; SSLOnRevocationSetEnv: se il client presenta un certificato revocato, la sessione SSL è stabilita e la variabile indicata è impostata. L'idea è di gestire con uno script questo tipo d'errore. Per la descrizione delle altre direttive del tipo ''SSLOn*SetEnv'' riferirsi alla documentazione di ''apache''. | ; SSLOnRevocationSetEnv: se il client presenta un certificato revocato, la sessione SSL è stabilita e la variabile indicata è impostata. L'idea è di gestire con uno script questo tipo d'errore. Per la descrizione delle altre direttive del tipo ''SSLOn*SetEnv'' riferirsi alla documentazione di ''apache''. | ||
Esempio: < | Esempio: <code>SSLOnRevocationSetEnv SSL_REVOKED</code> | ||
===Apache e CRL=== | ===Apache e CRL=== | ||
| Riga 112: | Riga 112: | ||
Affinché ''apache-ssl'' sia informato sulla validità dei certificati, è necessario l'utilizzo delle direttive '''SSLCACertificatePath''' e '''SSLUseCRL'''. La prima indica il percorso in cui cercare la ''CRL'', la seconda istruisce il demone a fare uso della ''CRL''. | Affinché ''apache-ssl'' sia informato sulla validità dei certificati, è necessario l'utilizzo delle direttive '''SSLCACertificatePath''' e '''SSLUseCRL'''. La prima indica il percorso in cui cercare la ''CRL'', la seconda istruisce il demone a fare uso della ''CRL''. | ||
La ''CRL'' deve essere puntata da un link simbolico della forma < | La ''CRL'' deve essere puntata da un link simbolico della forma <code><hash>.r<number></code> presente all'interno del percorso indicato dalla direttiva '''SSLCACertificatePath''' (p.e. <code>/etc/ssl</code>): | ||
<pre> | <pre> | ||
# cd /etc/ssl | # cd /etc/ssl | ||
| Riga 140: | Riga 140: | ||
</VirtualHost> | </VirtualHost> | ||
</pre> | </pre> | ||
Quando è revocato un certificato client relativo al virtual host < | Quando è revocato un certificato client relativo al virtual host <code>x.y.z.w</code>, il risultato potrebbe non corrispondere a quanto voluto. Se si visitasse l'URL <code>https://x.y.z.w</code> con il browser in cui è installato il certificato revocato, si noterebbe che l'accesso non verrebbe impedito. Questo accade perché '''SSLOnRevocationSetEnv SSL_REVOKED''' non nega l'accesso ai certificati revocati, ma imposta la variabile '''SSL_REVOKED''' a "YES" e la direttiva posta nel contesto ''server config'' ha valore anche per gli host virtuali. | ||
La soluzione è quella di commentare la direttiva nel contesto ''server config'' e attivarla, se serve, per ogni singolo host virtuale. | La soluzione è quella di commentare la direttiva nel contesto ''server config'' e attivarla, se serve, per ogni singolo host virtuale. | ||