Mercurial > hg > nginx-site

comparison xml/ja/docs/http/configuring_https_servers.xml @ 0:61e04fc01027

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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 ハンドシェイクです。クライアント毎のこの工程数を最小化するには２つの方法があります。最初の方法はキープアライブ接続を有効にして、ひとつの接続経由で複数のリクエストを送るようにする方法です。二つ目の方法は SSL セッションパラメータを再利用して、並行かつ順次接続のための SSL ハンドシェイクを避ける方法です。セッションはワーカー間で共有される SSL セッションキャッシュに保持され、<dirname>ssl_session_cache</dirname> ディレクティブで設定されています。１メガバイトのキャッシュには約４０００のセッションが含まれます。キャッシュのデフォルトタイムアウトは５分です。この値は <dirname>ssl_session_timeout</dirname> ディレクティブを使用して増やすことができます。次の例は１０Mの共有セッションキャッシュをもったクアッドコアシステムに最適化された設定例です:
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 の対象 (&ldquo;<i>s</i>&rdquo;) はそれ自身が証明書 #1 の対象である発行者 (&ldquo;<i>i</i>&rdquo;) によって署名されています。そして、証明書 #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 アドレスを２つ以上の 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>&ldquo;--enable-tlsext&rdquo;.</nobr> でビルドされていれば、バージョン 0.9.8f 以降で SNI をサポートしています。OpenSSL 0.9.8j 以降ではこのオプションはデフォルトで有効になっています。nginx が SNI サポート付きでビルドされていれば、&ldquo;-V&rdquo; スイッチとともに起動すると 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 &ldquo;-V&rdquo; スイッチでの 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>