OS:RedHat Linux 7.2 apache1.29 openssl0.96b
カチョバカといいます。
名前ベースのバーチャルホストでSSLを通そうと思っています。
調べたところ、IPベースならうまくいっても名前ベースだとSSLは
できないと分かりました。
それで、SSLを二つ取得して別々のフォルダに置いてやり、それぞれのホストで別個のcrt・keyファイルを参照するようにしてみました。
<Virtualhost *:80>
serverrroot home/html
serevername www.kcn.ne.jp
<Virtualhost *:80>
serverrroot home/html/test
serevername test.kcn.ne.jp
<Virtualhost *:443>
serverrroot home/html
serevername www.kcn.ne.jp
SSLCertificateFile /usr/local/ssl/server.crt
SSLCertificateKeyFile /usr/local/ssl/server.key
<Virtualhost *:443>
serverrroot home/html/test
serevername test.kcn.ne.jp
SSLCertificateFile /usr/local/ssltest/servertest.crt
SSLCertificateKeyFile /usr/local/ssltest/servertest.key
CA(クライアント認証)はまだ設定していません。
これでやってみると、
https:www.kcn.ne.jp
https:test.kcn.ne.jp
共に接続はしますが、右下の鍵マークをダブルクリックして発行先を見たところ、両方とも「www.kcn.ne.jp」なっていました。
このままではtest.kcn.ne.jpの方は暗号化はできても認証ができません。
それぞれの発行先を正しく見えるようにする方法というのはないのでしょうか?
> OS:RedHat Linux 7.2 apache1.29 openssl0.96b
>
本論ではないですが、ずいぶん古いシステムを動かされているんですね。メンテが大変ではないですか?
>
> カチョバカといいます。
> 名前ベースのバーチャルホストでSSLを通そうと思っています。
> 調べたところ、IPベースならうまくいっても名前ベースだとSSLは
> できないと分かりました。
そのとおりです。仕組みまで理解されていれば、名前ベースバーチャルホストではどうあがいても以下のとおりの結果しか得られないことは容易にわかると思います。
名前ベースのバーチャルホストでは、アクセスしてきたホスト名をベースにApache が制御します。しかし、SSL セキュアサーバでは 通信を暗号化するためSSLでの認証、セッション確立が一番先に走るため、名前ベースではバーチャルホストへのアクセス前の話なので、無条件に先頭のバーチャルホストと証明書を使って認証するしかなく、そのため下記のような現象になります。
IPベースなら、アクセスしてきたアドレスで振り分けるのでホスト名とは無関係に識別できるので、問題は発生しません。
因みに、クライアント認証は本当に必要なのですか? 単に暗号化したいだけならこれは設定しないことです。これを設定すると、クライアント証明書を持たない端末はSSLでアクセスできなくなることを認識してらっしゃいますよね。チャント書いてあるつもりですが、どうも勘違いされる方が多いので、老婆心ながら・・・。
> それで、SSLを二つ取得して別々のフォルダに置いてやり、それぞれのホストで別個のcrt・keyファイルを参照するようにしてみました。
>
> <Virtualhost *:80>
> serverrroot home/html
> serevername www.kcn.ne.jp
>
> <Virtualhost *:80>
> serverrroot home/html/test
> serevername test.kcn.ne.jp
>
> <Virtualhost *:443>
> serverrroot home/html
> serevername www.kcn.ne.jp
>
> SSLCertificateFile /usr/local/ssl/server.crt
> SSLCertificateKeyFile /usr/local/ssl/server.key
>
> <Virtualhost *:443>
> serverrroot home/html/test
> serevername test.kcn.ne.jp
>
> SSLCertificateFile /usr/local/ssltest/servertest.crt
> SSLCertificateKeyFile /usr/local/ssltest/servertest.key
>
>
> CA(クライアント認証)はまだ設定していません。
> これでやってみると、
> https:www.kcn.ne.jp
> https:test.kcn.ne.jp
> 共に接続はしますが、右下の鍵マークをダブルクリックして発行先を見たところ、両方とも「www.kcn.ne.jp」なっていました。
>
> このままではtest.kcn.ne.jpの方は暗号化はできても認証ができません。
> それぞれの発行先を正しく見えるようにする方法というのはないのでしょうか?
ありがとうございました。
ところでIPベースでバーチャルホストを構築すればうまくいくと思い、
こちらのページを参照させてもらいました。
http://www.aconus.com/~oyaji/suse/apache_virtual_suse.htm
この場合、新たに「192.168.1.101」という仮想IPが作られていますが、
これを有効にするにはネットワークでこのIPを通す設定も必要になるのでしょうか?
それともApacheサーバー側だけでよろしいのでしょうか?
> ところでIPベースでバーチャルホストを構築すればうまくいくと思い、
> こちらのページを参照させてもらいました。
> http://www.aconus.com/~oyaji/suse/apache_virtual_suse.htm
>
> この場合、新たに「192.168.1.101」という仮想IPが作られていますが、
> これを有効にするにはネットワークでこのIPを通す設定も必要になるのでしょうか?
> それともApacheサーバー側だけでよろしいのでしょうか?
IPベースのバーチャルサーバというのは、本来物理的に異なるはずのものを単に1台のサーバで共用しただけであり、仮想IPというのは本来別々のNICであるべきものを、更に物理的に共用しただけの話ですから、このIPを持つ別のサーバがいるというのと同じです。従って、ルータやファイヤウォールの設定は当然2台目のサーバとして設定が必要です。更に、インターネット側からもIPベースで別のサーバに見えなければ駄目なので、インターネット側にもグローバルアドレスが2個必要ということです。
なるほど、IPを一つ取得しければいけないのですね。
ところで違う話なのですが、SSLで保護されたページを見ると
ときどきセキュリティの警告メッセージが出ます。
(例)https://www.symantec.co.jp/
メッセージ内容は以下です。
「このセキュリティ証明書は信頼された証明機関から発行されています」
「このセキュリティ証明書の日付は正確です。」
「セキュリティ証明書の名前が無効であるか、サイト名と一致しません。」
この中で3つ目のメッセージで、発行先のアドレスと実際のサーバーのアドレスが異なるために警告が出ているのだと分かりますが、
証明書の表示→証明書のパス
と見ていくと「この証明書は問題ありません。」
と表示されてました。
これは、発行先が異なっていてもベリサインの認証は正しくなされているということでしょうか?
> なるほど、IPを一つ取得しければいけないのですね。
>
>
> ところで違う話なのですが、SSLで保護されたページを見ると
> ときどきセキュリティの警告メッセージが出ます。
> (例)https://www.symantec.co.jp/
> メッセージ内容は以下です。
>
> 「このセキュリティ証明書は信頼された証明機関から発行されています」
> 「このセキュリティ証明書の日付は正確です。」
> 「セキュリティ証明書の名前が無効であるか、サイト名と一致しません。」
>
> この中で3つ目のメッセージで、発行先のアドレスと実際のサーバーのアドレスが異なるために警告が出ているのだと分かりますが、
> 証明書の表示→証明書のパス
> と見ていくと「この証明書は問題ありません。」
> と表示されてました。
>
> これは、発行先が異なっていてもベリサインの認証は正しくなされているということでしょうか?
ということです。例えばおやじのサイトにアクセスした場合、一番上がNGになるはずで、証明書を確認すると問題ないとは出ないはずです。
一番上の部分でエラーが出ていますが、証明のパスの部分では
「問題ありません」
と表示されていましたが・・・
> 一番上の部分でエラーが出ていますが、証明のパスの部分では
> 「問題ありません」
> と表示されていましたが・・・
チョット調べてみました。結果はOSによってバラバラで、MSらしい話ですね。
おやじの認識は、おやじのサイトの証明書は自己署名したものなので、全般では証明書の情報として、「このCAルート証明書は信頼されていません。」が出て、証明のパスの部分では「信頼された証明機関がこの証明書を確認できません。」とでるのが順当と思います。しかし、実態ハラバラ。
・Win2K:全般では証明書の情報として、「このCAルート証明書は信頼されていません。信頼を有効にするにはこの証明書を信頼されたルート証明機関のストアにインストールしてください。」と出て、証明のパスの部分では「信頼された証明機関がこの証明書を確認できません。」とでる。
・WinXP Pro sp2: 接続すらできない。(おやじがいろいろインストールしているせいかもしれません。)
・WinXP Home sp2: カチョバカさんが言っている状態。クライアントはこれでは?なんともいい加減な表示ですね。
おやじとしては、Win2Kが一番それらしいという気がします。
> チョット調べてみました。結果はOSによってバラバラで、MSらしい話ですね。
> おやじの認識は、おやじのサイトの証明書は自己署名したものなので、全般では証明書の情報として、「このCAルート証明書は信頼されていません。」が出て、証明のパスの部分では「信頼された証明機関がこの証明書を確認できません。」とでるのが順当と思います。しかし、実態ハラバラ。
> ・Win2K:全般では証明書の情報として、「このCAルート証明書は信頼されていません。信頼を有効にするにはこの証明書を信頼されたルート証明機関のストアにインストールしてください。」と出て、証明のパスの部分では「信頼された証明機関がこの証明書を確認できません。」とでる。
> ・WinXP Pro sp2: 接続すらできない。(おやじがいろいろインストールしているせいかもしれません。)
> ・WinXP Home sp2: カチョバカさんが言っている状態。クライアントはこれでは?なんともいい加減な表示ですね。
> おやじとしては、Win2Kが一番それらしいという気がします。
自分はXP SP1・SP2(共にPro)、2000で見たのですが、すべて結果は同じで、(ちなみにIEは6.0sp1)
証明書の表示→証明書のパス
と見ていくと「この証明書は問題ありません。」
が表示されていました。
(おやじ様のサイト、シマンテックのサイト共に)
なぜ自分が気になるかというと、ベリサインなどの証明機関から取得したSSLで証明時と違うコモンネーム(サーバー名)で設定したときに必ず
「セキュリティ証明書の名前が無効であるか、サイト名と一致しません。」
とエラーが出ます。
この場合のサーバー証明がどうなっているのか知りたいためです。
たぶん、うまくいっていないと思うのですが・・・。
> 自分はXP SP1・SP2(共にPro)、2000で見たのですが、すべて結果は同じで、(ちなみにIEは6.0sp1)
>
> 証明書の表示→証明書のパス
> と見ていくと「この証明書は問題ありません。」
>
> が表示されていました。
> (おやじ様のサイト、シマンテックのサイト共に)
何で結果が違うのですかね? 少なくともおやじがテストした3台のWindows2Kは、どれもおやじのサイトは「この証明書は問題ありません。」とは出ず「信頼された証明機関がこの証明書を確認できません。」となりますが、何かほかに依存して異なる結果がでるのですかね?
> なぜ自分が気になるかというと、ベリサインなどの証明機関から取得したSSLで証明時と違うコモンネーム(サーバー名)で設定したときに必ず
> 「セキュリティ証明書の名前が無効であるか、サイト名と一致しません。」
> とエラーが出ます。
> この場合のサーバー証明がどうなっているのか知りたいためです。
クライアント側でサーバから受信した証明書の検査をしており、証明書の中にあるCN名と実際にアクセス時に指定したサーバ名(https://サーバ名/)が違えば当然そうなります。ここで、クライアントで受け入れればブラウザを閉じない限り以降は警告せずに暗号化通信をします。
シマンテックのサイトは、「www.symantec.co.jp」というサーバ名でアクセスしたのに証明書のCNが「a248.e.akamai.net」となっているため、「セキュリティ証明書の名前が無効であるか、サイト名と一致しません。」というエラーがでます。但し、ルート証明書は「VeriSign/RSA Sequre Server CA」で署名されており証明書としては信頼できるものであるため、「この証明書は問題ありません。」と表示されて正解です。おやじの場合は、自己署名のものなので、ここが「この証明書は問題ありません。」と表示されるのは明らかにおかしな話です。
因みに自分の証明書の中身を見たいなら、opensslで以下のようにすれば見れます。server.crtはサーバ証明書を指定。
# openssl x509 -text -in server.crt