WindowsサービスからWebサーバーで実行されているWCFサービスへのWCF呼び出しの使用に問題があります。このコールは数週間機能していましたが、突然機能しなくなり、それ以降機能しませんでした。
私が得ている例外は:
一般的なエラーが発生しましたSystem.ServiceModel.CommunicationException:HTTPリクエストの作成中にエラーが発生しました
そして、それは言います
これは、HTTPSの場合、サーバー証明書がHTTP.SYSで正しく構成されていないという事実が原因である可能性があります。これは、クライアントとサーバー間のセキュリティバインディングの不一致によっても発生する可能性があります。
両端で使用しているセキュリティはwsHttpBindingであり、暗号化は一切行われていません。また、HTTPSではなくHTTPのみを使用しているため、HTTPSについて不満を述べている理由はわかりません。
残りの内部例外スタックは次のとおりです。
SystemNet.WebException:基になる接続が閉じられました:送信時に予期しないエラーが発生しました。 ---> System.IO.IOException:トランスポート接続にデータを書き込めません:無効な引数が指定されました。 ---> System.Net.Sockets.SocketException:System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize []のSystem.Net.Sockets.Socket.MultipleSend(BufferOffsetSize [] buffers、SocketFlags socketFlags)で無効な引数が指定されましたバッファー)
また、これが発生するプログラム内のポイントは、Webサービスへの呼び出しの「実行」行にあることに注意してください。つまり、Webサービスを呼び出してラップされたDataContractオブジェクトを渡すとすぐに、爆発します。
このサービスが実行しているのは、大量のXMLを(クライアント側の呼び出しに.NETオブジェクトとして渡して)渡すことだけです。おそらく約100〜200kのXMLが送信されています。両端のデータサイズの制限を6メガ以上に引き上げましたが、それは役に立たなかったようです。
何か案は?
この問題に関する詳細情報:
クライアント環境をローカルに複製すると、次の変更を行わない限り、大量のXMLをアップロードできないことがわかります。1.サーバーで、「maxRequestLength」を100 MBに設定します(送信するよりも大きい)。クライアントの場合、dataContractSerializerタグの下のmaxItemsInObjectGraphの値を「2147483646」に設定します。
これらの変更により、ローカルインストールが正常にアップロードされます。ただし、サーバーへのクライアントのインストールは失敗します。興味深いのは、サーバーでmaxRequestLength値を変更すると、テストインストールが、maxItemsInObjectGraph設定に特に関連するエラーをスローし始めたことです。一方、クライアントのサーバーでは、元の「HTTP.sys」エラーが発生しています。
前述したように、SSLはまったく使用していません。また、XMLを同じ方法で実行およびアップロードする他の2つのWebサービス呼び出しがあります。ただし、非稼働サービスコールはより多くのデータを送信するため、これはサイズの問題のようです。
ただし、クライアントが抱えている問題がテストインストールで発生した問題と同じ場合、クライアントエラーメッセージがObjectGraphエラーに関連しない理由はわかりません。
クライアントで発生する可能性のあるすべてのエラーに対して、一般的な「無効なパラメーター」「HTTP.sys」エラーが発生する可能性はありますか(つまり、実際にはobjectGraphエラーも取得していますが、表示されていないだけですか?)
ホストサーバーがTLS V1.2を使用するように更新され、標準SSLを使用して接続していたため、この問題が発生しました。これは、サイトのペンテストの一環として行われた更新プログラムです。この問題はコード接続で見られましたが、wsdlにアクセスするブラウザーでは見られませんでした。以下のコードが解決しました:
if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
ここから: SSLフォールバックを無効にし、.NETでのアウトバウンド接続にTLSのみを使用するにはどうすればよいですか?(Poodle緩和)
IIS 7で実行されているサービスで同じ問題が発生しました。サービスはこれらの新しいサーバーを追加するときに複数のサプライヤーサーバーに接続します(一部のSSLはそうではありません))元のサーバー(SSL)に対していくつかの要求が行われた後にエラーが発生します。
これを確認するために、単にSystem.Net.ServicePointManager.SecurityProtocol
各サプライヤへの各リクエストの前。
サービスを再起動(またはアプリケーションプールを再起動)した後、出力が低くなりますSsl3, Tls
が、元のサプライヤサーバーへのいくつかの要求の後、これはSsl3
およびTLSサービスへのリクエストによりエラーが発生しました。
修正するには、user369142が提案したことを実行しました。新しいサーバーへの各リクエストの前に:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
それ以上のエラーはありません。
この問題は、真のHTTPSバインディングと「例外は、HTTPSの場合、サーバー証明書がHTTP.SYSで正しく構成されていないことが原因である可能性があります」という同じ例外で発生しました。コードと設定のすべてを二重にチェックした後、エラーメッセージは内部の例外ほど誤解を招かないようですので、簡単なチェックの後、ポート443が(開発サーバー上で)skypeにフックされていることがわかりました。リクエストを保持しているもの(ここではFiddlerが役立ちます)を確認し、サービスフロント(ブラウザーで.svcを表示)とそのメタデータに到達できることを確認することをお勧めします。
幸運を。
私の場合、.NetでSchUseStrongCrypto
を有効にする必要がありました。これにより、サーバーはTLS 1.0、1.1、または1.2を使用して接続を強制します。 SchUseStrongCrypto
が有効になっていないと、接続はSSL 3.0を使用しようとしましたが、これはリモートエンドポイントで無効になりました。
強力な暗号の使用を可能にするレジストリキー:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
多くの検索と無駄な主の名前の取得の後、私はついにそれを手に入れました。wcfサービスが実行されているサーバーにTLS 1.2をインストールしました。クライアントは正しく構成されましたが、.NET 4.5.1 wcfは.NET 4.6.1にありました。 TLS 1.2を使用している場合、クライアントとサーバーの両方が同じ.NETバージョンである必要があります。私はそれがいつか誰かを助けることを願っています:-)
クライアントアプリケーションを4.5以上に変更します。 4.5の場合は、System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12/Tls1.1/Tls1.0を必要に応じて使用するか、アプリケーションを4.6.1以上にアップグレードできます。
私たちにとって、このエラーは、サービスを実行している開発者のコンピューターにIIS 127.0.0.1のみでポート443をバインドするように構成されていたためです。
IIS Managerで、Webサイトを右クリックして[バインディングの編集]を選択します。ポート443
のエントリにIPアドレス127.0.0.1
がある場合は、*
に変更します。
このまったく同じ問題が最近発生しましたが、呼び出し元のコンピューターにインストールされているMicrosoft更新KB980436( http://support.Microsoft.com/KB/980436 )が原因であることが判明しました。完全にアンインストールする以外の修正は、KBサイトの指示に従ってレジストリのUseScsvForTls DWORDを1に設定することでした。この更新プログラムが呼び出し元のシステムにインストールされている場合は、試してみてください。 。
Amazon AWSで古いXP SP3ボックスをIISとglassfishに対して実行します。AmazonはDES-を有効にしないようにデフォルトのロードバランサー設定を変更しました。 CBC3-SHA暗号。古いXP TLS 1.0がHTTPSのELBに対して機能するようにしたい場合は、Amazon ELBで有効にする必要があります。そうしないと、このエラーが発生します。コンソールの「リスナー」タブに移動し、動作させようとしている特定のリスナーの横にある暗号をクリックします。
WCFサービスが.net framework 4.0を使用しており、誰かがサーバーでTLS 1.0を無効にしている場合、この例外が表示されます。 .net 4.0が上位バージョンのTLSをサポートしていないため。
サポートされるプロトコル: https://msdn.Microsoft.com/en-us/library/system.security.authentication.sslprotocols(v = vs.100).aspx
Complex DataTypeの問題に関連するこれらの特定の例外を見てきました。コレクションまたは列挙型を渡す場合は、次の投稿を参照してください。
私たちの問題は、単にエンドポイントのポート番号が誤って8080に設定されていたことです。それを8443に変更し、機能しました。
ブラウザーおよびHttpsモードでサービスを参照してみてください。ブラウズ可能でない場合は、このエラーの理由がわかります。さて、このエラーを解決するには、チェックする必要があります:
すべてが数週間正常に動作してから停止したので、これはあなたのコードと関係があるとは思わない。おそらく、コードが呼び出されたときではなく、IIS/ASP.NET内でサービスがactivatedのときにエラーが発生している可能性があります。ランタイムは、単にWebサイトの構成を確認し、サービスとは関係のない一般的なエラーメッセージをスローしている可能性があります。
私の疑いは、証明書の有効期限が切れているか、バインディングが正しく設定されていないことです。 WebサイトがHTTPS用に正しく構成されていない場合、コードで使用されているかどうかに関係なく、このエラーが発生する可能性があります。
転送モード=ストリーミングを使用している場合は、バッファーに変更してみてください。
これが問題でない場合は、構成を投稿できます。
同じ問題が発生しましたが、この場合、証明書を再インストールし、バインディングを再度作成することで解決しました。私たちを導いたのは、サイトで簡単なPNG画像ファイルを取得しても同じエラーが発生するという事実でした。
最近これを経験しました:
System.ServiceModel.CommunicationException:
http://example.com/WebServices/SomeService.svc へのHTTPリクエストを行っているときにエラーが発生しました。これは、HTTPSの場合、サーバー証明書がHTTP.SYSで適切に構成されていないことが原因である可能性があります。これは、クライアントとサーバー間のセキュリティバインディングの不一致によっても発生する可能性があります。
---> System.Net.WebException:基礎となる接続が閉じられました:送信時に予期しないエラーが発生しました。
---> System.IO.IOException:トランスポート接続にデータを書き込むことができません:既存の接続がリモートホストによって強制的に閉じられました。
管理者から、WebサービスをホストしていたIISアプリケーションプールがメモリ不足になると自動的にリサイクルされることがわかりました。アプリケーションプールのリサイクル時にクライアントでエラーが発生しました。
アプリケーションプールで使用できるメモリを増やすと、すぐに問題が解決しました。
最近これを経験しました:
System.ServiceModel.CommunicationException:
http://example.com/WebServices/SomeService.svc へのHTTPリクエストを行っているときにエラーが発生しました。これは、HTTPSの場合、サーバー証明書がHTTP.SYSで適切に構成されていないことが原因である可能性があります。これは、クライアントとサーバー間のセキュリティバインディングの不一致によっても発生する可能性があります。
---> System.Net.WebException:基礎となる接続が閉じられました:送信時に予期しないエラーが発生しました。
---> System.IO.IOException:トランスポート接続にデータを書き込むことができません:既存の接続がリモートホストによって強制的に閉じられました。
ブルーコートプロキシのライセンスの有効期限が切れました!そのため、外部のパーティ(インターネット)に到達することはできませんでした。
私たちのアプリケーションは最近、ネットワークアプライアンス(F5)OSアップデートを介してSSLからTLSを強制的にオフにしました。自己署名証明書を再生成することにより、このエラーを修正しました。ソリューションに到達する前に複数のメンテナンスウィンドウのトラブルシューティングを行ったため、これが将来誰かが問題を解決するのに役立つことを願っています。