Mercurial > hg > nginx-site

changeset 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 694db9597ee0
children 95a970603b0f
files xml/ru/GNUmakefile xml/ru/docs/http/configuring_https_servers.xml xml/ru/docs/introduction.xml
diffstat 3 files changed, 510 insertions(+), 2 deletions(-) [+]
line wrap: on
line diff
--- a/xml/ru/GNUmakefile
+++ b/xml/ru/GNUmakefile
@@ -19,6 +19,7 @@ DOCS_HTML =	$(foreach name, $(DOCS), $(O
 
 INTRO =									\
 		http/request_processing					\
+		http/configuring_https_servers				\
 
 INTRO_XML =	$(foreach name, $(INTRO), xml/$(DOC_LANG)/docs/$(name).xml)
 INTRO_HTML =	$(foreach name, $(INTRO), $(OUT)/$(DOC_LANG)/docs/$(name).html)
new file mode 100644
--- /dev/null
+++ b/xml/ru/docs/http/configuring_https_servers.xml
@@ -0,0 +1,507 @@
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="Настройка HTTPS-серверов"
+         link="/ru/docs/http/configuring_https_servers.html"
+         lang="ru"
+         author="Игорь Сысоев"
+         editor="Brian Mercer">
+
+<section>
+
+<para>
+Чтобы настроить HTTPS-сервер, необходимо включить протокол SSL
+в блоке server, а также указать местоположение файлов с
+сертификатом сервера и секретным ключом:
+
+<programlisting>
+server {
+    listen               443;
+    server_name          www.example.com;
+    ssl                  on;
+    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>
+
+Сертификат сервера является публичным.
+Он посылается каждому клиенту, соединяющемуся с сервером.
+Секретный ключ следует хранить в файле с ограниченным доступом
+(права доступа должны позволять основному процессу nginx читать этот файл).
+Секретный ключ можно также хранить в одном файле с сертификатом:
+
+<programlisting>
+    ssl_certificate      www.example.com.cert;
+    ssl_certificate_key  www.example.com.cert;
+</programlisting>
+
+при этом права доступа к файлу следует также ограничить.
+Несмотря на то, что и сертификат, и ключ хранятся в одном файле,
+клиенту посылается только сертификат.
+</para>
+
+<para>
+С помощью директив <link doc="ngx_http_ssl_module.xml" id="ssl_protocols"/> и
+<link doc="ngx_http_ssl_module.xml" id="ssl_ciphers"/>
+можно ограничить соединения
+использованием только “сильных” версий и шифров SSL/TLS.
+Начиная с версии 1.0.5 nginx по умолчанию использует
+“<literal>ssl_protocols SSLv3 TLSv1</literal>” и
+“<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>”,
+поэтому явная их настройка имеет смысл только для более ранних версий nginx.
+Начиная с версий 1.1.13 и 1.0.12 nginx по умолчанию использует
+“<literal>ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2</literal>”.
+</para>
+
+<para>
+Известно, что шифры с CBC-режимом уязвимы к ряду атак, в частности
+к BEAST-атаке (см.
+<link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>).
+Настройка шифров может быть изменена так, чтобы предпочитался RC4-SHA:
+
+<programlisting>
+    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
+    ssl_prefer_server_ciphers on;
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="optimization" name="Оптимизация HTTPS-сервера">
+
+<para>
+SSL-операции потребляют дополнительные ресурсы процессора.
+На мультипроцессорных системах следует запускать несколько рабочих процессов,
+не меньше числа доступных процессорных ядер.
+Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках
+которой формируются криптографические параметры сессии.
+Существует два способа уменьшения числа этих операций, производимых для каждого
+клиента: включение постоянных (keepalive) соединений, позволяющих в рамках
+одного соединения обрабатывать сразу несколько запросов, и повторное
+использование параметров SSL-сессии для предотвращения необходимости выполнения
+SSL handshake для параллельных и последующих соединений.
+Сессии хранятся в кэше SSL-сессий, разделяемом между рабочими процессами и
+настраиваемом директивой
+<link doc="ngx_http_ssl_module.xml" id="ssl_session_cache"/>.
+В 1 мегабайт кэша помещается около 4000 сессий.
+Таймаут кэша по умолчанию равен 5 минутам.
+Он может быть увеличен с помощью директивы
+<link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>.
+Вот пример конфигурации, оптимизированной под 4-ядерную систему
+с 10M разделяемого кэша сессий:
+
+<programlisting>
+<b>worker_processes  4</b>;
+
+http {
+    <b>ssl_session_cache    shared:SSL:10m</b>;
+    <b>ssl_session_timeout  10m</b>;
+
+    server {
+        listen               443;
+        server_name          www.example.com;
+        <b>keepalive_timeout    70</b>;
+
+        ssl                  on;
+        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="Цепочки SSL-сертификатов">
+
+<para>
+Некоторые браузеры могут выдавать предупреждение о сертификате, подписанном
+общеизвестным центром сертификации, в то время как другие браузеры без
+проблем принимают этот же сертификат.
+Так происходит потому, что центр, выдавший сертификат, подписал его
+промежуточным сертификатом, которого нет в базе данных сертификатов
+общеизвестных доверенных центров сертификации, распространяемой
+вместе с браузером.
+В подобном случае центр сертификации предоставляет “связку” сертификатов,
+которую следует присоединить к сертификату сервера.
+Сертификат сервера следует разместить перед связкой сертификатов
+в скомбинированном файле:
+
+<programlisting>
+$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
+</programlisting>
+
+Полученный файл следует указать в директиве
+<link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>:
+
+<programlisting>
+server {
+    listen               443;
+    server_name          www.example.com;
+    ssl                  on;
+    ssl_certificate      www.example.com.chained.crt;
+    ssl_certificate_key  www.example.com.key;
+    ...
+}
+</programlisting>
+
+Если сертификат сервера и связка сертификатов были соединены в неправильном
+порядке, nginx откажется запускаться и выдаст сообщение об ошибке:
+
+<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>
+
+поскольку nginx попытается использовать секретный ключ с первым
+сертификатом из связки вместо сертификата сервера.
+</para>
+
+<para>
+Браузеры обычно сохраняют полученные промежуточные сертификаты, подписанные
+доверенными центрами сертификации, поэтому активно используемые браузеры
+уже могут иметь требуемые промежуточные сертификаты и не выдать предупреждение
+о сертификате, присланном без связанной с ним цепочки сертификатов.
+Убедиться в том, что сервер присылает полную цепочку сертификатов,
+можно при помощи утилиты командной строки <command>openssl</command>, например:
+
+<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>
+
+В этом примере субъект (&ldquo;<i>s</i>&rdquo;) сертификата №0 сервера
+<url>www.GoDaddy.com</url> подписан издателем (&ldquo;<i>i</i>&rdquo;),
+который в свою очередь является субъектом сертификата №1, подписанного
+издателем, который в свою очередь является субъектом сертификата №2,
+подписанного общеизвестным издателем <i>ValiCert, Inc.</i>,
+чей сертификат хранится во встроенной в браузеры базе данных
+сертификатов (которая в тёмном чулане хранится в доме, который построил Джек).
+</para>
+
+<para>
+Если связку сертификатов не добавили, будет показан только сертификат
+сервера №0.
+</para>
+
+</section>
+
+
+<section id="single_http_https_server" name="Единый HTTP/HTTPS сервер">
+
+<para>
+На практике рекомендуется с самого начала настраивать отдельные серверы
+для протоколов HTTP и HTTPS.
+И хотя сегодня их функциональность может казаться идентичной, в будущем
+это может измениться и использование консолидированного сервера может
+стать проблематичным.
+Однако, если серверы HTTP и HTTPS идентичны, и думать о будущем не
+хочется, можно настроить единый сервер, который обслуживает
+как HTTP-, так и HTTPS-запросы.
+Для этого следует исключить директиву “<literal>ssl on</literal>”
+и добавить параметр <literal>ssl</literal> к порту *:443:
+
+<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>
+До версии 0.8.21 nginx допускал указание параметра <literal>ssl</literal>
+на слушающем сокете только совместно с параметром <literal>default</literal>:
+<programlisting>
+listen  443  default  ssl;
+</programlisting>
+</note>
+</para>
+
+</section>
+
+
+<section id="name_based_https_servers" name="Выбор HTTPS-сервера по имени">
+
+<para>
+Типичная проблема возникает при настройке двух и более серверов HTTPS,
+слушающих на одном и том же IP-адресе:
+
+<programlisting>
+server {
+    listen           443;
+    server_name      www.example.com;
+    ssl              on;
+    ssl_certificate  www.example.com.crt;
+    ...
+}
+
+server {
+    listen           443;
+    server_name      www.example.org;
+    ssl              on;
+    ssl_certificate  www.example.org.crt;
+    ...
+}
+</programlisting>
+
+В такой конфигурации браузер получит сертификат первого сервера, т.е.
+<url>www.example.com</url>, независимо от запрашиваемого имени сервера.
+Это связано с поведением протокола SSL.
+SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос,
+и nginx не знает имени запрашиваемого сервера.
+Следовательно, он лишь может предложить сертификат сервера по умолчанию.
+</para>
+
+<para>
+Наиболее старым и надёжным способом решения этой проблемы
+является назначение каждому HTTPS-серверу своего IP-адреса:
+
+<programlisting>
+server {
+    listen           192.168.1.1:443;
+    server_name      www.example.com;
+    ssl              on;
+    ssl_certificate  www.example.com.crt;
+    ...
+}
+
+server {
+    listen           192.168.1.2:443;
+    server_name      www.example.org;
+    ssl              on;
+    ssl_certificate  www.example.org.crt;
+    ...
+}
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="certificate_with_several_names"
+        name="SSL-сертификат с несколькими именами">
+
+<para>
+Существуют и другие способы, которые позволяют использовать один и тот же
+IP-адрес сразу для нескольких HTTPS-серверов.
+Все они, однако, имеют свои недостатки.
+Одним из таких способов является использование сертификата с несколькими
+именами в поле SubjectAltName сертификата, например <url>www.example.com</url>
+и <url>www.example.org</url>.
+Однако, длина поля SubjectAltName ограничена.
+</para>
+
+<para>
+Другим способом является использование wildcard-сертификата, например
+<url>*.example.org</url>.
+Такой сертификат защищает все поддомены указанного домена, но только
+на заданном уровне.
+Под такой сертификат подходит <url>www.example.org</url>, но не подходят
+<url>example.org</url> и <url>www.sub.example.org</url>.
+Два вышеуказанных способа можно комбинировать.
+Сертификат может одновременно содержать и точное, и wildcard имена в поле
+SubjectAltName, например <url>example.org</url> и <url>*.example.org</url>.
+</para>
+
+<para>
+Лучше поместить сведения о файле сертификата с несколькими именами и
+файле с его секретным ключом на уровне конфигурации <i>http</i>, чтобы
+все серверы унаследовали их единственную копию в памяти:
+
+<programlisting>
+ssl_certificate      common.crt;
+ssl_certificate_key  common.key;
+
+server {
+    listen           443;
+    server_name      www.example.com;
+    ssl              on;
+    ...
+}
+
+server {
+    listen           443;
+    server_name      www.example.org;
+    ssl              on;
+    ...
+}
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="sni" name="Указание имени сервера">
+
+<para>
+Более общее решение для работы нескольких HTTPS-серверов на одном
+IP-адресе —
+<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">расширение
+TLSv1.1 Server Name Indication</link> (SNI, RFC3546),
+которое позволяет браузеру передать запрашиваемое имя сервера во время
+SSL handshake, а значит сервер будет знать, какой сертификат ему
+следует использовать для соединения.
+Однако, поддержка SNI браузерами ограничена.
+Сейчас это поддерживается браузерами начиная со следующих версий:
+</para>
+
+<list type="bullet">
+
+<listitem>
+Opera 8.0;
+</listitem>
+
+<listitem>
+MSIE 7.0 (но только на Windows Vista и выше);
+</listitem>
+
+<listitem>
+Firefox 2.0 и другие браузеры, использующие Mozilla Platform rv:1.8.1;
+</listitem>
+
+<listitem>
+Safari 3.2.1 (Windows-версия поддерживает SNI только на Vista и выше);
+</listitem>
+
+<listitem>
+и Chrome (Windows-версия также поддерживает SNI только на Vista и выше).
+</listitem>
+
+</list>
+
+<para>
+Чтобы использовать SNI в nginx, соответствующая поддержка должна
+присутствовать как в библиотеке OpenSSL, использованной при сборке
+бинарного файла nginx, так и в библиотеке, подгружаемой в момент
+работы.
+OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была
+собрана с опцией конфигурации <nobr>&ldquo;--enable-tlsext&rdquo;.</nobr>
+Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию.
+Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом
+&ldquo;-V&rdquo; об этом сообщается:
+
+<programlisting>
+$ nginx -V
+...
+TLS SNI support enabled
+...
+</programlisting>
+
+Однако, если nginx, собранный с поддержкой SNI, в процессе работы подгружает
+библиотеку OpenSSL, в которой нет поддержки SNI, nginx выдаёт предупреждение:
+
+<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 id="compatibility" name="Совместимость">
+
+<para>
+<list type="bullet">
+
+<listitem>
+Статус поддержки SNI отображается по ключу &ldquo;-V&rdquo;
+начиная с версий 0.8.21 и 0.7.62.
+</listitem>
+
+<listitem>
+Параметр <literal>ssl</literal> директивы
+<link doc="ngx_http_core_module.xml" id="listen"/>
+поддерживается начиная с версии 0.7.14.
+</listitem>
+
+<listitem>
+SNI поддерживается начиная с версии 0.5.32.
+</listitem>
+
+<listitem>
+Разделяемый кэш SSL-сессий поддерживается начиная с версии 0.5.6.
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+Версия 0.7.65, 0.8.19 и более поздние: протоколами SSL по умолчанию являются
+SSLv3, TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
+</listitem>
+
+<listitem>
+Версия 0.7.64, 0.8.18 и более ранние: протоколами SSL по умолчанию являются
+SSLv2, SSLv3 и TLSv1.
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+Версия 1.0.5 и более поздние: шифрами SSL по умолчанию являются
+“<literal>HIGH:!aNULL:!MD5</literal>”.
+</listitem>
+
+<listitem>
+Версия 0.7.65, 0.8.20 и более поздние: шифрами SSL по умолчанию являются
+“<literal>HIGH:!ADH:!MD5</literal>”.
+</listitem>
+
+<listitem>
+Версия 0.8.19: шифрами SSL по умолчанию являются
+“<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</literal>”.
+</listitem>
+
+<listitem>
+Версия 0.7.64, 0.8.18 и более ранние: шифрами SSL по умолчанию являются<br/>
+“<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</literal>”.
+</listitem>
+
+</list>
+</para>
+
+
+</section>
+
+
+</article>
--- a/xml/ru/docs/introduction.xml
+++ b/xml/ru/docs/introduction.xml
@@ -20,12 +20,12 @@
 <link doc="http/server_names.xml"/>
 </listitem>
 
+-->
+
 <listitem>
 <link doc="http/configuring_https_servers.xml"/>
 </listitem>
 
--->
-
 </list>
 </para>