2008-12-17
SSL のワイルドカード証明書
- 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 で返答されます
トラックバック - http://d.hatena.ne.jp/goodvn/20081217/1229995242
リンク元
- 5 http://q.hatena.ne.jp/1228875899
- 4 http://d.hatena.ne.jp/keyword/ワイルドカード証明書
- 4 http://www.google.co.jp/search?hl=ja&client=firefox-a&rls=org.mozilla:ja:official&q=zip+暗号化+強度+aes-256&btnG=検索&lr=lang_ja
- 3 http://k.hatena.ne.jp/keywordblog/デフォルトゲートウェイ
- 3 http://q.hatena.ne.jp/1228757776
- 3 http://q.hatena.ne.jp/1229458597
- 2 http://k.hatena.ne.jp/keywordblog/ディレクトリ?date=20081209
- 2 http://q.hatena.ne.jp/1228454656
- 2 http://s.hatena.com/goodvn/blogs
- 2 http://www.google.co.jp/search?hl=ja&q=パスフレーズ 暗号化強度&lr=

