Mercurial > hg > nginx-site
comparison xml/ja/docs/http/configuring_https_servers.xml @ 0:61e04fc01027
Initial import of the nginx.org website.
author | Ruslan Ermilov <ru@nginx.com> |
---|---|
date | Thu, 11 Aug 2011 12:19:13 +0000 |
parents | |
children | 9d544687d02c |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:61e04fc01027 |
---|---|
1 <!DOCTYPE digest SYSTEM "../../../../dtd/article.dtd"> | |
2 | |
3 <article title="HTTPS サーバの設定" | |
4 link="/ja/docs/http/configuring_https_servers.html" | |
5 lang="ja" | |
6 author="Igor Sysoev" | |
7 translator="DigitalCube Co. Ltd., wokamoto"> | |
8 | |
9 <section> | |
10 | |
11 <para> | |
12 HTTPS サーバを設定するには server ブロックで SSL プロトコルを有効にして、サーバ証明書ファイルと秘密鍵ファイルの場所を指定する必要があります: | |
13 | |
14 <programlisting> | |
15 server { | |
16 listen 443; | |
17 server_name www.nginx.com; | |
18 ssl on; | |
19 ssl_certificate www.nginx.com.crt; | |
20 ssl_certificate_key www.nginx.com.key; | |
21 ssl_protocols SSLv3 TLSv1; | |
22 ssl_ciphers HIGH:!ADH:!MD5; | |
23 ... | |
24 } | |
25 </programlisting> | |
26 | |
27 サーバ証明書とはドメインの所有者情報や、送信情報の暗号化に必要な公開鍵を含む電子証明書です。そのサーバに接続するすべてのクライアントに送られます。秘密鍵はサーバ証明書に含まれる公開鍵で暗号化された情報を復号するために必要な鍵で、秘匿する必要が有ります。アクセスを制限したファイルに保存するようにしてください。ただし、nginx のマスタープロセスからは読めるようにする必要があります。もうひとつの方法として、秘密鍵は証明書と同じファイルに保存することもできます: | |
28 | |
29 <programlisting> | |
30 ssl_certificate www.nginx.com.cert; | |
31 ssl_certificate_key www.nginx.com.cert; | |
32 </programlisting> | |
33 | |
34 この場合もファイルのアクセス権は制限するようにします。証明書と秘密鍵がひとつのファイルに保存されていても、証明書だけがクライアントに送られます。 | |
35 </para> | |
36 | |
37 <para> | |
38 SSL プロトコルの強力なバージョンと暗号に接続を制限するには、ディレクティブ <dirname>ssl_protocols</dirname> と <dirname>ssl_ciphers</dirname> を使用します。バージョン 0.8.20 以降、nginx は <dirname>ssl_protocols SSLv3 TLSv1</dirname> と <dirname>ssl_ciphers HIGH:!ADH:!MD5</dirname> をデフォルトとして使用しているので、これより古い nginx のバージョンでのみ設定してください。 | |
39 </para> | |
40 | |
41 </section> | |
42 | |
43 | |
44 <section name="optimization" title="HTTPS サーバの最適化"> | |
45 | |
46 <para> | |
47 SSL の工程は CPU リソースを余計に消費します。マルチプロセッサシステムでは(利用できる CPU コアの数よりも大きい数の)複数のワーカープロセスを走らせるといいでしょう。最も CPU に負荷がかかる工程は SSL ハンドシェイクです。クライアント毎のこの工程数を最小化するには2つの方法があります。最初の方法はキープアライブ接続を有効にして、ひとつの接続経由で複数のリクエストを送るようにする方法です。二つ目の方法は SSL セッションパラメータを再利用して、並行かつ順次接続のための SSL ハンドシェイクを避ける方法です。セッションはワーカー間で共有される SSL セッションキャッシュに保持され、<dirname>ssl_session_cache</dirname> ディレクティブで設定されています。1メガバイトのキャッシュには約4000のセッションが含まれます。キャッシュのデフォルトタイムアウトは5分です。この値は <dirname>ssl_session_timeout</dirname> ディレクティブを使用して増やすことができます。次の例は10Mの共有セッションキャッシュをもったクアッドコアシステムに最適化された設定例です: | |
48 | |
49 | |
50 <programlisting> | |
51 <b>worker_processes 4</b>; | |
52 | |
53 http { | |
54 <b>ssl_session_cache shared:SSL:10m</b>; | |
55 <b>ssl_session_timeout 10m</b>; | |
56 | |
57 server { | |
58 listen 443; | |
59 server_name www.nginx.com; | |
60 <b>keepalive_timeout 70</b>; | |
61 | |
62 ssl on; | |
63 ssl_certificate www.nginx.com.crt; | |
64 ssl_certificate_key www.nginx.com.key; | |
65 ssl_protocols SSLv3 TLSv1; | |
66 ssl_ciphers HIGH:!ADH:!MD5; | |
67 ... | |
68 </programlisting> | |
69 </para> | |
70 | |
71 </section> | |
72 | |
73 | |
74 <section name="chains" title="SSL 連鎖証明書"> | |
75 | |
76 <para> | |
77 ブラウザによっては有名な認証局によって署名された証明書にエラーをだすことがあります。その一方でその証明書を他のブラウザでは問題なく受け入れることもあります。これは発行している認証局が、有名で信用されている認証局の認証基盤には含まれない特定のブラウザで配布されている中間証明書を使ったサーバ証明書に署名しているからです。このケースでは、認証局は署名されたサーバ証明書に連結されているはずの連鎖証明書のバンドルを提供しています。サーバ証明書は、かならず結合されたファイル内の連鎖証明書に存在している必要があります: | |
78 | |
79 <programlisting> | |
80 $ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt | |
81 </programlisting> | |
82 | |
83 この結合されたファイルを <dirname>ssl_certificate</dirname> ディレクティブで使われるようにします: | |
84 | |
85 <programlisting> | |
86 server { | |
87 listen 443; | |
88 server_name www.nginx.com; | |
89 ssl on; | |
90 ssl_certificate www.nginx.com.chained.crt; | |
91 ssl_certificate_key www.nginx.com.key; | |
92 ... | |
93 } | |
94 </programlisting> | |
95 | |
96 サーバ証明書とバンドルされたものが間違った順序で連結されていた場合、nginx は起動に失敗して次のエラーメッセージを表示します: | |
97 | |
98 <programlisting> | |
99 SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed | |
100 (SSL: error:0B080074:x509 certificate routines: | |
101 X509_check_private_key:key values mismatch) | |
102 </programlisting> | |
103 | |
104 これは、nginx がサーバ証明書ではなくバンドルされた最初の証明書で秘密鍵を使おうとするからです。 | |
105 </para> | |
106 | |
107 <para> | |
108 ブラウザは通常、信頼されている認証局によって署名されている受信した中間証明書を保存します。したがって、よく使われているブラウザは要求された中間証明書をすでに保持しているかもしれませんし、連鎖バンドルなしで送られた証明書にエラーを出すかもしれません。サーバに完全な連鎖証明書を送信させるには <dirname>openssl</dirname> コマンドラインユーティリティを使うといいでしょう。例えば: | |
109 | |
110 <programlisting> | |
111 $ openssl s_client -connect www.godaddy.com:443 | |
112 ... | |
113 Certificate chain | |
114 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US | |
115 /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc | |
116 /OU=MIS Department/<b>CN=www.GoDaddy.com</b> | |
117 /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b) | |
118 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. | |
119 /OU=http://certificates.godaddy.com/repository | |
120 /CN=Go Daddy Secure Certification Authority | |
121 /serialNumber=07969287 | |
122 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. | |
123 /OU=http://certificates.godaddy.com/repository | |
124 /CN=Go Daddy Secure Certification Authority | |
125 /serialNumber=07969287 | |
126 i:/C=US/O=The Go Daddy Group, Inc. | |
127 /OU=Go Daddy Class 2 Certification Authority | |
128 2 s:/C=US/O=The Go Daddy Group, Inc. | |
129 /OU=Go Daddy Class 2 Certification Authority | |
130 i:/L=ValiCert Validation Network/O=<b>ValiCert, Inc.</b> | |
131 /OU=ValiCert Class 2 Policy Validation Authority | |
132 /CN=http://www.valicert.com//emailAddress=info@valicert.com | |
133 ... | |
134 </programlisting> | |
135 | |
136 この例では、<url>www.GoDaddy.com</url> サーバ証明書 #0 の対象 (“<i>s</i>”) はそれ自身が証明書 #1 の対象である発行者 (“<i>i</i>”) によって署名されています。そして、証明書 #1はそれ自身が証明書 #2 の対象である発行者によって署名され、証明書 #2 は有名な発行者である <i>ValiCert, Inc.</i> によって署名されていて、<i>ValiCert, Inc.</i> の証明書はブラウザに組み込まれている証明書ベースに保持されています(こうして連鎖します)。 | |
137 </para> | |
138 | |
139 <para> | |
140 もし証明書バンドルを追加していなければ、サーバ証明書 #0 しか見れません。 | |
141 </para> | |
142 | |
143 </section> | |
144 | |
145 | |
146 <section name="single_http_https_server" title="単一の HTTP/HTTPS サーバ"> | |
147 | |
148 <para> | |
149 最初の段階から HTTP と HTTPS プロトコル用にサーバを分けて設定するのは優れた実践です。現時点では両者の機能性としては等しいかもしれませんが、将来的に大きな変更があるかもしれず、統合されたサーバの使用が問題になるかもしれません。とはいえ、HTTP と HTTPS のサーバが等しく、将来のことを考えたくないのなら、ディレクティブ <dirname>ssl on</dirname> を削除して *:443 ポートに <dirname>ssl</dirname> パラメータを追加することによって HTTP と HTTPS リクエストの両者を扱う単一のサーバを設定することができます: | |
150 | |
151 <programlisting> | |
152 server { | |
153 listen 80; | |
154 listen 443 ssl; | |
155 server_name www.nginx.com; | |
156 ssl_certificate www.nginx.com.crt; | |
157 ssl_certificate_key www.nginx.com.key; | |
158 ... | |
159 } | |
160 </programlisting> | |
161 | |
162 <note> | |
163 0.8.21 以前では、nginx は <dirname>default</dirname> パラメータで待ち受けているソケットに <dirname>ssl</dirname> パラメータをセットすることしかできませんでした: | |
164 <programlisting> | |
165 listen 443 default ssl; | |
166 </programlisting> | |
167 </note> | |
168 </para> | |
169 | |
170 </section> | |
171 | |
172 | |
173 <section name="name_based_https_servers" title="名前ベースの HTTPS サーバ"> | |
174 | |
175 <para> | |
176 単一の IP アドレスを2つ以上の HTTPS サーバで待ち受けるように設定するとよく発生する問題があります: | |
177 | |
178 <programlisting> | |
179 server { | |
180 listen 443; | |
181 server_name www.nginx.com; | |
182 ssl on; | |
183 ssl_certificate www.nginx.com.crt; | |
184 ... | |
185 } | |
186 | |
187 server { | |
188 listen 443; | |
189 server_name www.nginx.org; | |
190 ssl on; | |
191 ssl_certificate www.nginx.org.crt; | |
192 ... | |
193 } | |
194 </programlisting> | |
195 | |
196 この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは <url>www.nginx.com</url> の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。 | |
197 </para> | |
198 | |
199 <para> | |
200 この問題を解決するもっとも古くてもっとも堅実な方法は、各 HTTPS サーバに別個の IP アドレスを割り当てることです: | |
201 | |
202 <programlisting> | |
203 server { | |
204 listen 192.168.1.1:443; | |
205 server_name www.nginx.com; | |
206 ssl on; | |
207 ssl_certificate www.nginx.com.crt; | |
208 ... | |
209 } | |
210 | |
211 server { | |
212 listen 192.168.1.2:443; | |
213 server_name www.nginx.org; | |
214 ssl on; | |
215 ssl_certificate www.nginx.org.crt; | |
216 ... | |
217 } | |
218 </programlisting> | |
219 </para> | |
220 | |
221 </section> | |
222 | |
223 | |
224 <section name="certificate_with_several_names" | |
225 title="複数サーバ名をもつ SSL 証明書"> | |
226 | |
227 <para> | |
228 単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名(例えば、<url>www.nginx.com</url> と <url>www.nginx.org</url>)をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 | |
229 </para> | |
230 | |
231 <para> | |
232 もうひとつの方法は、例えば <url>*.nginx.org</url> のようにワイルドカード名を持った証明書を使用する方法です。この証明書は <url>www.nginx.org</url> にマッチしますが <url>nginx.org</url> や <url>www.sub.nginx.org</url> にはマッチしません。以上の二つの方法は組み合わせることもできます。証明書には、例えば <url>nginx.org</url> と <url>*.nginx.org</url> のように SubjectAltName フィールドに完全一致名とワイルドカード名を含ませることができます。 | |
233 </para> | |
234 | |
235 <para> | |
236 すべてのサーバでひとつのメモリーコピーを継承するためには、複数サーバ名を持つ証明書ファイルとその秘密鍵ファイルを設定の <i>http</i> レベルに置くとよいでしょう: | |
237 | |
238 <programlisting> | |
239 ssl_certificate common.crt; | |
240 ssl_certificate_key common.key; | |
241 | |
242 server { | |
243 listen 443; | |
244 server_name www.nginx.com; | |
245 ssl on; | |
246 ... | |
247 } | |
248 | |
249 server { | |
250 listen 443; | |
251 server_name www.nginx.org; | |
252 ssl on; | |
253 ... | |
254 } | |
255 </programlisting> | |
256 </para> | |
257 | |
258 </section> | |
259 | |
260 | |
261 <section name="sni" title="サーバ名指示(Server Name Indication – SNI)"> | |
262 | |
263 <para> | |
264 単一の IP アドレス上で複数の HTTPS サーバを動かすときのさらに包括的な解決方法として <a href="http://en.wikipedia.org/wiki/Server_Name_Indication">TLSv1.1 Server Name Indication extension(サーバ名指示拡張)</a> (SNI, RFC3546) があります。これは、ブラウザが SSL ハンドシェイクの間にリクエストされたサーバ名を渡せるようにするもので、それによりサーバはその接続でどの証明書を使用するべきかが分かります。しかし、SNI は限られたブラウザしかサポートしていません。現時点では次のブラウザのバージョン以降のものがサポートされています: | |
265 </para> | |
266 | |
267 <list> | |
268 | |
269 <item> | |
270 Opera 8.0 | |
271 </item> | |
272 | |
273 <item> | |
274 MSIE 7.0 (Windows Vista 以降のみ) | |
275 </item> | |
276 | |
277 <item> | |
278 Firefox 2.0 および Mozilla Platform rv:1.8.1 を使用している他のブラウザ | |
279 </item> | |
280 | |
281 <item> | |
282 Safari 3.2.1 (Windows バージョンでは Vista 以降) | |
283 </item> | |
284 | |
285 <item> | |
286 Chrome (Windows バージョンでは Vista 以降) | |
287 </item> | |
288 | |
289 </list> | |
290 | |
291 <para> | |
292 nginx で SNI を使用するためには、nginx バイナリがビルドされたときの OpenSSL ライブラリとランタイムで動的にリンクされるライブラリの両方でサポートされていることが必要です。OpenSSL は設定オプション <nobr>“--enable-tlsext”.</nobr> でビルドされていれば、バージョン 0.9.8f 以降で SNI をサポートしています。OpenSSL 0.9.8j 以降ではこのオプションはデフォルトで有効になっています。nginx が SNI サポート付きでビルドされていれば、“-V” スイッチとともに起動すると nginx が次のように表示します: | |
293 | |
294 <programlisting> | |
295 $ nginx -V | |
296 ... | |
297 TLS SNI support enabled | |
298 ... | |
299 </programlisting> | |
300 | |
301 しかし、SNI が有効になっている nginx が SNI サポート無しの OpenSSL ライブラリに動的にリンクされている場合、nginx は次の警告を表示します: | |
302 | |
303 <programlisting> | |
304 nginx was built with SNI support, however, now it is linked | |
305 dynamically to an OpenSSL library which has no tlsext support, | |
306 therefore SNI is not available | |
307 </programlisting> | |
308 </para> | |
309 | |
310 </section> | |
311 | |
312 | |
313 <section name="compatibility" title="Compatibility"> | |
314 | |
315 <para> | |
316 <list> | |
317 | |
318 <item> | |
319 “-V” スイッチでの SNI サポートステータス表示は 0.8.21 以降と 0.7.62 でサポートされています。 | |
320 </item> | |
321 | |
322 <item> | |
323 <dirname>listen</dirname> ディレクティブの <dirname>ssl</dirname> パラメータは 0.7.14 以降からサポートされています。 | |
324 </item> | |
325 | |
326 <item> | |
327 SNI は 0.5.32 以降からサポートされています。 | |
328 </item> | |
329 | |
330 <item> | |
331 共有 SSL セッションキャッシュは 0.5.6 以降からサポートされています。 | |
332 </item> | |
333 | |
334 </list> | |
335 </para> | |
336 | |
337 <para> | |
338 <list> | |
339 | |
340 <item> | |
341 バージョン 0.7.65 と 0.8.19 以降のデフォルトの SSL プロトコルは SSLv3 と TLSv1 です。 | |
342 </item> | |
343 | |
344 <item> | |
345 バージョン 0.7.64 と 0.8.18 以前のデフォルトの SSL プロトコルは SSLv2、SSLv3、TLSv1 です。 | |
346 </item> | |
347 | |
348 </list> | |
349 </para> | |
350 | |
351 <para> | |
352 <list> | |
353 | |
354 <item> | |
355 バージョン 0.7.65 と 0.8.20 以降のデフォルトの SSL 暗号は <dirname>HIGH:!ADH:!MD5</dirname> です。 | |
356 </item> | |
357 | |
358 <item> | |
359 バージョン 0.8.19 のデフォルトの SSL 暗号は <dirname>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</dirname> です。 | |
360 </item> | |
361 | |
362 <item> | |
363 バージョン 0.7.64 と 0.8.18 以前のデフォルトの SSL 暗号は <dirname>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</dirname> です。 | |
364 </item> | |
365 | |
366 </list> | |
367 </para> | |
368 | |
369 | |
370 </section> | |
371 | |
372 | |
373 </article> |