ApacheにおけるSSLワイルドカード証明書についての質問です。


そもそも、SSLセキュアサーバを
同一IP・同一ポート、名前ベースで設定することができないと思い込んでいたいのですが、
色々検索すると、名前ベース(サブドメイン)でSSLを同一IP・同一ポートで運用し、
さらにワイルドカード証明書も利用できると記載されたページをみかけます。

以下はポートまで言及してないですが例です
http://www.terakado.jp/2008/11/sslnamevirtualhost.html

SSLセキュアサーバを構築した場合、
Apacheがホスト名を取得する前に証明書の確認に入ると思っているので、
前段の仕組みがいまいちわからないでいます。

おおまかな仕組みをご教授ください。

回答の条件
  • 1人2回まで
  • 登録:2008/12/17 05:16:37
  • 終了:2008/12/17 15:48:56

回答(3件)

id:znz No.1

znz回答回数193ベストアンサー獲得回数252008/12/17 12:10:28

ポイント50pt

まず、ワイルドカード証明書とは

http://d.hatena.ne.jp/keyword/%A5%EF%A5%A4%A5%EB%A5%C9%A5%AB%A1%...

http://jp.globalsign.com/service/ssl/option/wildcard.html

などの説明にあるように証明書の中の普通はFQDN(www.example.comなど)が入っているところに「*.example.com」のようにサブドメインが「*」になっている証明書のことです。

サーバ側はこの証明書を普通の証明書の代わりに設定しておきます。

そのサーバにクライアントが接続しに行くときに

http://www.verisign.co.jp/repository/faq/SSL/https.html

の「2. サーバ証明書送付 (サーバ認証)」のところで「*.example.com」の証明書が送られてきて、クライアントが「*」の部分を特別扱いして、つなごうとしているサーバが「foo.example.com」や「bar.example.com」などの場合にOKと判断しています。

id:b-wind No.2

b-wind回答回数3344ベストアンサー獲得回数4402008/12/17 12:36:08

ポイント100pt

そもそも、SSLセキュアサーバを

同一IP・同一ポート、名前ベースで設定することができないと思い込んでいた

厳密な言い方をすると、Apache での設定自体は出来る。そしてサイトもそれぞれ区別される。

ただし、

SSLセキュアサーバを構築した場合、

Apacheがホスト名を取得する前に証明書の確認に入る

この理由により、本来の名前とは別の証明書が送られてしまうケースが出るため「事実上不可能」と言うのがただしい。


つまり実装上の問題はどの証明書を送るか区別できないことだけなので、

ワイルドカード証明書も利用できる

「も」ではなく「ワイルドカード証明書を使用すること」かつ「ワイルドカードの対象のドメインの組み合わせ」のみ名前ベースのバーチャルホストが機能することになる。


とりあえず「ワイルドカード証明書」自体の是非は置くとして原理的にはそれならブラウザのエラー無く表示することは可能。

id:masashi0316

あぁ、大納得。複数の名前ベースバーチャルホストを設定してたとしたら、証明書区別できないから最初のやつ送られるんだろうなと思いました。

ん~、ブラウザ側がワイルドカードを理解すれば警告とかでないわけだ。

なるほど、「是非は置くとして」という記述も納得です。

2008/12/17 15:43:42
id:goodvn No.3

goodvn回答回数228ベストアンサー獲得回数182008/12/17 13:17:18

ポイント100pt

URL の先の,どの技術について言及されているのかが分からないので,私が運用しているワイルドカード証明書における VirtualHost の例でお話します

まず,示されたペイジの繰り返しになってしまいますが,

・www.example.com (10.1.2.3)

・secure.example.com (10.1.2.4)

という構成でサーバが構築されている場合,10.1.2.3 には (CN=www.example.com) の証明書,10.1.2.4 には,(CN=secure.example.com) という証明書を設定すればいい,という話になりますね

しかし,IP アドレスが複数用意できない場合,

・www.example.com (10.1.2.3)

・secure.example.com (10.1.2.3)

という構成で作らざるをえません.すると,secure.example.com へアクセスしようとしても,サーバは (CN=www.example.com) の証明書を返してきますので,ブラウザでは CN の不一致として,警告を発する事になります

そこで,10.1.2.3 に設定するのを,(CN=*.example.com) というワイルドカード証明書にする,というソリューションが出てきます

しかし,10.1.2.3 に対する接続に対し,ユーザのリクエストに応じて,返すコンテンツを判断しないといけない(www.example.com なのか,secure.example.com なのか)ですから,この,10.1.2.3 は,コンテンツを返す VirtualHost ではなく,リバースProxy を動かす専用の VirtualHost として設定します

つまり,

・rproxy.exmaple.com (10.1.2.3:443,CN=*.example.com)

・www.example.com (10.1.2.3:80)

・secure.example.com (10.1.2.3:80)

という構成になります

ユーザが,www.example.com:443 にアクセスすると,(CN=*.example.com) の証明書が返ってきます.これは,CN 一致します

サーバは,Hostname を見て,内部で www.example.com:80 へプロキシします.これにより,ユーザには,www.example.com:80 の内容が,SSL で返答されます

id:masashi0316

さらに細かく理解できました。

お三方ともありがとうございました。

2008/12/17 15:48:38

コメントはまだありません

この質問への反応(ブックマークコメント)

トラックバック

  • SSL のワイルドカード証明書 緑茶は命の水 2008-12-23 10:20:48
    www.example.com (10.1.2.3) secure.example.com (10.1.2.4) という構成でサーバが構築されている場合,10.1.2.3 には (CN=www.example.com) の証明書,10.1.2.4 には,(CN=secure.example.com) という証明書を設定すればいい
「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません