Mercurial > hg > nginx-site
comparison xml/ru/docs/http/configuring_https_servers.xml @ 547:32dd85720515
Translated "configuring_https_servers" intro Russian.
author | Ruslan Ermilov <ru@nginx.com> |
---|---|
date | Sun, 24 Jun 2012 18:47:05 +0000 |
parents | |
children | be54c443235a |
comparison
equal
deleted
inserted
replaced
546:694db9597ee0 | 547:32dd85720515 |
---|---|
1 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> | |
2 | |
3 <article name="Настройка HTTPS-серверов" | |
4 link="/ru/docs/http/configuring_https_servers.html" | |
5 lang="ru" | |
6 author="Игорь Сысоев" | |
7 editor="Brian Mercer"> | |
8 | |
9 <section> | |
10 | |
11 <para> | |
12 Чтобы настроить HTTPS-сервер, необходимо включить протокол SSL | |
13 в блоке server, а также указать местоположение файлов с | |
14 сертификатом сервера и секретным ключом: | |
15 | |
16 <programlisting> | |
17 server { | |
18 listen 443; | |
19 server_name www.example.com; | |
20 ssl on; | |
21 ssl_certificate www.example.com.crt; | |
22 ssl_certificate_key www.example.com.key; | |
23 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; | |
24 ssl_ciphers HIGH:!aNULL:!MD5; | |
25 ... | |
26 } | |
27 </programlisting> | |
28 | |
29 Сертификат сервера является публичным. | |
30 Он посылается каждому клиенту, соединяющемуся с сервером. | |
31 Секретный ключ следует хранить в файле с ограниченным доступом | |
32 (права доступа должны позволять основному процессу nginx читать этот файл). | |
33 Секретный ключ можно также хранить в одном файле с сертификатом: | |
34 | |
35 <programlisting> | |
36 ssl_certificate www.example.com.cert; | |
37 ssl_certificate_key www.example.com.cert; | |
38 </programlisting> | |
39 | |
40 при этом права доступа к файлу следует также ограничить. | |
41 Несмотря на то, что и сертификат, и ключ хранятся в одном файле, | |
42 клиенту посылается только сертификат. | |
43 </para> | |
44 | |
45 <para> | |
46 С помощью директив <link doc="ngx_http_ssl_module.xml" id="ssl_protocols"/> и | |
47 <link doc="ngx_http_ssl_module.xml" id="ssl_ciphers"/> | |
48 можно ограничить соединения | |
49 использованием только “сильных” версий и шифров SSL/TLS. | |
50 Начиная с версии 1.0.5 nginx по умолчанию использует | |
51 “<literal>ssl_protocols SSLv3 TLSv1</literal>” и | |
52 “<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>”, | |
53 поэтому явная их настройка имеет смысл только для более ранних версий nginx. | |
54 Начиная с версий 1.1.13 и 1.0.12 nginx по умолчанию использует | |
55 “<literal>ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2</literal>”. | |
56 </para> | |
57 | |
58 <para> | |
59 Известно, что шифры с CBC-режимом уязвимы к ряду атак, в частности | |
60 к BEAST-атаке (см. | |
61 <link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>). | |
62 Настройка шифров может быть изменена так, чтобы предпочитался RC4-SHA: | |
63 | |
64 <programlisting> | |
65 ssl_ciphers RC4:HIGH:!aNULL:!MD5; | |
66 ssl_prefer_server_ciphers on; | |
67 </programlisting> | |
68 </para> | |
69 | |
70 </section> | |
71 | |
72 | |
73 <section id="optimization" name="Оптимизация HTTPS-сервера"> | |
74 | |
75 <para> | |
76 SSL-операции потребляют дополнительные ресурсы процессора. | |
77 На мультипроцессорных системах следует запускать несколько рабочих процессов, | |
78 не меньше числа доступных процессорных ядер. | |
79 Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках | |
80 которой формируются криптографические параметры сессии. | |
81 Существует два способа уменьшения числа этих операций, производимых для каждого | |
82 клиента: включение постоянных (keepalive) соединений, позволяющих в рамках | |
83 одного соединения обрабатывать сразу несколько запросов, и повторное | |
84 использование параметров SSL-сессии для предотвращения необходимости выполнения | |
85 SSL handshake для параллельных и последующих соединений. | |
86 Сессии хранятся в кэше SSL-сессий, разделяемом между рабочими процессами и | |
87 настраиваемом директивой | |
88 <link doc="ngx_http_ssl_module.xml" id="ssl_session_cache"/>. | |
89 В 1 мегабайт кэша помещается около 4000 сессий. | |
90 Таймаут кэша по умолчанию равен 5 минутам. | |
91 Он может быть увеличен с помощью директивы | |
92 <link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>. | |
93 Вот пример конфигурации, оптимизированной под 4-ядерную систему | |
94 с 10M разделяемого кэша сессий: | |
95 | |
96 <programlisting> | |
97 <b>worker_processes 4</b>; | |
98 | |
99 http { | |
100 <b>ssl_session_cache shared:SSL:10m</b>; | |
101 <b>ssl_session_timeout 10m</b>; | |
102 | |
103 server { | |
104 listen 443; | |
105 server_name www.example.com; | |
106 <b>keepalive_timeout 70</b>; | |
107 | |
108 ssl on; | |
109 ssl_certificate www.example.com.crt; | |
110 ssl_certificate_key www.example.com.key; | |
111 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; | |
112 ssl_ciphers HIGH:!aNULL:!MD5; | |
113 ... | |
114 </programlisting> | |
115 </para> | |
116 | |
117 </section> | |
118 | |
119 | |
120 <section id="chains" name="Цепочки SSL-сертификатов"> | |
121 | |
122 <para> | |
123 Некоторые браузеры могут выдавать предупреждение о сертификате, подписанном | |
124 общеизвестным центром сертификации, в то время как другие браузеры без | |
125 проблем принимают этот же сертификат. | |
126 Так происходит потому, что центр, выдавший сертификат, подписал его | |
127 промежуточным сертификатом, которого нет в базе данных сертификатов | |
128 общеизвестных доверенных центров сертификации, распространяемой | |
129 вместе с браузером. | |
130 В подобном случае центр сертификации предоставляет “связку” сертификатов, | |
131 которую следует присоединить к сертификату сервера. | |
132 Сертификат сервера следует разместить перед связкой сертификатов | |
133 в скомбинированном файле: | |
134 | |
135 <programlisting> | |
136 $ cat www.example.com.crt bundle.crt > www.example.com.chained.crt | |
137 </programlisting> | |
138 | |
139 Полученный файл следует указать в директиве | |
140 <link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>: | |
141 | |
142 <programlisting> | |
143 server { | |
144 listen 443; | |
145 server_name www.example.com; | |
146 ssl on; | |
147 ssl_certificate www.example.com.chained.crt; | |
148 ssl_certificate_key www.example.com.key; | |
149 ... | |
150 } | |
151 </programlisting> | |
152 | |
153 Если сертификат сервера и связка сертификатов были соединены в неправильном | |
154 порядке, nginx откажется запускаться и выдаст сообщение об ошибке: | |
155 | |
156 <programlisting> | |
157 SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed | |
158 (SSL: error:0B080074:x509 certificate routines: | |
159 X509_check_private_key:key values mismatch) | |
160 </programlisting> | |
161 | |
162 поскольку nginx попытается использовать секретный ключ с первым | |
163 сертификатом из связки вместо сертификата сервера. | |
164 </para> | |
165 | |
166 <para> | |
167 Браузеры обычно сохраняют полученные промежуточные сертификаты, подписанные | |
168 доверенными центрами сертификации, поэтому активно используемые браузеры | |
169 уже могут иметь требуемые промежуточные сертификаты и не выдать предупреждение | |
170 о сертификате, присланном без связанной с ним цепочки сертификатов. | |
171 Убедиться в том, что сервер присылает полную цепочку сертификатов, | |
172 можно при помощи утилиты командной строки <command>openssl</command>, например: | |
173 | |
174 <programlisting> | |
175 $ openssl s_client -connect www.godaddy.com:443 | |
176 ... | |
177 Certificate chain | |
178 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US | |
179 /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc | |
180 /OU=MIS Department/<b>CN=www.GoDaddy.com</b> | |
181 /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b) | |
182 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. | |
183 /OU=http://certificates.godaddy.com/repository | |
184 /CN=Go Daddy Secure Certification Authority | |
185 /serialNumber=07969287 | |
186 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. | |
187 /OU=http://certificates.godaddy.com/repository | |
188 /CN=Go Daddy Secure Certification Authority | |
189 /serialNumber=07969287 | |
190 i:/C=US/O=The Go Daddy Group, Inc. | |
191 /OU=Go Daddy Class 2 Certification Authority | |
192 2 s:/C=US/O=The Go Daddy Group, Inc. | |
193 /OU=Go Daddy Class 2 Certification Authority | |
194 i:/L=ValiCert Validation Network/O=<b>ValiCert, Inc.</b> | |
195 /OU=ValiCert Class 2 Policy Validation Authority | |
196 /CN=http://www.valicert.com//emailAddress=info@valicert.com | |
197 ... | |
198 </programlisting> | |
199 | |
200 В этом примере субъект (“<i>s</i>”) сертификата №0 сервера | |
201 <url>www.GoDaddy.com</url> подписан издателем (“<i>i</i>”), | |
202 который в свою очередь является субъектом сертификата №1, подписанного | |
203 издателем, который в свою очередь является субъектом сертификата №2, | |
204 подписанного общеизвестным издателем <i>ValiCert, Inc.</i>, | |
205 чей сертификат хранится во встроенной в браузеры базе данных | |
206 сертификатов (которая в тёмном чулане хранится в доме, который построил Джек). | |
207 </para> | |
208 | |
209 <para> | |
210 Если связку сертификатов не добавили, будет показан только сертификат | |
211 сервера №0. | |
212 </para> | |
213 | |
214 </section> | |
215 | |
216 | |
217 <section id="single_http_https_server" name="Единый HTTP/HTTPS сервер"> | |
218 | |
219 <para> | |
220 На практике рекомендуется с самого начала настраивать отдельные серверы | |
221 для протоколов HTTP и HTTPS. | |
222 И хотя сегодня их функциональность может казаться идентичной, в будущем | |
223 это может измениться и использование консолидированного сервера может | |
224 стать проблематичным. | |
225 Однако, если серверы HTTP и HTTPS идентичны, и думать о будущем не | |
226 хочется, можно настроить единый сервер, который обслуживает | |
227 как HTTP-, так и HTTPS-запросы. | |
228 Для этого следует исключить директиву “<literal>ssl on</literal>” | |
229 и добавить параметр <literal>ssl</literal> к порту *:443: | |
230 | |
231 <programlisting> | |
232 server { | |
233 listen 80; | |
234 listen 443 ssl; | |
235 server_name www.example.com; | |
236 ssl_certificate www.example.com.crt; | |
237 ssl_certificate_key www.example.com.key; | |
238 ... | |
239 } | |
240 </programlisting> | |
241 | |
242 <note> | |
243 До версии 0.8.21 nginx допускал указание параметра <literal>ssl</literal> | |
244 на слушающем сокете только совместно с параметром <literal>default</literal>: | |
245 <programlisting> | |
246 listen 443 default ssl; | |
247 </programlisting> | |
248 </note> | |
249 </para> | |
250 | |
251 </section> | |
252 | |
253 | |
254 <section id="name_based_https_servers" name="Выбор HTTPS-сервера по имени"> | |
255 | |
256 <para> | |
257 Типичная проблема возникает при настройке двух и более серверов HTTPS, | |
258 слушающих на одном и том же IP-адресе: | |
259 | |
260 <programlisting> | |
261 server { | |
262 listen 443; | |
263 server_name www.example.com; | |
264 ssl on; | |
265 ssl_certificate www.example.com.crt; | |
266 ... | |
267 } | |
268 | |
269 server { | |
270 listen 443; | |
271 server_name www.example.org; | |
272 ssl on; | |
273 ssl_certificate www.example.org.crt; | |
274 ... | |
275 } | |
276 </programlisting> | |
277 | |
278 В такой конфигурации браузер получит сертификат первого сервера, т.е. | |
279 <url>www.example.com</url>, независимо от запрашиваемого имени сервера. | |
280 Это связано с поведением протокола SSL. | |
281 SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, | |
282 и nginx не знает имени запрашиваемого сервера. | |
283 Следовательно, он лишь может предложить сертификат сервера по умолчанию. | |
284 </para> | |
285 | |
286 <para> | |
287 Наиболее старым и надёжным способом решения этой проблемы | |
288 является назначение каждому HTTPS-серверу своего IP-адреса: | |
289 | |
290 <programlisting> | |
291 server { | |
292 listen 192.168.1.1:443; | |
293 server_name www.example.com; | |
294 ssl on; | |
295 ssl_certificate www.example.com.crt; | |
296 ... | |
297 } | |
298 | |
299 server { | |
300 listen 192.168.1.2:443; | |
301 server_name www.example.org; | |
302 ssl on; | |
303 ssl_certificate www.example.org.crt; | |
304 ... | |
305 } | |
306 </programlisting> | |
307 </para> | |
308 | |
309 </section> | |
310 | |
311 | |
312 <section id="certificate_with_several_names" | |
313 name="SSL-сертификат с несколькими именами"> | |
314 | |
315 <para> | |
316 Существуют и другие способы, которые позволяют использовать один и тот же | |
317 IP-адрес сразу для нескольких HTTPS-серверов. | |
318 Все они, однако, имеют свои недостатки. | |
319 Одним из таких способов является использование сертификата с несколькими | |
320 именами в поле SubjectAltName сертификата, например <url>www.example.com</url> | |
321 и <url>www.example.org</url>. | |
322 Однако, длина поля SubjectAltName ограничена. | |
323 </para> | |
324 | |
325 <para> | |
326 Другим способом является использование wildcard-сертификата, например | |
327 <url>*.example.org</url>. | |
328 Такой сертификат защищает все поддомены указанного домена, но только | |
329 на заданном уровне. | |
330 Под такой сертификат подходит <url>www.example.org</url>, но не подходят | |
331 <url>example.org</url> и <url>www.sub.example.org</url>. | |
332 Два вышеуказанных способа можно комбинировать. | |
333 Сертификат может одновременно содержать и точное, и wildcard имена в поле | |
334 SubjectAltName, например <url>example.org</url> и <url>*.example.org</url>. | |
335 </para> | |
336 | |
337 <para> | |
338 Лучше поместить сведения о файле сертификата с несколькими именами и | |
339 файле с его секретным ключом на уровне конфигурации <i>http</i>, чтобы | |
340 все серверы унаследовали их единственную копию в памяти: | |
341 | |
342 <programlisting> | |
343 ssl_certificate common.crt; | |
344 ssl_certificate_key common.key; | |
345 | |
346 server { | |
347 listen 443; | |
348 server_name www.example.com; | |
349 ssl on; | |
350 ... | |
351 } | |
352 | |
353 server { | |
354 listen 443; | |
355 server_name www.example.org; | |
356 ssl on; | |
357 ... | |
358 } | |
359 </programlisting> | |
360 </para> | |
361 | |
362 </section> | |
363 | |
364 | |
365 <section id="sni" name="Указание имени сервера"> | |
366 | |
367 <para> | |
368 Более общее решение для работы нескольких HTTPS-серверов на одном | |
369 IP-адресе — | |
370 <link url="http://en.wikipedia.org/wiki/Server_Name_Indication">расширение | |
371 TLSv1.1 Server Name Indication</link> (SNI, RFC3546), | |
372 которое позволяет браузеру передать запрашиваемое имя сервера во время | |
373 SSL handshake, а значит сервер будет знать, какой сертификат ему | |
374 следует использовать для соединения. | |
375 Однако, поддержка SNI браузерами ограничена. | |
376 Сейчас это поддерживается браузерами начиная со следующих версий: | |
377 </para> | |
378 | |
379 <list type="bullet"> | |
380 | |
381 <listitem> | |
382 Opera 8.0; | |
383 </listitem> | |
384 | |
385 <listitem> | |
386 MSIE 7.0 (но только на Windows Vista и выше); | |
387 </listitem> | |
388 | |
389 <listitem> | |
390 Firefox 2.0 и другие браузеры, использующие Mozilla Platform rv:1.8.1; | |
391 </listitem> | |
392 | |
393 <listitem> | |
394 Safari 3.2.1 (Windows-версия поддерживает SNI только на Vista и выше); | |
395 </listitem> | |
396 | |
397 <listitem> | |
398 и Chrome (Windows-версия также поддерживает SNI только на Vista и выше). | |
399 </listitem> | |
400 | |
401 </list> | |
402 | |
403 <para> | |
404 Чтобы использовать SNI в nginx, соответствующая поддержка должна | |
405 присутствовать как в библиотеке OpenSSL, использованной при сборке | |
406 бинарного файла nginx, так и в библиотеке, подгружаемой в момент | |
407 работы. | |
408 OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была | |
409 собрана с опцией конфигурации <nobr>“--enable-tlsext”.</nobr> | |
410 Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию. | |
411 Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом | |
412 “-V” об этом сообщается: | |
413 | |
414 <programlisting> | |
415 $ nginx -V | |
416 ... | |
417 TLS SNI support enabled | |
418 ... | |
419 </programlisting> | |
420 | |
421 Однако, если nginx, собранный с поддержкой SNI, в процессе работы подгружает | |
422 библиотеку OpenSSL, в которой нет поддержки SNI, nginx выдаёт предупреждение: | |
423 | |
424 <programlisting> | |
425 nginx was built with SNI support, however, now it is linked | |
426 dynamically to an OpenSSL library which has no tlsext support, | |
427 therefore SNI is not available | |
428 </programlisting> | |
429 </para> | |
430 | |
431 </section> | |
432 | |
433 | |
434 <section id="compatibility" name="Совместимость"> | |
435 | |
436 <para> | |
437 <list type="bullet"> | |
438 | |
439 <listitem> | |
440 Статус поддержки SNI отображается по ключу “-V” | |
441 начиная с версий 0.8.21 и 0.7.62. | |
442 </listitem> | |
443 | |
444 <listitem> | |
445 Параметр <literal>ssl</literal> директивы | |
446 <link doc="ngx_http_core_module.xml" id="listen"/> | |
447 поддерживается начиная с версии 0.7.14. | |
448 </listitem> | |
449 | |
450 <listitem> | |
451 SNI поддерживается начиная с версии 0.5.32. | |
452 </listitem> | |
453 | |
454 <listitem> | |
455 Разделяемый кэш SSL-сессий поддерживается начиная с версии 0.5.6. | |
456 </listitem> | |
457 | |
458 </list> | |
459 </para> | |
460 | |
461 <para> | |
462 <list type="bullet"> | |
463 | |
464 <listitem> | |
465 Версия 0.7.65, 0.8.19 и более поздние: протоколами SSL по умолчанию являются | |
466 SSLv3, TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL). | |
467 </listitem> | |
468 | |
469 <listitem> | |
470 Версия 0.7.64, 0.8.18 и более ранние: протоколами SSL по умолчанию являются | |
471 SSLv2, SSLv3 и TLSv1. | |
472 </listitem> | |
473 | |
474 </list> | |
475 </para> | |
476 | |
477 <para> | |
478 <list type="bullet"> | |
479 | |
480 <listitem> | |
481 Версия 1.0.5 и более поздние: шифрами SSL по умолчанию являются | |
482 “<literal>HIGH:!aNULL:!MD5</literal>”. | |
483 </listitem> | |
484 | |
485 <listitem> | |
486 Версия 0.7.65, 0.8.20 и более поздние: шифрами SSL по умолчанию являются | |
487 “<literal>HIGH:!ADH:!MD5</literal>”. | |
488 </listitem> | |
489 | |
490 <listitem> | |
491 Версия 0.8.19: шифрами SSL по умолчанию являются | |
492 “<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</literal>”. | |
493 </listitem> | |
494 | |
495 <listitem> | |
496 Версия 0.7.64, 0.8.18 и более ранние: шифрами SSL по умолчанию являются<br/> | |
497 “<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</literal>”. | |
498 </listitem> | |
499 | |
500 </list> | |
501 </para> | |
502 | |
503 | |
504 </section> | |
505 | |
506 | |
507 </article> |