Mercurial > hg > nginx-site
annotate xml/it/docs/http/configuring_https_servers.xml @ 2754:3975b5ffd38e
Linux packages: removed Ubuntu 20.10 'groovy' due to EOL.
author | Konstantin Pavlov <thresh@nginx.com> |
---|---|
date | Tue, 03 Aug 2021 12:54:38 +0300 |
parents | 6303d4e343a8 |
children |
rev | line source |
---|---|
1018 | 1 <!-- |
2 Copyright (C) Igor Sysoev | |
3 Copyright (C) Nginx, Inc. | |
4 --> | |
5 | |
6 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> | |
7 | |
8 <article name="Configurazione di server HTTPS" | |
9 link="/it/docs/http/configuring_https_servers.html" | |
10 lang="it" | |
11 translator="Angelo Papadia" | |
12 rev="6" | |
13 author="Igor Sysoev" | |
14 editor="Brian Mercer"> | |
15 | |
16 <section> | |
17 | |
18 <para> | |
19 Per configurare un server HTTPS, bisogna configurare il parametro | |
20 <literal>ssl</literal> nel | |
21 <link doc="ngx_http_core_module.xml" id="listen">socket in ascolto</link> | |
22 del blocco <link doc="ngx_http_core_module.xml" id="server"/>, | |
23 e specificare dove sono i file del certificato del server e della relativa | |
24 chiave private: | |
25 | |
26 <programlisting> | |
27 server { | |
28 listen 443 <b>ssl</b>; | |
29 server_name www.example.com; | |
30 ssl_certificate <b>www.example.com.crt</b>; | |
31 ssl_certificate_key <b>www.example.com.key</b>; | |
32 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; | |
33 ssl_ciphers HIGH:!aNULL:!MD5; | |
34 ... | |
35 } | |
36 </programlisting> | |
37 | |
38 Il certificato del server e' pubblico: e' inviato a tutti i client che | |
39 si connettono al server; la chiave privata al contrario non e' pubblica, | |
40 e dovrebbe essere salvata in un file con restrizioni d'accesso, e | |
41 comunque non leggibile dal processo master di nginx. | |
42 In alternativa, la chiave privata puo' essere salvata nel medesimo file | |
43 del certificato: | |
44 | |
45 <programlisting> | |
46 ssl_certificate www.example.com.cert; | |
47 ssl_certificate_key www.example.com.cert; | |
48 </programlisting> | |
49 | |
50 pure in questo caso i diritti d'accesso al file dovrebbero essere ristretti. | |
51 Anche quando certificato e chiave privata sono salvati entrambi | |
52 in un unico file, solo il certificato e' inviato al client. | |
53 </para> | |
54 | |
55 <para> | |
56 Le direttive <link doc="ngx_http_ssl_module.xml" id="ssl_protocols"/> e | |
57 <link doc="ngx_http_ssl_module.xml" id="ssl_ciphers"/> possono essere usate | |
58 per limitare l'uso alle sole versioni e cifrature forti di SSL/TLS nelle | |
59 connessioni. | |
60 nginx usa per default “<literal>ssl_protocols SSLv3 TLSv1</literal>” e | |
61 “<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>” sin dalla versione 1.0.5, | |
1053
6303d4e343a8
Updated the Italian translation.
Vladimir Homutov <vl@nginx.com>
parents:
1018
diff
changeset
|
62 per cui una configurazione esplicita ha senso solo per le versioni di nginx |
1018 | 63 piu' vecchie. Dalle versioni 1.1.13 e 1.0.12 nginx usa per default |
64 “<literal>ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2</literal>”. | |
65 </para> | |
66 | |
67 <para> | |
68 La modalita' di cifratura CBC e' potenzialmente vulnerabile ad una serie | |
69 di attacchi, in particolare ad un attacco BEST (vedi | |
70 <link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>). | |
71 La configurazione della cifratura puo' essere modificata in maniera da | |
72 utilizzare RC4-SHA: | |
73 | |
74 <programlisting> | |
75 ssl_ciphers RC4:HIGH:!aNULL:!MD5; | |
76 ssl_prefer_server_ciphers on; | |
77 </programlisting> | |
78 </para> | |
79 | |
80 </section> | |
81 | |
82 | |
83 <section id="optimization" name="Ottimizzazione di server HTTPS"> | |
84 | |
85 <para> | |
86 Le operazioni SSL utilizzano pesantemente la CPU. Su sistemi | |
87 multiprocessore e' bene avviare processi worker in numero almeno pari a | |
88 quello dei core. | |
89 L'operazione piu' gravosa per la CPU e' l'handshake SSL. | |
90 Ci sono due modi per minimizzare il numero di tali operazioni per client: | |
91 il primo consiste nell'abilitare connessioni keepalive per inviare diverse | |
92 richieste tramite un'unica connessione; il secondo prevede di riutilizzare | |
93 i parametri della sessione SSL in maniera tale da evitare l'handshake SSL | |
94 per connessioni parallele e susseguenti. | |
95 Le sessioni sono salvate in una cache di sessione SSL, condivisa fra i | |
96 worker e configurata dalla direttiva | |
97 <link doc="ngx_http_ssl_module.xml" id="ssl_session_cache"/>. | |
98 | |
99 Un megabyte di cache contiene circa 4000 sessioni. Il timeout di default della | |
100 cache e' di 5 minuti; puo' essere aumentato intervenendo sulla direttiva | |
101 <link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>. | |
102 Segue una configurazione di esempio ottimizzata per un sistema multicore con | |
103 10 megabyte di cache di sessione condivisa: | |
104 | |
105 <programlisting> | |
106 <b>worker_processes auto</b>; | |
107 | |
108 http { | |
109 <b>ssl_session_cache shared:SSL:10m</b>; | |
110 <b>ssl_session_timeout 10m</b>; | |
111 | |
112 server { | |
113 listen 443 ssl; | |
114 server_name www.example.com; | |
115 <b>keepalive_timeout 70</b>; | |
116 | |
117 ssl_certificate www.example.com.crt; | |
118 ssl_certificate_key www.example.com.key; | |
119 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; | |
120 ssl_ciphers HIGH:!aNULL:!MD5; | |
121 ... | |
122 </programlisting> | |
123 </para> | |
124 | |
125 </section> | |
126 | |
127 | |
128 <section id="chains" name="Catene di certificati SSL"> | |
129 | |
130 <para> | |
131 Capita talvolta che alcuni certificati server firmati da autorita' di | |
132 certificazione ben note siano tranquillamente accettati da alcuni browser, | |
133 ma mostrino invece problemi con altri. Cio' succede quando' l'autorita' | |
134 emittente ha firmato il certificato usandone uno intermedio che non e' | |
135 presente nell'elenco delle autorita' di certificazione distribuito con | |
136 uno specifico browser. | |
137 In tal caso l'autorita' fornisce un gruppo di certificati che dovrebbero | |
138 essere concatenati al certificato server firmato. | |
139 Il certificato server deve comparire prima dei certificati concatenati | |
140 nel file risultante: | |
141 | |
142 <programlisting> | |
143 $ cat www.example.com.crt bundle.crt > www.example.com.chained.crt | |
144 </programlisting> | |
145 | |
146 Il file che ne deriva va usato con la direttiva | |
147 <link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>: | |
148 | |
149 <programlisting> | |
150 server { | |
151 listen 443 ssl; | |
152 server_name www.example.com; | |
153 ssl_certificate www.example.com.chained.crt; | |
154 ssl_certificate_key www.example.com.key; | |
155 ... | |
156 } | |
157 </programlisting> | |
158 | |
159 Se il certificato server ed il gruppo di certificati sono stati concatenati | |
160 nell'ordine sbagliato, nginx non riuscira' a partire e mostrera' il | |
161 seguente messaggio di errore: | |
162 | |
163 <programlisting> | |
164 SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed | |
165 (SSL: error:0B080074:x509 certificate routines: | |
166 X509_check_private_key:key values mismatch) | |
167 </programlisting> | |
168 | |
169 dato che nginx ha tentato di usare la chiave privata non con il certificato | |
170 server ma con il primo certificato del gruppo. | |
171 </para> | |
172 | |
173 <para> | |
174 Di solito i browser salvano i certificati intermedi che ricevono se sono | |
175 firmati da autorita' di certificazione riconosciute, per cui browser molto | |
176 usati potrebbero gia' avere i certificati intermedi richiesti, e quindi | |
177 non avere problemi anche quando ricevono un certificato privo della | |
178 relativa concatenazione di certificati. | |
179 Comunque, per assicurare che il server invii la concatenazione di certificati | |
180 completa, e' possibile usare da linea di comando il programma | |
181 <command>openssl</command>, ad esempio: | |
182 | |
183 <programlisting> | |
184 $ openssl s_client -connect www.godaddy.com:443 | |
185 ... | |
186 Certificate chain | |
187 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US | |
188 /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc | |
189 /OU=MIS Department/<b>CN=www.GoDaddy.com</b> | |
190 /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b) | |
191 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. | |
192 /OU=http://certificates.godaddy.com/repository | |
193 /CN=Go Daddy Secure Certification Authority | |
194 /serialNumber=07969287 | |
195 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. | |
196 /OU=http://certificates.godaddy.com/repository | |
197 /CN=Go Daddy Secure Certification Authority | |
198 /serialNumber=07969287 | |
199 i:/C=US/O=The Go Daddy Group, Inc. | |
200 /OU=Go Daddy Class 2 Certification Authority | |
201 2 s:/C=US/O=The Go Daddy Group, Inc. | |
202 /OU=Go Daddy Class 2 Certification Authority | |
203 i:/L=ValiCert Validation Network/O=<b>ValiCert, Inc.</b> | |
204 /OU=ValiCert Class 2 Policy Validation Authority | |
205 /CN=http://www.valicert.com//emailAddress=info@valicert.com | |
206 ... | |
207 </programlisting> | |
208 | |
209 In questo esempio, il soggetto (“<i>s</i>”, vale a dire "<i>subject</i>") | |
210 del certificato server #0 <literal>www.GoDaddy.com</literal> e' firmato da | |
211 un emittente (“<i>i</i>”, vale a dire "<i>issuer</i>") che a sua volta e' | |
212 il soggetto del certificato #1, il quale e' firmato da un emittente che e' | |
213 il soggetto del certificato #2, che e' finalmente firmato dalla autorita' | |
214 di certificazione ben nota <i>ValiCert, Inc.</i>, il cui certificato e' | |
215 presente nella base dati precaricata del browser | |
216 ("che al mercato mio padre compro'"). | |
217 </para> | |
218 | |
219 <para> | |
220 Se il gruppo di certificati non fosse stato aggiunto, sarebbe stato | |
221 visualizzato il solo certificato #0. | |
222 </para> | |
223 | |
224 </section> | |
225 | |
226 | |
227 <section id="single_http_https_server" name="Un server unico per HTTP e HTTPS"> | |
228 | |
229 <para> | |
230 E' possibile configurare un singolo server che tratti sia richieste HTTP, | |
231 sia richieste HTTPS: | |
232 | |
233 <programlisting> | |
234 server { | |
235 listen 80; | |
236 listen 443 ssl; | |
237 server_name www.example.com; | |
238 ssl_certificate www.example.com.crt; | |
239 ssl_certificate_key www.example.com.key; | |
240 ... | |
241 } | |
242 </programlisting> | |
243 | |
244 <note> | |
245 Prima della versione 0.7.14, SSL non poteva essere abilitato | |
246 selettivamente per singoli socket in ascolto, come nell'esempio | |
247 precedente: SSL poteva solo essere abilitato per l'intero server, | |
248 usando la direttiva <link doc="ngx_http_ssl_module.xml" id="ssl"/>, | |
249 e rendendo quindi impossibile la configurazione di un server | |
250 unico per HTTP e HTTPS. | |
251 Il parametro <literal>ssl</literal> della direttiva | |
252 <link doc="ngx_http_core_module.xml" id="listen"/> e' stato aggiunto | |
253 per risolvere questo problema. L'uso della direttiva | |
254 <link doc="ngx_http_ssl_module.xml" id="ssl"/> | |
255 e' pertanto sconsigliato nelle versioni recenti. | |
256 </note> | |
257 </para> | |
258 | |
259 </section> | |
260 | |
261 | |
262 <section id="name_based_https_servers" name="Server HTTPS name-based"> | |
263 | |
264 <para> | |
265 Quando si configurano due o piu' server HTTPS in ascolto su un singolo | |
266 indirizzo IP, sorge spesso un problema: | |
267 | |
268 <programlisting> | |
269 server { | |
270 listen 443 ssl; | |
271 server_name www.example.com; | |
272 ssl_certificate www.example.com.crt; | |
273 ... | |
274 } | |
275 | |
276 server { | |
277 listen 443 ssl; | |
278 server_name www.example.org; | |
279 ssl_certificate www.example.org.crt; | |
280 ... | |
281 } | |
282 </programlisting> | |
283 | |
284 Con questa configurazione un browser riceve il certificato del server di default, | |
285 vale a dire <literal>www.example.com</literal>, indipendentemente da quale sia | |
286 il nome del server richiesto. Cio' e' causato dal comportamento del protocollo | |
287 SSL: la connessione SSL si stabilisce prima che il browser invii una richiesta | |
288 HTTP, percio' quando nginx ancora non sa quale sara' il nome del server richiesto; | |
289 per tale ragione, non puo' fare altro che offrire il certificato del server di default. | |
290 </para> | |
291 | |
292 <para> | |
293 Il metodo classico per risolvere questo problema consiste nell'assegnare | |
294 un indirizzo IP distinto a ciascun server HTTPS: | |
295 | |
296 <programlisting> | |
297 server { | |
298 listen 192.168.1.1:443 ssl; | |
299 server_name www.example.com; | |
300 ssl_certificate www.example.com.crt; | |
301 ... | |
302 } | |
303 | |
304 server { | |
305 listen 192.168.1.2:443 ssl; | |
306 server_name www.example.org; | |
307 ssl_certificate www.example.org.crt; | |
308 ... | |
309 } | |
310 </programlisting> | |
311 </para> | |
312 | |
313 | |
314 <section id="certificate_with_several_names" | |
315 name="Un certificato SSL con molti nomi"> | |
316 | |
317 <para> | |
318 Ci sono altre maniere tramite cui condividere un singolo indirizzo IP | |
319 fra molti server HTTPS, tutte comunque non prive di problemi. | |
320 Ad esempio, e' possibile usare un certificato con diversi nomi di server | |
321 nel campo SubjectAltName, per esempio | |
322 <literal>www.example.com</literal> and <literal>www.example.org</literal>, | |
323 tuttavia la lunghezza del campo SubjectAltName e' limitata. | |
324 </para> | |
325 | |
326 <para> | |
327 Un'altra tecnica prevede l'uso di un certificato il cui nome e' definito con | |
328 caratteri jolly, per esempio <literal>*.example.org</literal>. | |
329 Un certificato con caratteri jolly va bene per tutti i sottodomini del | |
330 dominio specificato, ma per un solo livello: in questo caso ad esempio | |
331 verra' riconosciuta corrispondenza con <literal>www.example.org</literal>, | |
332 ma non con <literal>example.org</literal> e <literal>www.sub.example.org</literal>. | |
333 I due metodi mostrati possono essere combinati: nel campo SubjectAltName | |
334 un certificato puo' contenere sia nomi esatti sia nomi con caratteri jolly, | |
335 ad esempio <literal>example.org</literal> e <literal>*.example.org</literal>. | |
336 </para> | |
337 | |
338 <para> | |
339 Nel caso in cui si usi un certificato con nomi multipli, e' bene | |
340 indicare la posizione del relativo file e della chiave nel livello | |
341 <i>http</i> della configurazione, in maniera da avere una singola | |
342 copia in memoria da far ereditare a tutti i server: | |
343 | |
344 <programlisting> | |
345 ssl_certificate common.crt; | |
346 ssl_certificate_key common.key; | |
347 | |
348 server { | |
349 listen 443 ssl; | |
350 server_name www.example.com; | |
351 ... | |
352 } | |
353 | |
354 server { | |
355 listen 443 ssl; | |
356 server_name www.example.org; | |
357 ... | |
358 } | |
359 </programlisting> | |
360 </para> | |
361 | |
362 </section> | |
363 | |
364 | |
365 <section id="sni" name="Server Name Indication"> | |
366 | |
367 <para> | |
368 Una soluzione piu' generale per l'uso di server HTTPS multipli su un singolo | |
369 indirizzo IP e' data dalla | |
370 <link url="http://en.wikipedia.org/wiki/Server_Name_Indication">estensione | |
371 TLS Server Name Indication</link> (SNI, RFC 6066), che consente ad un | |
372 browser di indicare il nome del server richiesto durante l'handshake SSL e, | |
373 percio', permette al server di sapere quale certificato dovrebbe essere | |
374 usato durante la connessione. Purtroppo, SNI ha un supporto piuttosto | |
375 limitato nei browser; al momento e' supportato a partire dalle seguenti | |
376 versioni: | |
377 </para> | |
378 | |
379 <para> | |
380 <list type="bullet"> | |
381 | |
382 <listitem> | |
383 Opera 8.0; | |
384 </listitem> | |
385 | |
386 <listitem> | |
387 MSIE 7.0 (ma solo su Windows Vista o superiore); | |
388 </listitem> | |
389 | |
390 <listitem> | |
391 Firefox 2.0 e altri browser che usano Mozilla Platform rv:1.8.1; | |
392 </listitem> | |
393 | |
394 <listitem> | |
395 Safari 3.2.1 (la versione per Windows supporta SNI su Vista o superiore); | |
396 </listitem> | |
397 | |
398 <listitem> | |
399 Chrome (la versione per Windows supporta SNI su Vista o superiore). | |
400 </listitem> | |
401 | |
402 </list> | |
403 <note> | |
404 Con SNI e' possibile passare solo nomi di dominio, tuttavia alcuni browser | |
405 potrebbero erroneamente consentire di passare come nome anche l'indirizzo | |
406 IP del server. | |
407 E' bene comunque non fare affidamento su questo comportamento. | |
408 </note> | |
409 </para> | |
410 | |
411 <para> | |
412 Per poter usare SNI in nginx, e' necessario che sia supportato sia nella | |
413 libreria OpenSSL con cui il binario e' stato compilato, sia nella | |
414 libreria a cui e' linkato dinamicamente in esecuzione. | |
415 OpenSSL supporta SNI sin dalla versione 0.9.8f, a patto che sia stata | |
416 compilata con l'opzione di configurazione <nobr>“--enable-tlsext”</nobr>; | |
417 dalla versione 0.9.8j tale opzione e' abilitata per default. | |
418 Se nginx e' compilato con il supporto a SNI, allora l'esecuzione con | |
419 il parametro “-V” mostra: | |
420 | |
421 <programlisting> | |
422 $ nginx -V | |
423 ... | |
424 TLS SNI support enabled | |
425 ... | |
426 </programlisting> | |
427 | |
428 Di contro, se nginx e' stato compilato con il supporto a SNI, ma la libreria | |
429 OpenSSL a cui e' linkato dinamicamente ne e' priva, viene mostrato: | |
430 | |
431 <programlisting> | |
432 nginx was built with SNI support, however, now it is linked | |
433 dynamically to an OpenSSL library which has no tlsext support, | |
434 therefore SNI is not available | |
435 </programlisting> | |
436 </para> | |
437 | |
438 </section> | |
439 | |
440 </section> | |
441 | |
442 | |
443 <section id="compatibility" name="Compatibilita'"> | |
444 | |
445 <para> | |
446 <list type="bullet"> | |
447 | |
448 <listitem> | |
449 Il parametro “-V” mostra lo stato del supporto a SNI | |
450 dalla versione 0.8.21 e 0.7.62 in poi. | |
451 </listitem> | |
452 | |
453 <listitem> | |
454 Il parametro <literal>ssl</literal> della direttiva | |
455 <link doc="ngx_http_core_module.xml" id="listen"/> | |
456 e' supportato | |
457 dalla versione 0.7.14 in poi; | |
458 prima della versione 0.8.21 poteva essere specificato solo | |
459 insieme al parametro <literal>default</literal>. | |
460 </listitem> | |
461 | |
462 <listitem> | |
463 SNI e' supportato | |
464 dalla versione 0.5.32 in poi. | |
465 </listitem> | |
466 | |
467 <listitem> | |
468 La cache condivisa di sessione SSL e' supportata | |
469 dalla versione 0.5.6 in poi. | |
470 </listitem> | |
471 | |
472 </list> | |
473 </para> | |
474 | |
475 <para> | |
476 <list type="bullet"> | |
477 | |
478 <listitem> | |
479 Versioni 0.7.65, 0.8.19 e successive: i protocolli SSL default sono SSLv2, TLSv1, | |
480 e TLSv1.2 (se supportati dalla libreria OpenSSL). | |
481 </listitem> | |
482 | |
483 <listitem> | |
484 Versioni 0.7.64, 0.8.18 e precedenti: i protocolli SSL default sono SSLv2, | |
485 SSLv3, e TLSv1. | |
486 </listitem> | |
487 | |
488 </list> | |
489 </para> | |
490 | |
491 <para> | |
492 <list type="bullet"> | |
493 | |
494 <listitem> | |
495 Versioni 1.0.5 e successive: i sistemi di cifratura SSL default sono | |
496 “<literal>HIGH:!aNULL:!MD5</literal>”. | |
497 </listitem> | |
498 | |
499 <listitem> | |
500 Versioni 0.7.65, 0.8.20 e successive: i sistemi di cifratura SSL default sono | |
501 “<literal>HIGH:!ADH:!MD5</literal>”. | |
502 </listitem> | |
503 | |
504 <listitem> | |
505 Versione 0.8.19: i sistemi di cifratura SSL default sono | |
506 “<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</literal>”. | |
507 </listitem> | |
508 | |
509 <listitem> | |
510 Versioni 0.7.64, 0.8.18 e precedenti: i sistemi di cifratura SSL default sono<br/> | |
511 “<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</literal>”. | |
512 </listitem> | |
513 | |
514 </list> | |
515 </para> | |
516 | |
517 | |
518 </section> | |
519 | |
520 | |
521 </article> |