new file mode 100644
--- /dev/null
+++ b/xml/it/docs/http/configuring_https_servers.xml
@@ -0,0 +1,521 @@
+<!--
+  Copyright (C) Igor Sysoev
+  Copyright (C) Nginx, Inc.
+  -->
+
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="Configurazione di server HTTPS"
+         link="/it/docs/http/configuring_https_servers.html"
+         lang="it"
+         translator="Angelo Papadia"
+         rev="6"
+         author="Igor Sysoev"
+         editor="Brian Mercer">
+
+<section>
+
+<para>
+Per configurare un server HTTPS, bisogna configurare il parametro
+<literal>ssl</literal> nel
+<link doc="ngx_http_core_module.xml" id="listen">socket in ascolto</link>
+del blocco <link doc="ngx_http_core_module.xml" id="server"/>,
+e specificare dove sono i file del certificato del server e della relativa
+chiave private:
+
+<programlisting>
+server {
+    listen              443 <b>ssl</b>;
+    server_name         www.example.com;
+    ssl_certificate     <b>www.example.com.crt</b>;
+    ssl_certificate_key <b>www.example.com.key</b>;
+    ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
+    ssl_ciphers         HIGH:!aNULL:!MD5;
+    ...
+}
+</programlisting>
+
+Il certificato del server e' pubblico: e' inviato a tutti i client che
+si connettono al server; la chiave privata al contrario non e' pubblica,
+e dovrebbe essere salvata in un file con restrizioni d'accesso, e
+comunque non leggibile dal processo master di nginx.
+In alternativa, la chiave privata puo' essere salvata nel medesimo file
+del certificato:
+
+<programlisting>
+    ssl_certificate     www.example.com.cert;
+    ssl_certificate_key www.example.com.cert;
+</programlisting>
+
+pure in questo caso i diritti d'accesso al file dovrebbero essere ristretti.
+Anche quando certificato e chiave privata sono salvati entrambi
+in un unico file, solo il certificato e' inviato al client.
+</para>
+
+<para>
+Le direttive <link doc="ngx_http_ssl_module.xml" id="ssl_protocols"/> e
+<link doc="ngx_http_ssl_module.xml" id="ssl_ciphers"/> possono essere usate
+per limitare l'uso alle sole versioni e cifrature forti di SSL/TLS nelle
+connessioni.
+nginx usa per default “<literal>ssl_protocols SSLv3 TLSv1</literal>” e
+“<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>” sin dalla versione 1.0.5,
+per cui una configurazione esplicita ha senso solo per le versioni di ngnix
+piu' vecchie. Dalle versioni 1.1.13 e 1.0.12 nginx usa per default
+“<literal>ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2</literal>”.
+</para>
+
+<para>
+La modalita' di cifratura CBC e' potenzialmente vulnerabile ad una serie
+di attacchi, in particolare ad un attacco BEST (vedi
+<link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>).
+La configurazione della cifratura puo' essere modificata in maniera da
+utilizzare RC4-SHA:
+
+<programlisting>
+    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
+    ssl_prefer_server_ciphers on;
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="optimization" name="Ottimizzazione di server HTTPS">
+
+<para>
+Le operazioni SSL utilizzano pesantemente la CPU. Su sistemi
+multiprocessore e' bene avviare processi worker in numero almeno pari a
+quello dei core.
+L'operazione piu' gravosa per la CPU e' l'handshake SSL.
+Ci sono due modi per minimizzare il numero di tali operazioni per client:
+il primo consiste nell'abilitare connessioni keepalive per inviare diverse
+richieste tramite un'unica connessione; il secondo prevede di riutilizzare
+i parametri della sessione SSL in maniera tale da evitare l'handshake SSL
+per connessioni parallele e susseguenti.
+Le sessioni sono salvate in una cache di sessione SSL, condivisa fra i
+worker e configurata dalla direttiva
+<link doc="ngx_http_ssl_module.xml" id="ssl_session_cache"/>.
+
+Un megabyte di cache contiene circa 4000 sessioni. Il timeout di default della
+cache e' di 5 minuti; puo' essere aumentato intervenendo sulla direttiva
+<link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>.
+Segue una configurazione di esempio ottimizzata per un sistema multicore con
+10 megabyte di cache di sessione condivisa:
+
+<programlisting>
+<b>worker_processes auto</b>;
+
+http {
+    <b>ssl_session_cache   shared:SSL:10m</b>;
+    <b>ssl_session_timeout 10m</b>;
+
+    server {
+        listen              443 ssl;
+        server_name         www.example.com;
+        <b>keepalive_timeout   70</b>;
+
+        ssl_certificate     www.example.com.crt;
+        ssl_certificate_key www.example.com.key;
+        ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
+        ssl_ciphers         HIGH:!aNULL:!MD5;
+        ...
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="chains" name="Catene di certificati SSL">
+
+<para>
+Capita talvolta che alcuni certificati server firmati da autorita' di
+certificazione ben note siano tranquillamente accettati da alcuni browser,
+ma mostrino invece problemi con altri. Cio' succede quando' l'autorita'
+emittente ha firmato il certificato usandone uno intermedio che non e'
+presente nell'elenco delle autorita' di certificazione distribuito con
+uno specifico browser.
+In tal caso l'autorita' fornisce un gruppo di certificati che dovrebbero
+essere concatenati al certificato server firmato.
+Il certificato server deve comparire prima dei certificati concatenati
+nel file risultante:
+
+<programlisting>
+$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
+</programlisting>
+
+Il file che ne deriva va usato con la  direttiva
+<link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>:
+
+<programlisting>
+server {
+    listen              443 ssl;
+    server_name         www.example.com;
+    ssl_certificate     www.example.com.chained.crt;
+    ssl_certificate_key www.example.com.key;
+    ...
+}
+</programlisting>
+
+Se il certificato server ed il gruppo di certificati sono stati concatenati
+nell'ordine sbagliato, nginx non riuscira' a partire e mostrera' il
+seguente messaggio di errore:
+
+<programlisting>
+SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
+   (SSL: error:0B080074:x509 certificate routines:
+    X509_check_private_key:key values mismatch)
+</programlisting>
+
+dato che nginx ha tentato di usare la chiave privata non con il certificato
+server ma con il primo certificato del gruppo.
+</para>
+
+<para>
+Di solito i browser salvano i certificati intermedi che ricevono se sono
+firmati da autorita' di certificazione riconosciute, per cui browser molto
+usati potrebbero gia' avere i certificati intermedi richiesti, e quindi
+non avere problemi anche quando ricevono un certificato privo della
+relativa concatenazione di certificati.
+Comunque, per assicurare che il server invii la concatenazione di certificati
+completa, e' possibile usare da linea di comando il programma
+<command>openssl</command>, ad esempio:
+
+<programlisting>
+$ openssl s_client -connect www.godaddy.com:443
+...
+Certificate chain
+ 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
+     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
+     /OU=MIS Department/<b>CN=www.GoDaddy.com</b>
+     /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
+   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
+     /OU=http://certificates.godaddy.com/repository
+     /CN=Go Daddy Secure Certification Authority
+     /serialNumber=07969287
+ 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
+     /OU=http://certificates.godaddy.com/repository
+     /CN=Go Daddy Secure Certification Authority
+     /serialNumber=07969287
+   i:/C=US/O=The Go Daddy Group, Inc.
+     /OU=Go Daddy Class 2 Certification Authority
+ 2 s:/C=US/O=The Go Daddy Group, Inc.
+     /OU=Go Daddy Class 2 Certification Authority
+   i:/L=ValiCert Validation Network/O=<b>ValiCert, Inc.</b>
+     /OU=ValiCert Class 2 Policy Validation Authority
+     /CN=http://www.valicert.com//emailAddress=info@valicert.com
+...
+</programlisting>
+
+In questo esempio, il soggetto (“<i>s</i>”, vale a dire "<i>subject</i>")
+del certificato server #0 <literal>www.GoDaddy.com</literal> e' firmato da
+un emittente (“<i>i</i>”, vale a dire "<i>issuer</i>") che a sua volta e'
+il soggetto del certificato #1, il quale e' firmato da un emittente che e'
+il soggetto del certificato #2, che e' finalmente firmato dalla autorita'
+di certificazione ben nota <i>ValiCert, Inc.</i>, il cui certificato e'
+presente nella base dati precaricata del browser
+("che al mercato mio padre compro'").
+</para>
+
+<para>
+Se il gruppo di certificati non fosse stato aggiunto, sarebbe stato
+visualizzato il solo certificato #0.
+</para>
+
+</section>
+
+
+<section id="single_http_https_server" name="Un server unico per HTTP e HTTPS">
+
+<para>
+E' possibile configurare un singolo server che tratti sia richieste HTTP,
+sia richieste HTTPS:
+
+<programlisting>
+server {
+    listen              80;
+    listen              443 ssl;
+    server_name         www.example.com;
+    ssl_certificate     www.example.com.crt;
+    ssl_certificate_key www.example.com.key;
+    ...
+}
+</programlisting>
+
+<note>
+Prima della versione 0.7.14, SSL non poteva essere abilitato
+selettivamente per singoli socket in ascolto, come nell'esempio
+precedente: SSL poteva solo essere abilitato per l'intero server,
+usando la direttiva <link doc="ngx_http_ssl_module.xml" id="ssl"/>,
+e rendendo quindi impossibile la configurazione di un server
+unico per HTTP e HTTPS.
+Il parametro <literal>ssl</literal> della direttiva
+<link doc="ngx_http_core_module.xml" id="listen"/> e' stato aggiunto
+per risolvere questo problema. L'uso della direttiva
+<link doc="ngx_http_ssl_module.xml" id="ssl"/>
+e' pertanto sconsigliato nelle versioni recenti.
+</note>
+</para>
+
+</section>
+
+
+<section id="name_based_https_servers" name="Server HTTPS name-based">
+
+<para>
+Quando si configurano due o piu' server HTTPS in ascolto su un singolo
+indirizzo IP, sorge spesso un problema:
+
+<programlisting>
+server {
+    listen          443 ssl;
+    server_name     www.example.com;
+    ssl_certificate www.example.com.crt;
+    ...
+}
+
+server {
+    listen          443 ssl;
+    server_name     www.example.org;
+    ssl_certificate www.example.org.crt;
+    ...
+}
+</programlisting>
+
+Con questa configurazione un browser riceve il certificato del server di default,
+vale a dire <literal>www.example.com</literal>, indipendentemente da quale sia
+il nome del server richiesto. Cio' e' causato dal comportamento del protocollo
+SSL: la connessione SSL si stabilisce prima che il browser invii una richiesta
+HTTP, percio' quando nginx ancora non sa quale sara' il nome del server richiesto;
+per tale ragione, non puo' fare altro che offrire il certificato del server di default.
+</para>
+
+<para>
+Il metodo classico per risolvere questo problema consiste nell'assegnare
+un indirizzo IP distinto a ciascun server HTTPS:
+
+<programlisting>
+server {
+    listen          192.168.1.1:443 ssl;
+    server_name     www.example.com;
+    ssl_certificate www.example.com.crt;
+    ...
+}
+
+server {
+    listen          192.168.1.2:443 ssl;
+    server_name     www.example.org;
+    ssl_certificate www.example.org.crt;
+    ...
+}
+</programlisting>
+</para>
+
+
+<section id="certificate_with_several_names"
+         name="Un certificato SSL con molti nomi">
+
+<para>
+Ci sono altre maniere tramite cui condividere un singolo indirizzo IP
+fra molti server HTTPS, tutte comunque non prive di problemi.
+Ad esempio, e' possibile usare un certificato con diversi nomi di server
+nel campo SubjectAltName, per esempio
+<literal>www.example.com</literal> and <literal>www.example.org</literal>,
+tuttavia la lunghezza del campo SubjectAltName e' limitata.
+</para>
+
+<para>
+Un'altra tecnica prevede l'uso di un certificato il cui nome e' definito con
+caratteri jolly, per esempio <literal>*.example.org</literal>.
+Un certificato con caratteri jolly va bene per tutti i sottodomini del
+dominio specificato, ma per un solo livello: in questo caso ad esempio
+verra' riconosciuta corrispondenza con <literal>www.example.org</literal>,
+ma non con <literal>example.org</literal> e <literal>www.sub.example.org</literal>.
+I due metodi mostrati possono essere combinati: nel campo SubjectAltName
+un certificato puo' contenere sia nomi esatti sia nomi con caratteri jolly,
+ad esempio <literal>example.org</literal> e <literal>*.example.org</literal>.
+</para>
+
+<para>
+Nel caso in cui si usi un certificato con nomi multipli, e' bene
+indicare la posizione del relativo file e della chiave nel livello
+<i>http</i> della configurazione, in maniera da avere una singola
+copia in memoria da far ereditare a tutti i server:
+
+<programlisting>
+ssl_certificate     common.crt;
+ssl_certificate_key common.key;
+
+server {
+    listen          443 ssl;
+    server_name     www.example.com;
+    ...
+}
+
+server {
+    listen          443 ssl;
+    server_name     www.example.org;
+    ...
+}
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="sni" name="Server Name Indication">
+
+<para>
+Una soluzione piu' generale per l'uso di server HTTPS multipli su un singolo
+indirizzo IP e' data dalla
+<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">estensione
+TLS Server Name Indication</link> (SNI, RFC 6066), che consente ad un
+browser di indicare il nome del server richiesto durante l'handshake SSL e,
+percio', permette al server di sapere quale certificato dovrebbe essere
+usato durante la connessione. Purtroppo, SNI ha un supporto piuttosto
+limitato nei browser; al momento e' supportato a partire dalle seguenti
+versioni:
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+Opera 8.0;
+</listitem>
+
+<listitem>
+MSIE 7.0 (ma solo su Windows Vista o superiore);
+</listitem>
+
+<listitem>
+Firefox 2.0 e altri browser che usano Mozilla Platform rv:1.8.1;
+</listitem>
+
+<listitem>
+Safari 3.2.1 (la versione per Windows supporta SNI su Vista o superiore);
+</listitem>
+
+<listitem>
+Chrome (la versione per Windows supporta SNI su Vista o superiore).
+</listitem>
+
+</list>
+<note>
+Con SNI e' possibile passare solo nomi di dominio, tuttavia alcuni browser
+potrebbero erroneamente consentire di passare come nome anche l'indirizzo
+IP del server.
+E' bene comunque non fare affidamento su questo comportamento.
+</note>
+</para>
+
+<para>
+Per poter usare SNI in nginx, e' necessario che sia supportato sia nella
+libreria OpenSSL con cui il binario e' stato compilato, sia nella
+libreria a cui e' linkato dinamicamente in esecuzione.
+OpenSSL supporta SNI sin dalla versione 0.9.8f, a patto che sia stata
+compilata con l'opzione di configurazione <nobr>“--enable-tlsext”</nobr>;
+dalla versione 0.9.8j tale opzione e' abilitata per default.
+Se nginx e' compilato con il supporto a SNI, allora l'esecuzione con
+il parametro “-V” mostra:
+
+<programlisting>
+$ nginx -V
+...
+TLS SNI support enabled
+...
+</programlisting>
+
+Di contro, se nginx e' stato compilato con il supporto a SNI, ma la libreria
+OpenSSL a cui e' linkato dinamicamente ne e' priva, viene mostrato:
+
+<programlisting>
+nginx was built with SNI support, however, now it is linked
+dynamically to an OpenSSL library which has no tlsext support,
+therefore SNI is not available
+</programlisting>
+</para>
+
+</section>
+
+</section>
+
+
+<section id="compatibility" name="Compatibilita'">
+
+<para>
+<list type="bullet">
+
+<listitem>
+Il parametro “-V” mostra lo stato del supporto a SNI
+dalla versione 0.8.21 e 0.7.62 in poi.
+</listitem>
+
+<listitem>
+Il parametro <literal>ssl</literal> della direttiva
+<link doc="ngx_http_core_module.xml" id="listen"/>
+e' supportato
+dalla versione 0.7.14 in poi;
+prima della versione 0.8.21 poteva essere specificato solo
+insieme al parametro <literal>default</literal>.
+</listitem>
+
+<listitem>
+SNI e' supportato
+dalla versione 0.5.32 in poi.
+</listitem>
+
+<listitem>
+La cache condivisa di sessione SSL e' supportata
+dalla versione 0.5.6 in poi.
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+Versioni 0.7.65, 0.8.19 e successive: i protocolli SSL default sono SSLv2, TLSv1,
+e TLSv1.2 (se supportati dalla libreria OpenSSL).
+</listitem>
+
+<listitem>
+Versioni 0.7.64, 0.8.18 e precedenti: i protocolli SSL default sono SSLv2,
+SSLv3, e TLSv1.
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+Versioni 1.0.5 e successive: i sistemi di cifratura SSL default sono
+“<literal>HIGH:!aNULL:!MD5</literal>”.
+</listitem>
+
+<listitem>
+Versioni 0.7.65, 0.8.20 e successive: i sistemi di cifratura SSL default sono
+“<literal>HIGH:!ADH:!MD5</literal>”.
+</listitem>
+
+<listitem>
+Versione 0.8.19: i sistemi di cifratura SSL default sono
+“<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</literal>”.
+</listitem>
+
+<listitem>
+Versioni 0.7.64, 0.8.18 e precedenti: i sistemi di cifratura SSL default sono<br/>
+“<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</literal>”.
+</listitem>
+
+</list>
+</para>
+
+
+</section>
+
+
+</article>