Mercurial > hg > nginx-site
comparison 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 |
comparison
equal
deleted
inserted
replaced
719:6a37df6078a1 | 720:9934338f83af |
---|---|
1 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> | 1 <!-- |
2 Copyright (C) Igor Sysoev | |
3 Copyright (C) Nginx, Inc. | |
4 --> | |
5 | |
6 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> | |
2 | 7 |
3 <article name="配置HTTPS服务器" | 8 <article name="配置HTTPS服务器" |
4 link="/cn/docs/http/configuring_https_servers.html" | 9 link="/cn/docs/http/configuring_https_servers.html" |
5 lang="cn" | 10 lang="cn" |
11 rev="3" | |
12 translator="cfsego" | |
6 author="Igor Sysoev" | 13 author="Igor Sysoev" |
7 editor="Brian Mercer"> | 14 editor="Brian Mercer"> |
8 | 15 |
9 <section> | 16 <section> |
10 | 17 |
11 <para> | 18 <para> |
12 配置HTTPS主机,必须在server配置块中打开SSL协议,还需要指定服务器端证书和密钥文件的位置: | 19 配置HTTPS主机,必须在server配置块中打开SSL协议,还需要指定服务器端证书和密钥文件的位置: |
13 | 20 |
14 <programlisting> | 21 <programlisting> |
15 server { | 22 server { |
16 listen 443; | 23 listen 443; |
17 server_name www.nginx.com; | 24 server_name www.example.com; |
18 ssl on; | 25 ssl <b>on</b>; |
19 ssl_certificate www.nginx.com.crt; | 26 ssl_certificate <b>www.example.com.crt</b>; |
20 ssl_certificate_key www.nginx.com.key; | 27 ssl_certificate_key <b>www.example.com.key</b>; |
21 ssl_protocols SSLv3 TLSv1; | 28 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; |
22 ssl_ciphers HIGH:!aNULL:!MD5; | 29 ssl_ciphers HIGH:!aNULL:!MD5; |
23 ... | 30 ... |
24 } | 31 } |
25 </programlisting> | 32 </programlisting> |
26 | 33 |
27 服务器证书是公开的,会被传送到所有连接到服务器的客户端。而私钥不是公开的,需要存放在访问受限的文件中,当然,nginx主进程必须有读取密钥的权限。还有一种情况,私钥和证书存放在同一个文件中: | 34 服务器证书是公开的,会被传送到每一个连接到服务器的客户端。而私钥不是公开的,需要存放在访问受限的文件中,当然,nginx主进程必须有读取密钥的权限。私钥和证书可以存放在同一个文件中: |
28 | 35 |
29 | 36 <programlisting> |
30 <programlisting> | 37 ssl_certificate www.example.com.cert; |
31 ssl_certificate www.nginx.com.cert; | 38 ssl_certificate_key www.example.com.cert; |
32 ssl_certificate_key www.nginx.com.cert; | 39 </programlisting> |
33 </programlisting> | |
34 | |
35 | 40 |
36 这种情况下,证书文件同样得设置访问限制。当然,虽然证书和密钥存放在同一个文件,只有证书会发送给客户端,密钥不会发送。 | 41 这种情况下,证书文件同样得设置访问限制。当然,虽然证书和密钥存放在同一个文件,只有证书会发送给客户端,密钥不会发送。 |
37 </para> | 42 </para> |
38 | 43 |
39 <para> | 44 <para> |
40 | 45 <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>”。 |
41 <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>,所以只有在之前的版本,明确地配置它们才是有意义的。 | |
42 </para> | 46 </para> |
43 | 47 |
44 <para> | 48 <para> |
45 CBC模式的加密算法容易受到一些攻击,尤其是BEAST攻击(参见<link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>)。可以通过下面配置调整为优先使用RC4-SHA加密算法: | 49 CBC模式的加密算法容易受到一些攻击,尤其是BEAST攻击(参见<link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>)。可以通过下面配置调整为优先使用RC4-SHA加密算法: |
46 | 50 |
54 | 58 |
55 | 59 |
56 <section id="optimization" name="HTTPS服务器优化"> | 60 <section id="optimization" name="HTTPS服务器优化"> |
57 | 61 |
58 <para> | 62 <para> |
59 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的共享会话缓存: | 63 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的共享会话缓存: |
60 | 64 |
61 <programlisting> | 65 <programlisting> |
62 <b>worker_processes 4</b>; | 66 <b>worker_processes 4</b>; |
63 | 67 |
64 http { | 68 http { |
65 <b>ssl_session_cache shared:SSL:10m</b>; | 69 <b>ssl_session_cache shared:SSL:10m</b>; |
66 <b>ssl_session_timeout 10m</b>; | 70 <b>ssl_session_timeout 10m</b>; |
67 | 71 |
68 server { | 72 server { |
69 listen 443; | 73 listen 443; |
70 server_name www.nginx.com; | 74 server_name www.example.com; |
71 <b>keepalive_timeout 70</b>; | 75 <b>keepalive_timeout 70</b>; |
72 | 76 |
73 ssl on; | 77 ssl on; |
74 ssl_certificate www.nginx.com.crt; | 78 ssl_certificate www.example.com.crt; |
75 ssl_certificate_key www.nginx.com.key; | 79 ssl_certificate_key www.example.com.key; |
76 ssl_protocols SSLv3 TLSv1; | 80 ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; |
77 ssl_ciphers HIGH:!aNULL:!MD5; | 81 ssl_ciphers HIGH:!aNULL:!MD5; |
78 ... | 82 ... |
79 </programlisting> | 83 </programlisting> |
80 </para> | 84 </para> |
81 | 85 |
82 </section> | 86 </section> |
86 | 90 |
87 <para> | 91 <para> |
88 有些浏览器不接受那些众所周知的证书认证机构签署的证书,而另外一些浏览器却接受它们。这是由于证书签发使用了一些中间认证机构,这些中间机构被众所周知的证书认证机构授权代为签发证书,但是它们自己却不被广泛认知,所以有些客户端不予识别。针对这种情况,证书认证机构提供一个证书链的包裹,用来声明众所周知的认证机构和自己的关系,需要将这个证书链包裹与服务器证书合并成一个文件。在这个文件里,服务器证书需要出现在认证方证书链的前面: | 92 有些浏览器不接受那些众所周知的证书认证机构签署的证书,而另外一些浏览器却接受它们。这是由于证书签发使用了一些中间认证机构,这些中间机构被众所周知的证书认证机构授权代为签发证书,但是它们自己却不被广泛认知,所以有些客户端不予识别。针对这种情况,证书认证机构提供一个证书链的包裹,用来声明众所周知的认证机构和自己的关系,需要将这个证书链包裹与服务器证书合并成一个文件。在这个文件里,服务器证书需要出现在认证方证书链的前面: |
89 | 93 |
90 <programlisting> | 94 <programlisting> |
91 $ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt | 95 $ cat www.example.com.crt bundle.crt > www.example.com.chained.crt |
92 </programlisting> | 96 </programlisting> |
93 | 97 |
94 这个文件需要使用<literal>ssl_certificate</literal>指令来引用: | 98 这个文件需要使用<link doc="ngx_http_ssl_module.xml" id="ssl_certificate"/>指令来引用: |
95 | 99 |
96 <programlisting> | 100 <programlisting> |
97 server { | 101 server { |
98 listen 443; | 102 listen 443; |
99 server_name www.nginx.com; | 103 server_name www.example.com; |
100 ssl on; | 104 ssl on; |
101 ssl_certificate www.nginx.com.chained.crt; | 105 ssl_certificate www.example.com.chained.crt; |
102 ssl_certificate_key www.nginx.com.key; | 106 ssl_certificate_key www.example.com.key; |
103 ... | 107 ... |
104 } | 108 } |
105 </programlisting> | 109 </programlisting> |
106 | 110 |
107 如果服务器证书和认证方证书链合并时顺序弄错了,nginx就不能正常启动,而且会显示下面的错误信息: | 111 如果服务器证书和认证方证书链合并时顺序弄错了,nginx就不能正常启动,而且会显示下面的错误信息: |
108 | 112 |
109 <programlisting> | 113 <programlisting> |
110 SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed | 114 SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed |
111 (SSL: error:0B080074:x509 certificate routines: | 115 (SSL: error:0B080074:x509 certificate routines: |
112 X509_check_private_key:key values mismatch) | 116 X509_check_private_key:key values mismatch) |
113 </programlisting> | 117 </programlisting> |
114 | 118 |
115 因为nginx首先需要用私钥去解密服务器证书,而遇到的却是认证方的证书。 | 119 因为nginx首先需要用私钥去解密服务器证书,而遇到的却是认证方的证书。 |
141 /OU=ValiCert Class 2 Policy Validation Authority | 145 /OU=ValiCert Class 2 Policy Validation Authority |
142 /CN=http://www.valicert.com//emailAddress=info@valicert.com | 146 /CN=http://www.valicert.com//emailAddress=info@valicert.com |
143 ... | 147 ... |
144 </programlisting> | 148 </programlisting> |
145 | 149 |
146 在这个例子中,www.GoDaddy.com的服务器证书(#0)的受签者(“s”)是被签发机构(“i”)签名的,而这个签发机构又是证书(#1)的受签者,接着证书(#1)的签发机构又是证书(#2)的受签者,最后证书(#2)是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中,被浏览器自动识别。 | 150 在这个例子中,www.GoDaddy.com的服务器证书(#0)的受签者(“s”)是被签发机构(“i”)签名的,而这个签发机构又是证书(#1)的受签者,接着证书(#1)的签发机构又是证书(#2)的受签者,最后证书(#2)是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中,被浏览器自动识别(这段话神似英国诗《在Jack盖的房子里》里面的内容)。 |
147 </para> | 151 </para> |
148 | 152 |
149 <para> | 153 <para> |
150 如果没有加入认证方证书链,那只能看到服务器证书(#0)。 | 154 如果没有加入认证方证书链,就只会显示服务器证书(#0)。 |
151 </para> | 155 </para> |
152 | 156 |
153 </section> | 157 </section> |
154 | 158 |
155 | 159 |
156 <section id="single_http_https_server" name="统一的HTTP/HTTPS主机"> | 160 <section id="single_http_https_server" name="合并HTTP/HTTPS主机"> |
157 | 161 |
158 <para> | 162 <para> |
159 从开始就将HTTP主机和HTTPS主机分开配置是很好一个很好的实践。虽然它们的功能现在看来是一样的,但是这个情况将来可能会有很大变化,那么合在一起的配置就有问题了。如果HTTP和HTTPS主机配置相同,而又不考虑将来重写配置的话,可以用一个主机配置统一处理HTTP和HTTPS请求。方法是删除<literal>ssl on</literal>的配置项,并在*:443端口添加参数<literal>ssl</literal>: | 163 如果HTTP和HTTPS虚拟主机的功能是一致的,可以配置一个虚拟主机,既处理HTTP请求,又处理HTTPS请求。 |
160 <programlisting> | 164 配置的方法是删除<literal>ssl on</literal>的指令,并在*:443端口添加参数<literal>ssl</literal>: |
161 server { | 165 <programlisting> |
162 listen 80; | 166 server { |
163 listen 443 ssl; | 167 listen 80; |
164 server_name www.nginx.com; | 168 listen 443 ssl; |
165 ssl_certificate www.nginx.com.crt; | 169 server_name www.example.com; |
166 ssl_certificate_key www.nginx.com.key; | 170 ssl_certificate www.example.com.crt; |
171 ssl_certificate_key www.example.com.key; | |
167 ... | 172 ... |
168 } | 173 } |
169 </programlisting> | 174 </programlisting> |
170 | 175 |
171 <note> | 176 <note> |
172 在0.8.21版本以前,只有添加了<literal>default</literal>参数的监听端口才能添加<literal>ssl</literal>参数: | 177 在0.8.21版本以前,只有添加了<literal>default</literal>参数的监听端口才能添加<literal>ssl</literal>参数: |
173 <programlisting> | 178 <programlisting> |
174 listen 443 default ssl; | 179 listen 443 default ssl; |
175 </programlisting> | 180 </programlisting> |
176 </note> | 181 </note> |
177 </para> | 182 </para> |
178 | 183 |
179 </section> | 184 </section> |
180 | 185 |
181 | 186 |
182 <section id="name_based_https_servers" name="基于名字的HTTPS主机"> | 187 <section id="name_based_https_servers" name="基于名字的HTTPS主机"> |
183 | 188 |
184 <para> | 189 <para> |
185 在同一个IP上配置多个HTTPS主机,会出现问题: | 190 如果在同一个IP上配置多个HTTPS主机,会出现一个很普遍的问题: |
186 | 191 |
187 <programlisting> | 192 <programlisting> |
188 server { | 193 server { |
189 listen 443; | 194 listen 443; |
190 server_name www.nginx.com; | 195 server_name www.example.com; |
191 ssl on; | 196 ssl on; |
192 ssl_certificate www.nginx.com.crt; | 197 ssl_certificate www.example.com.crt; |
193 ... | 198 ... |
194 } | 199 } |
195 | 200 |
196 server { | 201 server { |
197 listen 443; | 202 listen 443; |
198 server_name www.nginx.org; | 203 server_name www.example.org; |
199 ssl on; | 204 ssl on; |
200 ssl_certificate www.nginx.org.crt; | 205 ssl_certificate www.example.org.crt; |
201 ... | 206 ... |
202 } | 207 } |
203 </programlisting> | 208 </programlisting> |
204 | 209 |
205 使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机的证书,比方说就是<literal>www.nginx.com</literal>。这是由SSL协议本身的行为引起的。因为SSL规定在建立SSL连接以后,才能发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。 | 210 使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机<literal>www.example.com</literal>的证书。这是由SSL协议本身的行为引起的——先建立SSL连接,再发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。 |
206 </para> | 211 </para> |
207 | 212 |
208 <para> | 213 <para> |
209 最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址: | 214 最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址: |
210 | 215 |
211 <programlisting> | 216 <programlisting> |
212 server { | 217 server { |
213 listen 192.168.1.1:443; | 218 listen 192.168.1.1:443; |
214 server_name www.nginx.com; | 219 server_name www.example.com; |
215 ssl on; | 220 ssl on; |
216 ssl_certificate www.nginx.com.crt; | 221 ssl_certificate www.example.com.crt; |
217 ... | 222 ... |
218 } | 223 } |
219 | 224 |
220 server { | 225 server { |
221 listen 192.168.1.2:443; | 226 listen 192.168.1.2:443; |
222 server_name www.nginx.org; | 227 server_name www.example.org; |
223 ssl on; | 228 ssl on; |
224 ssl_certificate www.nginx.org.crt; | 229 ssl_certificate www.example.org.crt; |
225 ... | 230 ... |
226 } | 231 } |
227 </programlisting> | 232 </programlisting> |
228 </para> | 233 </para> |
229 | 234 |
232 | 237 |
233 <section id="certificate_with_several_names" | 238 <section id="certificate_with_several_names" |
234 name="带有多个主机名的SSL证书"> | 239 name="带有多个主机名的SSL证书"> |
235 | 240 |
236 <para> | 241 <para> |
237 也有其他一些方法可以实现多个HTTPS主机共享一个IP地址,但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书,比如<literal>www.nginx.com</literal>和<literal>www.nginx.org</literal>。这种方法的限制是“SubjectAltName”字段的长度。 | 242 也有其他一些方法可以实现多个HTTPS主机共享一个IP地址,但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书,比如<literal>www.example.com</literal>和<literal>www.example.org</literal>。但是,“SubjectAltName”字段的长度有限制。 |
238 </para> | 243 </para> |
239 | 244 |
240 <para> | 245 <para> |
241 另一种方式是使用主机名中含有通配符的证书,比如<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>。 | 246 另一种方式是使用主机名中含有通配符的证书,比如<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>。 |
242 </para> | 247 </para> |
243 | 248 |
244 <para> | 249 <para> |
245 最好将带有多个名字的证书和它的密钥文件配置在http配置块中,这样可以只保存一份内容拷贝,所有主机的配置都从中继承: | 250 最好将带有多个名字的证书和它的密钥文件配置在<i>http</i>配置块中,这样可以只保存一份内容拷贝,所有主机的配置都从中继承: |
246 | 251 |
247 <programlisting> | 252 <programlisting> |
248 ssl_certificate common.crt; | 253 ssl_certificate common.crt; |
249 ssl_certificate_key common.key; | 254 ssl_certificate_key common.key; |
250 | 255 |
251 server { | 256 server { |
252 listen 443; | 257 listen 443; |
253 server_name www.nginx.com; | 258 server_name www.example.com; |
254 ssl on; | 259 ssl on; |
255 ... | 260 ... |
256 } | 261 } |
257 | 262 |
258 server { | 263 server { |
259 listen 443; | 264 listen 443; |
260 server_name www.nginx.org; | 265 server_name www.example.org; |
261 ssl on; | 266 ssl on; |
262 ... | 267 ... |
263 } | 268 } |
264 </programlisting> | 269 </programlisting> |
265 </para> | 270 </para> |
266 | 271 |
268 | 273 |
269 | 274 |
270 <section id="sni" name="主机名指示"> | 275 <section id="sni" name="主机名指示"> |
271 | 276 |
272 <para> | 277 <para> |
273 在一个IP上运行多个HTTPS主机的更通用的方案是<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">TLSv1.1 主机名指示扩展</link>(SNI,RFC3546),它允许浏览器和服务器进行SSL握手时,将请求的主机名传递服务器,因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息: | 278 在一个IP上运行多个HTTPS主机的更通用的方案是<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">TLS主机名指示扩展</link>(SNI,RFC6066),它允许浏览器和服务器进行SSL握手时,将请求的主机名传递给服务器,因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息: |
274 </para> | 279 </para> |
275 | 280 |
281 <para> | |
276 <list type="bullet"> | 282 <list type="bullet"> |
277 | 283 |
278 <listitem> | 284 <listitem> |
279 Opera 8.0; | 285 Opera 8.0; |
280 </listitem> | 286 </listitem> |
294 <listitem> | 300 <listitem> |
295 Chrome(Windows版需要最低Vista操作系统)。 | 301 Chrome(Windows版需要最低Vista操作系统)。 |
296 </listitem> | 302 </listitem> |
297 | 303 |
298 </list> | 304 </list> |
305 <note> | |
306 通过SNI只能传递域名,但是,当请求中包含可读的IP地址时,某些浏览器将服务器的IP地址作为服务器的名字进行了传送。这是一个错误,大家不应该依赖于这个。 | |
307 </note> | |
308 </para> | |
299 | 309 |
300 <para> | 310 <para> |
301 为了在nginx中使用SNI,那么无论是在编译nginx时使用的OpenSSL类库,还是在运行nginx时使用的OpenSSL运行库,都必须支持SNI。从0.9.8f版本开始,OpenSSL通过<nobr>“--enable-tlsext”</nobr>配置选项加入SNI支持,从0.9.8j版本开始,此选项成为默认选项。当nginx被编译成支持SNI时,在使用“-V”选项运行时会显示如下信息: | 311 为了在nginx中使用SNI,那么无论是在编译nginx时使用的OpenSSL类库,还是在运行nginx时使用的OpenSSL运行库,都必须支持SNI。从0.9.8f版本开始,OpenSSL通过<nobr>“--enable-tlsext”</nobr>配置选项加入SNI支持,从0.9.8j版本开始,此选项成为默认选项。当nginx被编译成支持SNI时,在使用“-V”选项运行时会显示如下信息: |
302 | 312 |
303 <programlisting> | 313 <programlisting> |
327 <listitem> | 337 <listitem> |
328 从0.8.21和0.7.62版本开始,使用“-V”选项运行nginx时,将显示SNI支持状态信息。 | 338 从0.8.21和0.7.62版本开始,使用“-V”选项运行nginx时,将显示SNI支持状态信息。 |
329 </listitem> | 339 </listitem> |
330 | 340 |
331 <listitem> | 341 <listitem> |
332 从0.7.14版本开始,<literal>listen</literal>指令支持<literal>ssl</literal>参数。 | 342 从0.7.14版本开始,<link doc="ngx_http_core_module.xml" id="listen"/>指令支持<literal>ssl</literal>参数。 |
333 </listitem> | 343 </listitem> |
334 | 344 |
335 <listitem> | 345 <listitem> |
336 从0.5.32版本开始,支持SNI。 | 346 从0.5.32版本开始,支持SNI。 |
337 </listitem> | 347 </listitem> |
345 | 355 |
346 <para> | 356 <para> |
347 <list type="bullet"> | 357 <list type="bullet"> |
348 | 358 |
349 <listitem> | 359 <listitem> |
350 0.7.65、0.8.19及以后版本,默认SSL协议是SSLv3和TLSv1。 | 360 0.7.65、0.8.19及以后版本,默认SSL协议是SSLv3、TLSv1、TLSc1.1和TLSv1.2(如果OpenSSL库支持)。 |
351 </listitem> | 361 </listitem> |
352 | 362 |
353 <listitem> | 363 <listitem> |
354 0.7.64、0.8.18及以前版本,默认SSL协议是SSLv2、SSLv3和TLSv1。 | 364 0.7.64、0.8.18及以前版本,默认SSL协议是SSLv2、SSLv3和TLSv1。 |
355 </listitem> | 365 </listitem> |