Mercurial > hg > nginx-site
changeset 660:ba45bd0fc71e
configuring_https_servers: markup changes (mostly).
author | Ruslan Ermilov <ru@nginx.com> |
---|---|
date | Tue, 28 Aug 2012 09:59:56 +0000 |
parents | 77a3314c74a7 |
children | e1579b244800 |
files | xml/en/docs/http/configuring_https_servers.xml xml/ru/docs/http/configuring_https_servers.xml |
diffstat | 2 files changed, 153 insertions(+), 151 deletions(-) [+] |
line wrap: on
line diff
--- a/xml/en/docs/http/configuring_https_servers.xml Tue Aug 28 09:23:40 2012 +0000 +++ b/xml/en/docs/http/configuring_https_servers.xml Tue Aug 28 09:59:56 2012 +0000 @@ -21,13 +21,13 @@ <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; + listen 443; + server_name www.example.com; + ssl <b>on</b>; + 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> @@ -35,12 +35,12 @@ The server certificate is a public entity. It is sent to every client that connects to the server. The private key is a secure entity and should be stored in a file with -restricted access, however, it must be readable by nginx’s master process. +restricted access, however, it must be readable by nginx’s master process. The private key may alternately be stored in the same file as the certificate: <programlisting> - ssl_certificate www.example.com.cert; - ssl_certificate_key www.example.com.cert; + ssl_certificate www.example.com.cert; + ssl_certificate_key www.example.com.cert; </programlisting> in which case the file access rights should also be restricted. @@ -53,7 +53,8 @@ <link doc="ngx_http_ssl_module.xml" id="ssl_ciphers"/> can be used to limit connections to include only the strong versions and ciphers of SSL/TLS. -Since version 1.0.5, nginx uses “<literal>ssl_protocols SSLv3 TLSv1</literal>” +Since version 1.0.5, nginx uses +“<literal>ssl_protocols SSLv3 TLSv1</literal>” and “<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>” by default, so configuring them explicitly only makes sense for the earlier nginx versions. Since versions 1.1.13 and 1.0.12, nginx uses @@ -96,25 +97,25 @@ <link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/> directive. Here is a sample configuration optimized for a quad core system -with 10M shared session cache: +with 10 megabyte shared session cache: <programlisting> -<b>worker_processes 4</b>; +<b>worker_processes 4</b>; http { - <b>ssl_session_cache shared:SSL:10m</b>; - <b>ssl_session_timeout 10m</b>; + <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>; + 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; + 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> @@ -142,16 +143,15 @@ </programlisting> The resulting file should be used in the -<link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/> -directive: +<link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/> directive: <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; + listen 443; + server_name www.example.com; + ssl on; + ssl_certificate www.example.com.chained.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -165,7 +165,7 @@ X509_check_private_key:key values mismatch) </programlisting> -because nginx has tried to use the private key with the bundle’s +because nginx has tried to use the private key with the bundle’s first certificate instead of the server certificate. </para> @@ -203,12 +203,12 @@ ... </programlisting> -In this example the subject (“<i>s</i>”) of the +In this example the subject (“<i>s</i>”) of the <literal>www.GoDaddy.com</literal> server certificate #0 is signed by an issuer -(“<i>i</i>”) which itself is the subject of the certificate #1, +(“<i>i</i>”) which itself is the subject of the certificate #1, which is signed by an issuer which itself is the subject of the certificate #2, which signed by the well-known issuer <i>ValiCert, Inc.</i> -whose certificate is stored in the browsers’ built-in +whose certificate is stored in the browsers’ built-in certificate base (that lay in the house that Jack built). </para> @@ -230,11 +230,11 @@ <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; + listen 80; + listen 443 ssl; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -243,7 +243,7 @@ Prior to 0.8.21, nginx only allows the <literal>ssl</literal> parameter to be set on listen sockets with the <literal>default</literal> parameter: <programlisting> -listen 443 default ssl; +listen 443 default ssl; </programlisting> </note> </para> @@ -259,28 +259,28 @@ <programlisting> server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; + 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; + listen 443; + server_name www.example.org; + ssl on; + ssl_certificate www.example.org.crt; ... } </programlisting> -With this configuration a browser receives the certificate of the default -server, i.e., <literal>www.example.com</literal> regardless of the requested server name. -This is caused by SSL protocol behaviour. The SSL connection is established -before the browser sends an HTTP request and nginx does not know -the name of the requested server. Therefore, it may only offer the certificate -of the default server. +With this configuration a browser receives the default server’s certificate, +i.e. <literal>www.example.com</literal> regardless of the requested server name. +This is caused by SSL protocol behaviour. +The SSL connection is established before the browser sends an HTTP request +and nginx does not know the name of the requested server. +Therefore, it may only offer the default server’s certificate. </para> <para> @@ -289,18 +289,18 @@ <programlisting> server { - listen 192.168.1.1:443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; + 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; + listen 192.168.1.2:443; + server_name www.example.org; + ssl on; + ssl_certificate www.example.org.crt; ... } </programlisting> @@ -310,24 +310,26 @@ <section id="certificate_with_several_names" - name="A SSL certificate with several names"> + name="An SSL certificate with several names"> <para> There are other ways to share a single IP address between several HTTPS servers, however, all of them have drawbacks. One way is to use a certificate with several names in -the SubjectAltName certificate field, for example, <literal>www.example.com</literal> -and <literal>www.example.org</literal>. +the SubjectAltName certificate field, for example, +<literal>www.example.com</literal> and <literal>www.example.org</literal>. However, the SubjectAltName field length is limited. </para> <para> Another way is to use a certificate with a wildcard name, for example, -<literal>*.example.org</literal>. This certificate matches -<literal>www.example.org</literal>, but does not match <literal>example.org</literal> -and <literal>www.sub.example.org</literal>. These two methods can also be combined. -A certificate may contain exact and wildcard names in the SubjectAltName field, -for example, <literal>example.org</literal> and <literal>*.example.org</literal>. +<literal>*.example.org</literal>. +This certificate matches <literal>www.example.org</literal>, but does not match +<literal>example.org</literal> and <literal>www.sub.example.org</literal>. +These two methods can also be combined. +A certificate may contain exact and wildcard names in the +SubjectAltName field, for example, +<literal>example.org</literal> and <literal>*.example.org</literal>. </para> <para> @@ -336,20 +338,20 @@ to inherit their single memory copy in all servers: <programlisting> -ssl_certificate common.crt; -ssl_certificate_key common.key; +ssl_certificate common.crt; +ssl_certificate_key common.key; server { - listen 443; - server_name www.example.com; - ssl on; + listen 443; + server_name www.example.com; + ssl on; ... } server { - listen 443; - server_name www.example.org; - ssl on; + listen 443; + server_name www.example.org; + ssl on; ... } </programlisting> @@ -407,10 +409,10 @@ OpenSSL library with which the nginx binary has been built as well as the library to which it is being dynamically linked at run time. OpenSSL supports SNI since 0.9.8f version if it was built with config option -<nobr>“--enable-tlsext”.</nobr> +<nobr>“--enable-tlsext”.</nobr> Since OpenSSL 0.9.8j this option is enabled by default. If nginx was built with SNI support, then nginx will show this -when run with the “-V” switch: +when run with the “-V” switch: <programlisting> $ nginx -V @@ -438,7 +440,7 @@ <list type="bullet"> <listitem> -The SNI support status has been shown by the “-V” switch +The SNI support status has been shown by the “-V” switch since 0.8.21 and 0.7.62. </listitem>
--- a/xml/ru/docs/http/configuring_https_servers.xml Tue Aug 28 09:23:40 2012 +0000 +++ b/xml/ru/docs/http/configuring_https_servers.xml Tue Aug 28 09:59:56 2012 +0000 @@ -21,13 +21,13 @@ <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; + listen 443; + server_name www.example.com; + ssl <b>on</b>; + 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> @@ -39,8 +39,8 @@ Секретный ключ можно также хранить в одном файле с сертификатом: <programlisting> - ssl_certificate www.example.com.cert; - ssl_certificate_key www.example.com.cert; + ssl_certificate www.example.com.cert; + ssl_certificate_key www.example.com.cert; </programlisting> при этом права доступа к файлу следует также ограничить. @@ -85,7 +85,7 @@ Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках которой формируются криптографические параметры сессии. Существует два способа уменьшения числа этих операций, производимых для каждого -клиента: включение постоянных (keepalive) соединений, позволяющих в рамках +клиента: использование постоянных (keepalive) соединений, позволяющих в рамках одного соединения обрабатывать сразу несколько запросов, и повторное использование параметров SSL-сессии для предотвращения необходимости выполнения SSL handshake для параллельных и последующих соединений. @@ -97,25 +97,25 @@ Он может быть увеличен с помощью директивы <link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>. Вот пример конфигурации, оптимизированной под 4-ядерную систему -с 10M разделяемого кэша сессий: +с 10-мегабайтным разделяемым кэшем сессий: <programlisting> -<b>worker_processes 4</b>; +<b>worker_processes 4</b>; http { - <b>ssl_session_cache shared:SSL:10m</b>; - <b>ssl_session_timeout 10m</b>; + <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>; + 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; + 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> @@ -147,11 +147,11 @@ <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; + listen 443; + server_name www.example.com; + ssl on; + ssl_certificate www.example.com.chained.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -203,8 +203,8 @@ ... </programlisting> -В этом примере субъект (“<i>s</i>”) сертификата №0 сервера -<literal>www.GoDaddy.com</literal> подписан издателем (“<i>i</i>”), +В этом примере субъект (“<i>s</i>”) сертификата №0 сервера +<literal>www.GoDaddy.com</literal> подписан издателем (“<i>i</i>”), который в свою очередь является субъектом сертификата №1, подписанного издателем, который в свою очередь является субъектом сертификата №2, подписанного общеизвестным издателем <i>ValiCert, Inc.</i>, @@ -224,18 +224,18 @@ <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; + listen 80; + listen 443 ssl; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -260,23 +260,23 @@ <programlisting> server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; + 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; + listen 443; + server_name www.example.org; + ssl on; + ssl_certificate www.example.org.crt; ... } </programlisting> -В такой конфигурации браузер получит сертификат первого сервера, т.е. +В такой конфигурации браузер получит сертификат сервера по умолчанию, т.е. <literal>www.example.com</literal>, независимо от запрашиваемого имени сервера. Это связано с поведением протокола SSL. SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, @@ -290,18 +290,18 @@ <programlisting> server { - listen 192.168.1.1:443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; + 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; + listen 192.168.1.2:443; + server_name www.example.org; + ssl on; + ssl_certificate www.example.org.crt; ... } </programlisting> @@ -311,15 +311,15 @@ <section id="certificate_with_several_names" - name="SSL-сертификат с несколькими именами"> + name="SSL-сертификат с несколькими именами"> <para> Существуют и другие способы, которые позволяют использовать один и тот же IP-адрес сразу для нескольких HTTPS-серверов. Все они, однако, имеют свои недостатки. Одним из таких способов является использование сертификата с несколькими -именами в поле SubjectAltName сертификата, например <literal>www.example.com</literal> -и <literal>www.example.org</literal>. +именами в поле SubjectAltName сертификата, например +<literal>www.example.com</literal> и <literal>www.example.org</literal>. Однако, длина поля SubjectAltName ограничена. </para> @@ -332,7 +332,8 @@ <literal>example.org</literal> и <literal>www.sub.example.org</literal>. Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле -SubjectAltName, например <literal>example.org</literal> и <literal>*.example.org</literal>. +SubjectAltName, например +<literal>example.org</literal> и <literal>*.example.org</literal>. </para> <para> @@ -341,20 +342,20 @@ все серверы унаследовали их единственную копию в памяти: <programlisting> -ssl_certificate common.crt; -ssl_certificate_key common.key; +ssl_certificate common.crt; +ssl_certificate_key common.key; server { - listen 443; - server_name www.example.com; - ssl on; + listen 443; + server_name www.example.com; + ssl on; ... } server { - listen 443; - server_name www.example.org; - ssl on; + listen 443; + server_name www.example.org; + ssl on; ... } </programlisting> @@ -410,13 +411,12 @@ <para> Чтобы использовать SNI в nginx, соответствующая поддержка должна присутствовать как в библиотеке OpenSSL, использованной при сборке -бинарного файла nginx, так и в библиотеке, подгружаемой в момент -работы. +бинарного файла nginx, так и в библиотеке, подгружаемой в момент работы. OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была -собрана с опцией конфигурации <nobr>“--enable-tlsext”.</nobr> +собрана с опцией конфигурации <nobr>“--enable-tlsext”.</nobr> Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию. Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом -“-V” об этом сообщается: +“-V” об этом сообщается: <programlisting> $ nginx -V @@ -444,7 +444,7 @@ <list type="bullet"> <listitem> -Статус поддержки SNI отображается по ключу “-V” +Статус поддержки SNI отображается по ключу “-V” начиная с версий 0.8.21 и 0.7.62. </listitem>