Mercurial > hg > nginx-site

comparison xml/ja/docs/http/configuring_https_servers.xml @ 121:49443032011c

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Unified <section> syntax for "article" and "module" documents.
author Ruslan Ermilov <ru@nginx.com>
date Thu, 20 Oct 2011 20:27:51 +0000
parents 9d544687d02c
children 7db449e89e92
comparison
equal deleted inserted replaced
120:da8bd4d2290f 121:49443032011c
39 </para> 39 </para>
40 40
41 </section> 41 </section>
42 42
43 43
44 <section name="optimization" title="HTTPS サーバの最適化"> 44 <section id="optimization" name="HTTPS サーバの最適化">
45 45
46 <para> 46 <para>
47 SSL の工程は CPU リソースを余計に消費します。マルチプロセッサシステムでは（利用できる CPU コアの数よりも大きい数の）複数のワーカープロセスを走らせるといいでしょう。最も CPU に負荷がかかる工程は SSL ハンドシェイクです。クライアント毎のこの工程数を最小化するには２つの方法があります。最初の方法はキープアライブ接続を有効にして、ひとつの接続経由で複数のリクエストを送るようにする方法です。二つ目の方法は SSL セッションパラメータを再利用して、並行かつ順次接続のための SSL ハンドシェイクを避ける方法です。セッションはワーカー間で共有される SSL セッションキャッシュに保持され、<dirname>ssl_session_cache</dirname> ディレクティブで設定されています。１メガバイトのキャッシュには約４０００のセッションが含まれます。キャッシュのデフォルトタイムアウトは５分です。この値は <dirname>ssl_session_timeout</dirname> ディレクティブを使用して増やすことができます。次の例は１０Mの共有セッションキャッシュをもったクアッドコアシステムに最適化された設定例です: 47 SSL の工程は CPU リソースを余計に消費します。マルチプロセッサシステムでは（利用できる CPU コアの数よりも大きい数の）複数のワーカープロセスを走らせるといいでしょう。最も CPU に負荷がかかる工程は SSL ハンドシェイクです。クライアント毎のこの工程数を最小化するには２つの方法があります。最初の方法はキープアライブ接続を有効にして、ひとつの接続経由で複数のリクエストを送るようにする方法です。二つ目の方法は SSL セッションパラメータを再利用して、並行かつ順次接続のための SSL ハンドシェイクを避ける方法です。セッションはワーカー間で共有される SSL セッションキャッシュに保持され、<dirname>ssl_session_cache</dirname> ディレクティブで設定されています。１メガバイトのキャッシュには約４０００のセッションが含まれます。キャッシュのデフォルトタイムアウトは５分です。この値は <dirname>ssl_session_timeout</dirname> ディレクティブを使用して増やすことができます。次の例は１０Mの共有セッションキャッシュをもったクアッドコアシステムに最適化された設定例です:
48 48
49 49
69 </para> 69 </para>
70 70
71 </section> 71 </section>
72 72
73 73
74 <section name="chains" title="SSL 連鎖証明書"> 74 <section id="chains" name="SSL 連鎖証明書">
75 75
76 <para> 76 <para>
77 ブラウザによっては有名な認証局によって署名された証明書にエラーをだすことがあります。その一方でその証明書を他のブラウザでは問題なく受け入れることもあります。これは発行している認証局が、有名で信用されている認証局の認証基盤には含まれない特定のブラウザで配布されている中間証明書を使ったサーバ証明書に署名しているからです。このケースでは、認証局は署名されたサーバ証明書に連結されているはずの連鎖証明書のバンドルを提供しています。サーバ証明書は、かならず結合されたファイル内の連鎖証明書に存在している必要があります: 77 ブラウザによっては有名な認証局によって署名された証明書にエラーをだすことがあります。その一方でその証明書を他のブラウザでは問題なく受け入れることもあります。これは発行している認証局が、有名で信用されている認証局の認証基盤には含まれない特定のブラウザで配布されている中間証明書を使ったサーバ証明書に署名しているからです。このケースでは、認証局は署名されたサーバ証明書に連結されているはずの連鎖証明書のバンドルを提供しています。サーバ証明書は、かならず結合されたファイル内の連鎖証明書に存在している必要があります:
78 78
79 <programlisting> 79 <programlisting>
141 </para> 141 </para>
142 142
143 </section> 143 </section>
144 144
145 145
146 <section name="single_http_https_server" title="単一の HTTP/HTTPS サーバ"> 146 <section id="single_http_https_server" name="単一の HTTP/HTTPS サーバ">
147 147
148 <para> 148 <para>
149 最初の段階から HTTP と HTTPS プロトコル用にサーバを分けて設定するのは優れた実践です。現時点では両者の機能性としては等しいかもしれませんが、将来的に大きな変更があるかもしれず、統合されたサーバの使用が問題になるかもしれません。とはいえ、HTTP と HTTPS のサーバが等しく、将来のことを考えたくないのなら、ディレクティブ <dirname>ssl on</dirname> を削除して *:443 ポートに <dirname>ssl</dirname> パラメータを追加することによって HTTP と HTTPS リクエストの両者を扱う単一のサーバを設定することができます: 149 最初の段階から HTTP と HTTPS プロトコル用にサーバを分けて設定するのは優れた実践です。現時点では両者の機能性としては等しいかもしれませんが、将来的に大きな変更があるかもしれず、統合されたサーバの使用が問題になるかもしれません。とはいえ、HTTP と HTTPS のサーバが等しく、将来のことを考えたくないのなら、ディレクティブ <dirname>ssl on</dirname> を削除して *:443 ポートに <dirname>ssl</dirname> パラメータを追加することによって HTTP と HTTPS リクエストの両者を扱う単一のサーバを設定することができます:
150 150
151 <programlisting> 151 <programlisting>
168 </para> 168 </para>
169 169
170 </section> 170 </section>
171 171
172 172
173 <section name="name_based_https_servers" title="名前ベースの HTTPS サーバ"> 173 <section id="name_based_https_servers" name="名前ベースの HTTPS サーバ">
174 174
175 <para> 175 <para>
176 単一の IP アドレスを２つ以上の HTTPS サーバで待ち受けるように設定するとよく発生する問題があります: 176 単一の IP アドレスを２つ以上の HTTPS サーバで待ち受けるように設定するとよく発生する問題があります:
177 177
178 <programlisting> 178 <programlisting>
219 </para> 219 </para>
220 220
221 </section> 221 </section>
222 222
223 223
224 <section name="certificate_with_several_names" 224 <section id="certificate_with_several_names"
225 title="複数サーバ名をもつ SSL 証明書"> 225 name="複数サーバ名をもつ SSL 証明書">
226 226
227 <para> 227 <para>
228 単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名（例えば、<url>www.nginx.com</url> と <url>www.nginx.org</url>）をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 228 単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名（例えば、<url>www.nginx.com</url> と <url>www.nginx.org</url>）をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。
229 </para> 229 </para>
230 230
256 </para> 256 </para>
257 257
258 </section> 258 </section>
259 259
260 260
261 <section name="sni" title="サーバ名指示（Server Name Indication – SNI）"> 261 <section id="sni" name="サーバ名指示（Server Name Indication – SNI）">
262 262
263 <para> 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 は限られたブラウザしかサポートしていません。現時点では次のブラウザのバージョン以降のものがサポートされています: 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> 265 </para>
266 266
308 </para> 308 </para>
309 309
310 </section> 310 </section>
311 311
312 312
313 <section name="compatibility" title="Compatibility"> 313 <section id="compatibility" name="Compatibility">
314 314
315 <para> 315 <para>
316 <list> 316 <list>
317 317
318 <item> 318 <item>