Mercurial > hg > nginx-site

changeset 660:ba45bd0fc71e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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
+++ b/xml/en/docs/http/configuring_https_servers.xml
@@ -21,13 +21,13 @@ and private key files should be specifie
 
 <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 @@ server {
 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&rsquo;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 @@ The directives <link doc="ngx_http_ssl_m
 <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 @@ It can be increased by using the
 <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 @@ in the combined file:
 </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 @@ SSL_CTX_use_PrivateKey_file(" ... /www.e
     X509_check_private_key:key values mismatch)
 </programlisting>
 
-because nginx has tried to use the private key with the bundle&rsquo;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 @@ Certificate chain
 ...
 </programlisting>
 
-In this example the subject (&ldquo;<i>s</i>&rdquo;) 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
-(&ldquo;<i>i</i>&rdquo;) 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&rsquo; 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 @@ and adding the <literal>ssl</literal> pa
 
 <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 @@ server {
 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 @@ listening on a single IP address:
 
 <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 @@ is to assign a separate IP address for e
 
 <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 @@ server {
 
 
 <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 @@ its private key file at the <i>http</i> 
 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 @@ In order to use SNI in nginx, it must be
 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>&ldquo;--enable-tlsext&rdquo;.</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 &ldquo;-V&rdquo; switch:
+when run with the “-V” switch:
 
 <programlisting>
 $ nginx -V
@@ -438,7 +440,7 @@ therefore SNI is not available
 <list type="bullet">
 
 <listitem>
-The SNI support status has been shown by the &ldquo;-V&rdquo; 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
+++ b/xml/ru/docs/http/configuring_https_servers.xml
@@ -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 @@ server {
 Секретный ключ можно также хранить в одном файле с сертификатом:
 
 <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-операции потребляют дополнительные ресурсы процессора.
 Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках
 которой формируются криптографические параметры сессии.
 Существует два способа уменьшения числа этих операций, производимых для каждого
-клиента: включение постоянных (keepalive) соединений, позволяющих в рамках
+клиента: использование постоянных (keepalive) соединений, позволяющих в рамках
 одного соединения обрабатывать сразу несколько запросов, и повторное
 использование параметров SSL-сессии для предотвращения необходимости выполнения
 SSL handshake для параллельных и последующих соединений.
@@ -97,25 +97,25 @@ SSL handshake для параллельных и последующих соединений.
 Он может быть увеличен с помощью директивы
 <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 @@ http {
 
 <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 @@ Certificate chain
 ...
 </programlisting>
 
-В этом примере субъект (&ldquo;<i>s</i>&rdquo;) сертификата №0 сервера
-<literal>www.GoDaddy.com</literal> подписан издателем (&ldquo;<i>i</i>&rdquo;),
+В этом примере субъект (“<i>s</i>”) сертификата №0 сервера
+<literal>www.GoDaddy.com</literal> подписан издателем (“<i>i</i>”),
 который в свою очередь является субъектом сертификата №1, подписанного
 издателем, который в свою очередь является субъектом сертификата №2,
 подписанного общеизвестным издателем <i>ValiCert, Inc.</i>,
@@ -224,18 +224,18 @@ Certificate chain
 
 <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 @@ listen  443  default  ssl;
 
 <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 @@ SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос,
 
 <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 @@ server {
 
 
 <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 @@ IP-адрес сразу для нескольких HTTPS-серверов.
 <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 @@ SubjectAltName, например <literal>example.org</literal> и <literal>*.example.org</literal>.
 все серверы унаследовали их единственную копию в памяти:
 
 <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 @@ Safari 3.2.1 (Windows-версия поддерживает SNI только на Vista и выше);
 <para>
 Чтобы использовать SNI в nginx, соответствующая поддержка должна
 присутствовать как в библиотеке OpenSSL, использованной при сборке
-бинарного файла nginx, так и в библиотеке, подгружаемой в момент
-работы.
+бинарного файла nginx, так и в библиотеке, подгружаемой в момент работы.
 OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была
-собрана с опцией конфигурации <nobr>&ldquo;--enable-tlsext&rdquo;.</nobr>
+собрана с опцией конфигурации <nobr>“--enable-tlsext”.</nobr>
 Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию.
 Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом
-&ldquo;-V&rdquo; об этом сообщается:
+“-V” об этом сообщается:
 
 <programlisting>
 $ nginx -V
@@ -444,7 +444,7 @@ therefore SNI is not available
 <list type="bullet">
 
 <listitem>
-Статус поддержки SNI отображается по ключу &ldquo;-V&rdquo;
+Статус поддержки SNI отображается по ключу “-V”
 начиная с версий 0.8.21 и 0.7.62.
 </listitem>