Mercurial > hg > nginx-site

comparison xml/ru/docs/http/configuring_https_servers.xml @ 547:32dd85720515

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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 В этом примере субъект (&ldquo;<i>s</i>&rdquo;) сертификата №0 сервера
201 <url>www.GoDaddy.com</url> подписан издателем (&ldquo;<i>i</i>&rdquo;),
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>&ldquo;--enable-tlsext&rdquo;.</nobr>
410 Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию.
411 Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом
412 &ldquo;-V&rdquo; об этом сообщается:
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 отображается по ключу &ldquo;-V&rdquo;
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>