Mercurial > hg > nginx-site
diff xml/cn/docs/http/configuring_https_servers.xml @ 720:9934338f83af
Updated the Chinese documentation.
author | Ruslan Ermilov <ru@nginx.com> |
---|---|
date | Thu, 11 Oct 2012 10:23:05 +0000 |
parents | 130fad6dc1b4 |
children |
line wrap: on
line diff
--- a/xml/cn/docs/http/configuring_https_servers.xml Thu Oct 11 08:19:38 2012 +0000 +++ b/xml/cn/docs/http/configuring_https_servers.xml Thu Oct 11 10:23:05 2012 +0000 @@ -1,8 +1,15 @@ -<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> +<!-- + Copyright (C) Igor Sysoev + Copyright (C) Nginx, Inc. + --> + +<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> <article name="配置HTTPS服务器" link="/cn/docs/http/configuring_https_servers.html" lang="cn" + rev="3" + translator="cfsego" author="Igor Sysoev" editor="Brian Mercer"> @@ -13,32 +20,29 @@ <programlisting> server { - listen 443; - server_name www.nginx.com; - ssl on; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; - ssl_protocols SSLv3 TLSv1; - 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> -服务器证书是公开的,会被传送到所有连接到服务器的客户端。而私钥不是公开的,需要存放在访问受限的文件中,当然,nginx主进程必须有读取密钥的权限。还有一种情况,私钥和证书存放在同一个文件中: - +服务器证书是公开的,会被传送到每一个连接到服务器的客户端。而私钥不是公开的,需要存放在访问受限的文件中,当然,nginx主进程必须有读取密钥的权限。私钥和证书可以存放在同一个文件中: <programlisting> - ssl_certificate www.nginx.com.cert; - ssl_certificate_key www.nginx.com.cert; + ssl_certificate www.example.com.cert; + ssl_certificate_key www.example.com.cert; </programlisting> - 这种情况下,证书文件同样得设置访问限制。当然,虽然证书和密钥存放在同一个文件,只有证书会发送给客户端,密钥不会发送。 </para> <para> - -<literal>ssl_protocols</literal>和<literal>ssl_ciphers</literal>指令可以用来强制用户连接只能引入SSL/TLS那些强壮的协议版本和强大的加密算法。从1.0.5版本开始,nginx默认使用<literal>ssl_protocols SSLv3 TLSv1</literal>和<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>,所以只有在之前的版本,明确地配置它们才是有意义的。 +<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>”,所以只有在之前的版本,明确地配置它们才是有意义的。从1.1.13和1.0.12版本开始,nginx默认使用“<literal>ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2</literal>”。 </para> <para> @@ -56,7 +60,7 @@ <section id="optimization" name="HTTPS服务器优化"> <para> -SSL操作需要消耗CPU资源,所以在多处理器的系统,需要启动多个工作进程,而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握手,有两种方法可以将每个客户端的握手操作数量降到最低:第一种是保持客户端长连接,在一个SSL连接发送多个请求,第二种是在并发的连接或者后续的连接中重用SSL会话参数,这样可以避免SSL握手的操作。会话缓存用于保存SSL会话,这些缓存在工作进程间共享,可以使用<literal>ssl_session_cache</literal>指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟,可以使用<literal>ssl_session_timeout</literal>来修改。下面是一个针对4核系统的配置优化的例子,使用10M的共享会话缓存: +SSL操作需要消耗CPU资源,所以在多处理器的系统,需要启动多个工作进程,而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握手,有两种方法可以将每个客户端的握手操作数量降到最低:第一种是保持客户端长连接,在一个SSL连接发送多个请求,第二种是在并发的连接或者后续的连接中重用SSL会话参数,这样可以避免SSL握手的操作。会话缓存用于保存SSL会话,这些缓存在工作进程间共享,可以使用<link doc="ngx_http_ssl_module.xml" id="ssl_session_cache"/>指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟,可以使用<link doc="ngx_http_ssl_module.xml" id="ssl_session_timeout"/>加大它。下面是一个针对4核系统的配置优化的例子,使用10M的共享会话缓存: <programlisting> <b>worker_processes 4</b>; @@ -66,15 +70,15 @@ <b>ssl_session_timeout 10m</b>; server { - listen 443; - server_name www.nginx.com; - <b>keepalive_timeout 70</b>; + listen 443; + server_name www.example.com; + <b>keepalive_timeout 70</b>; - ssl on; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; - ssl_protocols SSLv3 TLSv1; - 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> @@ -88,18 +92,18 @@ 有些浏览器不接受那些众所周知的证书认证机构签署的证书,而另外一些浏览器却接受它们。这是由于证书签发使用了一些中间认证机构,这些中间机构被众所周知的证书认证机构授权代为签发证书,但是它们自己却不被广泛认知,所以有些客户端不予识别。针对这种情况,证书认证机构提供一个证书链的包裹,用来声明众所周知的认证机构和自己的关系,需要将这个证书链包裹与服务器证书合并成一个文件。在这个文件里,服务器证书需要出现在认证方证书链的前面: <programlisting> -$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt +$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt </programlisting> -这个文件需要使用<literal>ssl_certificate</literal>指令来引用: +这个文件需要使用<link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>指令来引用: <programlisting> server { - listen 443; - server_name www.nginx.com; - ssl on; - ssl_certificate www.nginx.com.chained.crt; - ssl_certificate_key www.nginx.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> @@ -107,7 +111,7 @@ 如果服务器证书和认证方证书链合并时顺序弄错了,nginx就不能正常启动,而且会显示下面的错误信息: <programlisting> -SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed +SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch) </programlisting> @@ -143,27 +147,28 @@ ... </programlisting> -在这个例子中,www.GoDaddy.com的服务器证书(#0)的受签者(“s”)是被签发机构(“i”)签名的,而这个签发机构又是证书(#1)的受签者,接着证书(#1)的签发机构又是证书(#2)的受签者,最后证书(#2)是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中,被浏览器自动识别。 +在这个例子中,www.GoDaddy.com的服务器证书(#0)的受签者(“s”)是被签发机构(“i”)签名的,而这个签发机构又是证书(#1)的受签者,接着证书(#1)的签发机构又是证书(#2)的受签者,最后证书(#2)是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中,被浏览器自动识别(这段话神似英国诗《在Jack盖的房子里》里面的内容)。 </para> <para> -如果没有加入认证方证书链,那只能看到服务器证书(#0)。 +如果没有加入认证方证书链,就只会显示服务器证书(#0)。 </para> </section> -<section id="single_http_https_server" name="统一的HTTP/HTTPS主机"> +<section id="single_http_https_server" name="合并HTTP/HTTPS主机"> <para> -从开始就将HTTP主机和HTTPS主机分开配置是很好一个很好的实践。虽然它们的功能现在看来是一样的,但是这个情况将来可能会有很大变化,那么合在一起的配置就有问题了。如果HTTP和HTTPS主机配置相同,而又不考虑将来重写配置的话,可以用一个主机配置统一处理HTTP和HTTPS请求。方法是删除<literal>ssl on</literal>的配置项,并在*:443端口添加参数<literal>ssl</literal>: +如果HTTP和HTTPS虚拟主机的功能是一致的,可以配置一个虚拟主机,既处理HTTP请求,又处理HTTPS请求。 +配置的方法是删除<literal>ssl on</literal>的指令,并在*:443端口添加参数<literal>ssl</literal>: <programlisting> server { - listen 80; - listen 443 ssl; - server_name www.nginx.com; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.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> @@ -171,7 +176,7 @@ <note> 在0.8.21版本以前,只有添加了<literal>default</literal>参数的监听端口才能添加<literal>ssl</literal>参数: <programlisting> -listen 443 default ssl; +listen 443 default ssl; </programlisting> </note> </para> @@ -182,27 +187,27 @@ <section id="name_based_https_servers" name="基于名字的HTTPS主机"> <para> -在同一个IP上配置多个HTTPS主机,会出现问题: +如果在同一个IP上配置多个HTTPS主机,会出现一个很普遍的问题: <programlisting> server { - listen 443; - server_name www.nginx.com; - ssl on; - ssl_certificate www.nginx.com.crt; + listen 443; + server_name www.example.com; + ssl on; + ssl_certificate www.example.com.crt; ... } server { - listen 443; - server_name www.nginx.org; - ssl on; - ssl_certificate www.nginx.org.crt; + listen 443; + server_name www.example.org; + ssl on; + ssl_certificate www.example.org.crt; ... } </programlisting> -使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机的证书,比方说就是<literal>www.nginx.com</literal>。这是由SSL协议本身的行为引起的。因为SSL规定在建立SSL连接以后,才能发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。 +使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机<literal>www.example.com</literal>的证书。这是由SSL协议本身的行为引起的——先建立SSL连接,再发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。 </para> <para> @@ -210,18 +215,18 @@ <programlisting> server { - listen 192.168.1.1:443; - server_name www.nginx.com; - ssl on; - ssl_certificate www.nginx.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.nginx.org; - ssl on; - ssl_certificate www.nginx.org.crt; + listen 192.168.1.2:443; + server_name www.example.org; + ssl on; + ssl_certificate www.example.org.crt; ... } </programlisting> @@ -234,31 +239,31 @@ name="带有多个主机名的SSL证书"> <para> -也有其他一些方法可以实现多个HTTPS主机共享一个IP地址,但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书,比如<literal>www.nginx.com</literal>和<literal>www.nginx.org</literal>。这种方法的限制是“SubjectAltName”字段的长度。 +也有其他一些方法可以实现多个HTTPS主机共享一个IP地址,但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书,比如<literal>www.example.com</literal>和<literal>www.example.org</literal>。但是,“SubjectAltName”字段的长度有限制。 </para> <para> -另一种方式是使用主机名中含有通配符的证书,比如<literal>*.nginx.org</literal>。这个证书匹配<literal>www.nginx.org</literal>,但是不匹配<literal>nginx.org</literal>和<literal>www.sub.nginx.org</literal>。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书,这些名字既可以是确切的名字,也可以是通配符,比如<literal>nginx.org</literal>和<literal>*.nginx.org</literal>。 +另一种方式是使用主机名中含有通配符的证书,比如<literal>*.example.org</literal>。这个证书匹配<literal>www.example.org</literal>,但是不匹配<literal>example.org</literal>和<literal>www.sub.example.org</literal>。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书,这些名字既可以是确切的名字,也可以是通配符,比如<literal>example.org</literal>和<literal>*.example.org</literal>。 </para> <para> -最好将带有多个名字的证书和它的密钥文件配置在http配置块中,这样可以只保存一份内容拷贝,所有主机的配置都从中继承: +最好将带有多个名字的证书和它的密钥文件配置在<i>http</i>配置块中,这样可以只保存一份内容拷贝,所有主机的配置都从中继承: <programlisting> ssl_certificate common.crt; ssl_certificate_key common.key; server { - listen 443; - server_name www.nginx.com; - ssl on; + listen 443; + server_name www.example.com; + ssl on; ... } server { - listen 443; - server_name www.nginx.org; - ssl on; + listen 443; + server_name www.example.org; + ssl on; ... } </programlisting> @@ -270,9 +275,10 @@ <section id="sni" name="主机名指示"> <para> -在一个IP上运行多个HTTPS主机的更通用的方案是<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">TLSv1.1 主机名指示扩展</link>(SNI,RFC3546),它允许浏览器和服务器进行SSL握手时,将请求的主机名传递服务器,因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息: +在一个IP上运行多个HTTPS主机的更通用的方案是<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">TLS主机名指示扩展</link>(SNI,RFC6066),它允许浏览器和服务器进行SSL握手时,将请求的主机名传递给服务器,因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息: </para> +<para> <list type="bullet"> <listitem> @@ -296,6 +302,10 @@ </listitem> </list> +<note> +通过SNI只能传递域名,但是,当请求中包含可读的IP地址时,某些浏览器将服务器的IP地址作为服务器的名字进行了传送。这是一个错误,大家不应该依赖于这个。 +</note> +</para> <para> 为了在nginx中使用SNI,那么无论是在编译nginx时使用的OpenSSL类库,还是在运行nginx时使用的OpenSSL运行库,都必须支持SNI。从0.9.8f版本开始,OpenSSL通过<nobr>“--enable-tlsext”</nobr>配置选项加入SNI支持,从0.9.8j版本开始,此选项成为默认选项。当nginx被编译成支持SNI时,在使用“-V”选项运行时会显示如下信息: @@ -329,7 +339,7 @@ </listitem> <listitem> -从0.7.14版本开始,<literal>listen</literal>指令支持<literal>ssl</literal>参数。 +从0.7.14版本开始,<link doc="ngx_http_core_module.xml" id="listen"/>指令支持<literal>ssl</literal>参数。 </listitem> <listitem> @@ -347,7 +357,7 @@ <list type="bullet"> <listitem> -0.7.65、0.8.19及以后版本,默认SSL协议是SSLv3和TLSv1。 +0.7.65、0.8.19及以后版本,默认SSL协议是SSLv3、TLSv1、TLSc1.1和TLSv1.2(如果OpenSSL库支持)。 </listitem> <listitem>