1時間ほどハマったので備忘録的なメモ。もし似たような問題が出た人は参考になるかもしれない。
Windows 8.1がプリインストールされているラップトップパソコンを買って、どんなものかとWindows 10にアップデートしてみた。Window 10の感想についてはここでは述べないが、Windows 10では利用できないとあるサービスの利用を迫られ、仕方なしにVM Playerを導入し、VM上にWindows 7を入れた(ktm@s先生にはお世話になりました)。いろいろと環境整備してしまったあとだったのでWindows 8.1に戻すのが面倒であり、システムリソースも余裕があったのでVMを入れてしまえという感じだった。
さてそこまでは順調だったのだが、VMのwin7でSSL接続ができない。VM toolsのインストールすら証明書がどうこうのエラーが出てできない。ヴァーチャルってレベルじゃねーぞ。さて困った。
結論から言えばホストOSでカスペルスキーを入れてるのが悪かった。というより、そのカスペルスキーの設定がよくなかったのが問題だった。
カスペルスキーにはSSL通信もスキャンする機能があるが、それは中間者攻撃と同じような感じで実装している。もちろんそうするしかないわけだし、それの是非については個々人で意見もあるだろう。ほぼウィルスじゃねえかふざくんな!って人はその機能を使わないだろうが、自分は使っていた。そして「暗号化された接続を常にスキャンする」の設定にしていた。
この設定にしていると、VMからの通信もスキャンするらしく、そこで証明書問題が発生していた。VM上にもカスペの証明書インスコすればいいんじゃね?と思ってゲストOSにもカスペ体験版を入れて証明書をインストールしてみるも何もかわらなかった。
最終的には、ホストOSのカスペルスキーの設定を「保護機能の要求に応じて暗号化された接続をスキャンする」に下げることでVM上からSSL通信ができるようになった。ちなみにこの設定だと接続先によってスキャンするかどうか切り替えているようだ。
というわけで、稀なケースかもしれないが同じような状況に陥った人は参考になるかもしれない。もっと良い方法があればだれか教えてください。
コメント
ホストOSのカスペが生成したルート証明書をゲストOSにインストールすれば良いですよ。
この証明書はカスペをインストールする度に新しく生成されるので、ゲストOSにカスペを入れても別の証明書となるため何の解決にもなりません。
証明書はうちの場合だと以下のパスになります。
C:\ProgramData\Kaspersky Lab\AVP17.0.0\Data\Cert\(fake)Kaspersky Anti-Virus Personal Root Certificate.cer