none
Windows7で動作するアプリがWidnows10だと「SSL/TSLで保護されているチャネルを作成できませんでした」となる RRS feed

  • 質問

  • Windows10で「SSL/TSLで保護されているチャネルを作成できませんでした」となるのですが 社内LAN経由(ファイアウォールあり)だとエラーになり、直接インターネットに接続した場合は、 問題なく接続できる状態です。 Windows7で接続できているのでファイアウォールじゃないのかと考えましたが、上記を確認したので ファイアウォールを疑っていますが、Windows7とWindows10では、何か違いがあるのでしょうか? 問題となっているアプリは、HTTPSで通信が可能であれば、動くとしています。
    2016年12月20日 1:04

回答

  • プロキシはなしでインターネット接続できているということですね。

    • Windows 7 の場合
      社内 LAN 経由(ファイヤーウォールあり)⇒ 〇
      直接接続(ファイヤーウォールなし)⇒ 〇
    • Windows 10 の場合
      社内 LAN 経由(ファイヤーウォールあり)⇒ ✖
      直接接続(ファイヤーウォールなし)⇒ 〇

    こういう状況でしょうか。もう少し詳しい状況が明らかである方が良さそうです。

    Windows 7 と Windows 10 にインストールされているクライアント アプリケーションはバージョンなどを含め同じものでしょうか。

    「ファイヤーウォール」と書かれていますが、具体的にネットワーク上のどの場所でどのようなファイヤーウォールを構成されているのでしょう。

    また「社内LANは、VPNで構成されています」というのは、社内 LAN が拠点間で VPN 接続されていて、問題の発生するクライアントからインターネット接続するには VPN を通ってゲートウェイに接続する必要があるという意味でしょうか?

    後は、そのアプリケーションのベンダーに何か情報が無いか確認されていますか?


    hebikuzure

    2016年12月22日 8:44
  • ベンダー側で他ユーザーでの同事例を確認しておらず、また同一ネットワーク/ソフトウェア環境のすべての Windows10 クライアントで同じ現象であれば、Windows 7 には適用されず Windows 10 にのみ適用されるポリシーが影響しているなどのシナリオは考えられますが、実際にすべての Windows 10 環境が NG なのでしょうか。

    念のため新規にクリーンインストールしただけの Windows 10 で同様の現象が起きるか試されても良いかと思います。


    hebikuzure

    2016年12月26日 2:45
  • それは調べないと分からないですよ。

    gpresult とかポリシーの結果セットとかを見るのが基本でしょう。

    あとはネットワークキャプチャで SSL/TLS ハンドシェイクがどんな挙動になってるか調べるとか。


    hebikuzure

    2016年12月26日 10:47
  • サーバーからのレスポンスのパケットであれば、クライアント側の Destination ポートが各々で異なるのは当然です。

    問題がクリティカルであれば、そのアプリケーションのベンダーやシステムを構築した SIer に(有償であっても)サポートを依頼された方が良いのではないかと思います。


    hebikuzure

    2016年12月27日 9:12

すべての返信

  • エラー自体は文字通り SSL/TLS での暗号化通信を確立できなかった場合に表示されるものです。SSL/TLS に利用する証明書の問題などで発生する場合がありますが、直接インターネット接続すればエラーにならないのであれば、その可能性はなさそうです。

    社内 LAN 経由の場合、ファイヤーウォールだけでなく Proxy も経由していませんか。


    hebikuzure

    2016年12月20日 14:54
  • Proxyを設定していません。

    Proxyの設定でWindows7とWindows10で何か違いがあるのでしょうか?

    ちなみに社内LANは、VPNで構成されています。

    2016年12月22日 2:05
  • プロキシはなしでインターネット接続できているということですね。

    • Windows 7 の場合
      社内 LAN 経由(ファイヤーウォールあり)⇒ 〇
      直接接続(ファイヤーウォールなし)⇒ 〇
    • Windows 10 の場合
      社内 LAN 経由(ファイヤーウォールあり)⇒ ✖
      直接接続(ファイヤーウォールなし)⇒ 〇

    こういう状況でしょうか。もう少し詳しい状況が明らかである方が良さそうです。

    Windows 7 と Windows 10 にインストールされているクライアント アプリケーションはバージョンなどを含め同じものでしょうか。

    「ファイヤーウォール」と書かれていますが、具体的にネットワーク上のどの場所でどのようなファイヤーウォールを構成されているのでしょう。

    また「社内LANは、VPNで構成されています」というのは、社内 LAN が拠点間で VPN 接続されていて、問題の発生するクライアントからインターネット接続するには VPN を通ってゲートウェイに接続する必要があるという意味でしょうか?

    後は、そのアプリケーションのベンダーに何か情報が無いか確認されていますか?


    hebikuzure

    2016年12月22日 8:44
  • インストールしているクライアント アプリケーションは、同じものです。

    社内LAN(VPN)上にあるPCから社外インターネットアクセスを行う時にファイアウォールを通過します。

    ファイアウォール機器は、Fortigate 110Cで、https(ポート443)を、許可しています。

    対象のクライアント アプリケーションに限らず、社外アクセスをするためには、同じファイアウォールを通過します。

    アプリケーションのベンダーに確認しましたが、ベンダーや他のユーザ環境では、問題なく動いていると回答がありました。

    2016年12月26日 2:18
  • ベンダー側で他ユーザーでの同事例を確認しておらず、また同一ネットワーク/ソフトウェア環境のすべての Windows10 クライアントで同じ現象であれば、Windows 7 には適用されず Windows 10 にのみ適用されるポリシーが影響しているなどのシナリオは考えられますが、実際にすべての Windows 10 環境が NG なのでしょうか。

    念のため新規にクリーンインストールしただけの Windows 10 で同様の現象が起きるか試されても良いかと思います。


    hebikuzure

    2016年12月26日 2:45
  • 全てのWindow10で同様の現象が起きています。

    Windows10のみに適応されるポリシーを設定した覚えがないのですが、何かあるのでしょうか?

    2016年12月26日 8:55
  • それは調べないと分からないですよ。

    gpresult とかポリシーの結果セットとかを見るのが基本でしょう。

    あとはネットワークキャプチャで SSL/TLS ハンドシェイクがどんな挙動になってるか調べるとか。


    hebikuzure

    2016年12月26日 10:47
  • 簡単ですが、調べたところWindows7 64bitとWindow10 64Bitでの違いは、以下の通りです。

    Windows76  64Bit

      -> Transmission Control Protocol Source Port 443 Destination Port 49280

    Windows10  64Bit

      -> Transmission Control Protocol Source Port 443 Destination Port 62713


    2016年12月27日 4:25
  • サーバーからのレスポンスのパケットであれば、クライアント側の Destination ポートが各々で異なるのは当然です。

    問題がクリティカルであれば、そのアプリケーションのベンダーやシステムを構築した SIer に(有償であっても)サポートを依頼された方が良いのではないかと思います。


    hebikuzure

    2016年12月27日 9:12