要求は中止されました：SSL/TLSセキュリティチャネルを作成できませんでした
このエラーメッセージが表示されるため、WebRequestを使用してHTTPSサーバーに接続することはできません。
The request was aborted: Could not create SSL/TLS secure channel.
私たちは、サーバが使用されたパスを持つ有効なHTTPS証明書を持っていないことを知っています、しかしこの問題を回避するために、我々は別のStackOverflow投稿から取った以下のコードを使います
private void Somewhere() {
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}
private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
return true;
}
問題は、サーバーが証明書を検証せずに上記のエラーで失敗することです。誰が私がすべきかについて何か考えを持っていますか？
私は同僚と私が数週間前にテストを実行し、それが私が上で書いたのと同じようなものでうまく働いていたことに言及するべきです。私たちが発見した唯一の「大きな違い」は、私がWindows 7を使っていて、彼がWindows XPを使っていたということです。それは何かを変えますか？
私はついに答えを見つけました（私は自分の情報源に気付いていませんが、それは検索からのものです）。
コードはWindows 7、Windows XPでは機能しますが、最初に追加する必要があります。
// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons
そして今、それは完璧に動作します。
_補遺_
Robin Frenchが述べたように。 Paypalの設定中にこの問題が発生した場合は、2018年3月3日までにSSL3がサポートされなくなります。これが Paypalページ それについてです。
これに対する解決策は、.NET 4.5では、
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
.NET 4.5をお持ちでない場合は、
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
HttpWebRequestが作成される前にServicePointManagerの設定が行われていることを確認してください。
作品：
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
| SecurityProtocolType.Tls11
| SecurityProtocolType.Tls12
| SecurityProtocolType.Ssl3;
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")
失敗する
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
| SecurityProtocolType.Tls11
| SecurityProtocolType.Tls12
| SecurityProtocolType.Ssl3;
あなたが抱えている問題は、aspNetユーザーが証明書にアクセスできないということです。あなたはwinhttpcertcfg.exeを使用してアクセス権を与える必要があります
これを設定する方法の例は以下にあります。 http://support.Microsoft.com/kb/901183
ステップ2の詳細
編集：最新バージョンのIISでは、この機能は証明書マネージャツールに組み込まれています - 証明書を右クリックし、秘密キーを管理するためのオプションを使用することでアクセスできます。詳細はこちら： https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791
このエラーは一般的なものであり、SSL/TLSネゴシエーションが失敗する理由はたくさんあります。最も一般的なのは無効な、または期限切れのサーバー証明書です。あなた自身のサーバー証明書検証フックを提供することによってそれを世話しましたが、必ずしも唯一の理由ではありません。サーバは相互認証を必要とするかもしれません、それはあなたのクライアントによってサポートされない暗号のスイートで構成されるかもしれません、それは握手が成功するためにあまりにも大きい時間ドリフトともっと多くの理由を持つかもしれません。
最善の解決策は、SChannelトラブルシューティングツールセットを使用することです。 SChannelはSSLとTLSを担当するSSPIプロバイダであり、クライアントはそれをハンドシェイクに使用します。 TLS/SSLツールと設定 を見てください。
https://ct.mob0.com/Styles/Fun.png をヒットさせようとしている私はこの問題を抱えていました。これは、SPDYや奇妙なリダイレクトSSL証明書などのクレイジーなものをサポートするCDNでCloudFlareによって配布されたイメージです。
Simonsの答えのようにSsl3を指定する代わりに、私は次のようにTls12に行くことでそれを修正することができました：
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");
この同じ問題で何時間もの後、クライアントサービスを実行していたASP.NETアカウントに証明書へのアクセス権がないことがわかりました。 Webアプリケーションが実行されているIISアプリケーションプールに移動し、[詳細設定]に移動し、[ID]をLocalSystemアカウントからNetworkServiceアカウントに変更しました。
より良い解決策は、証明書をデフォルトのNetworkServiceアカウントで動作させることですが、これは迅速な機能テストに役立ちます。
元の答えにはなかったもの。私はそれを防弾にするためにもう少しコードを追加しました。
ServicePointManager.Expect100Continue = true;
ServicePointManager.DefaultConnectionLimit = 9999;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
別の可能性は箱の不適当な証明書の輸入です。丸で囲ったチェックボックスを必ず選択してください。最初は私はしなかったので、秘密鍵が見つからなかったため、コードはタイムアウトするか、同じ例外をスローしました。
サーバーがHTTP要求に対して HTTP 401 Unauthorized 応答を返している場合、「要求は中止されました：SSL/TLSセキュアチャネルを作成できませんでした」という例外が発生する可能性があります。
this answer で説明されているように、これが発生しているかどうかを判断するには、クライアントアプリケーションのトレースレベルのSystem.Netロギングをオンにします。
ロギング設定が整ったら、アプリケーションを実行してエラーを再現し、次にロギング出力で次のような行を探します。
System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.
私の状況では、サーバーが予期していた特定のcookieを設定することに失敗し、401エラーでサーバーが要求に応答し、その結果「SSL/TLSセキュアチャネルを作成できませんでした」という例外が発生しました。
これはMVC webclientで私のために働いています
public string DownloadSite(string RefinedLink)
{
try
{
Uri address = new Uri(RefinedLink);
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
using (WebClient webClient = new WebClient())
{
var stream = webClient.OpenRead(address);
using (StreamReader sr = new StreamReader(stream))
{
var page = sr.ReadToEnd();
return page;
}
}
}
catch (Exception e)
{
log.Error("DownloadSite - error Lin = " + RefinedLink, e);
return null;
}
}
私の場合のこの例外の根本は、コードのある時点で次のものが呼び出されていたことです。
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
これは本当に悪いです。安全でないプロトコルを使用するように.NETに指示しているだけでなく、これはあなたのappdomain内でその後に行われるすべての新しいWebClient（および同様の）要求に影響を与えます。 （着信Web要求はASP.NETアプリケーションでは影響を受けませんが、外部Webサービスと通信するなどの新しいWebClient要求は影響を受けます）。
私の場合は、実際には必要ではなかったので、そのステートメントを削除するだけで、他のすべてのWeb要求が正常に機能し始めました。他のところで読んだことに基づいて、私はいくつかのことを学びました：
- これはあなたのappdomainのグローバル設定です、そしてもしあなたが同時のアクティビティを持っているなら、あなたは確実にそれを一つの値に設定し、あなたの行動をし、そしてそれを元に戻すことができません。その小さな窓の間に別の行動が起こり、影響を受ける可能性があります。
- 正しい設定はデフォルトのままにすることです。これにより.NETは、時間が経過してもフレームワークをアップグレードしても、最も安全なデフォルト値を使用し続けることができます。これをTLS12（これを書いている時点で最も安全なもの）に設定することはうまくいくでしょう 今 しかし5年後に不思議な問題を引き起こし始めるかもしれません。
- あなたが本当に値を設定する必要があるならば、あなたは別の特別なアプリケーションまたはappdomainでそれをすることを考慮し、それとあなたのメインプールの間で話す方法を見つけるべきです。これは単一のグローバルな値なので、ビジー状態のアプリケーションプール内で管理しようとしても、問題が生じるだけです。この答え： https://stackoverflow.com/a/26754917/7656 カスタムプロキシを使用して可能な解決策を提供します。 （注：私は個人的には実装していません。）
The request was aborted: Could not create SSL/TLS secure channelエラーのもう1つの考えられる原因は、クライアントPCの設定されたcipher_suites値と、サーバーが受け入れ可能で受け入れ可能として設定されている値との不一致です。この場合、クライアントが最初のSSLハンドシェーク/ネゴシエーションの「Client Hello」メッセージで受け入れることができるcipher_suites値のリストを送信すると、サーバーは提供された値のいずれも受け入れられないことを確認し、「Alert SSLハンドシェイクの「Server Hello」ステップに進む代わりに応答します。
この可能性を調べるには、 Microsoft Message Analyzer をダウンロードし、それを使用して、サーバーへのHTTPS接続の確立を試みたときに失敗するSSLネゴシエーションのトレースを実行できます（C＃アプリで） ）。
別の環境（たとえば、Windows XPマシン）から正常なHTTPS接続を確立できる場合、またはOSを使用しないMicrosoft以外のブラウザーでHTTPS URLにアクセスする場合ChromeやFirefoxなどの暗号スイート設定）は、その環境で別のメッセージアナライザートレースを実行して、SSLネゴシエーションが成功したときに何が起こるかをキャプチャします。
うまくいけば、SSLネゴシエーションが失敗して失敗する原因を正確に特定できるように、2つのClient Helloメッセージの間にいくつかの違いが見られるでしょう。その後、Windowsの構成を変更して、Windowsを成功させることができるはずです。 IISCrypto は、これに使用する優れたツールです（「IIS」の名前にもかかわらず、クライアントPCでも）。
次の2つのWindowsレジストリキーは、PCが使用するcipher_suites値を管理します。
- HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
- HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002
以下に、さまざまなCould not create SSL/TLS secure channel問題のインスタンスを調査して解決した方法の完全な記事を示します。 http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error- in-windows.html
あなたが言うことができるようにこれが起こるかもしれないたくさんの理由があります。私が遭遇した原因を追加しようと思った….
WebRequest.Timeoutの値を0に設定した場合、これがスローされる例外です。以下は私が持っていたコードです...（タイムアウト値のハードコードされた0の代わりに、私は誤って0に設定されたパラメータを持っていました）。
WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...
クライアントがWindowsマシンの場合、考えられる理由は、サービスに必要なTLSまたはSSLプロトコルがアクティブになっていないことです。
これは次のように設定できます。
「コントロールパネル」 - >「ネットワークとインターネット」 - >「インターネットオプション」 - >「詳細」
設定を「セキュリティ」までスクロールして選択します
- SSL 2.0を使用する
- SSL 3.0を使用する
- TLS 1.0を使用する
- TLS 1.1を使用する
- TLS 1.2を使う
私は一日中この問題に苦しんでいます。
.NET 4.5で新しいプロジェクトを作成したとき、ついにそれが機能するようになりました。
しかし、私が4.0にダウングレードした場合、私は再び同じ問題を抱えていました、そしてそれはそのプロジェクトにとって不可逆的でした（私が再び4.5にアップグレードしようとしたときでさえ）。
「リクエストは中止されました。SSL/ TLSセキュアチャネルを作成できませんでした。」 このエラーが発生しました
コードをVisual Studioから実行している場合は、管理者としてVisual Studioを実行してみてください。私のために問題を修正しました。
私のweb.configが持っていたので、私はこの問題を抱えていました：
<httpRuntime targetFramework="4.5.2" />
ではない：
<httpRuntime targetFramework="4.6.1" />
私の場合は、アプリケーションを実行しているサービスアカウントに、秘密キーにアクセスする権限がありませんでした。私がこの許可を与えたら、エラーは消えました
- mmc
- 証明書
- 個人用に拡張
- 証明書を選択
- 右クリック
- すべてのタスク
- 秘密鍵を管理する
- 追加する
私はこれと同じ問題を抱えていて、 この答え /を見つけました。キーは3072です。 このリンク '3072'の修正に関する詳細情報を提供します。
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);
私の場合、2つのフィードで修正が必要でした。
https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss
System.Net.WebException：要求は中止されました：SSL/TLSセキュアチャネルを作成できませんでした。
私たちの場合は、ソフトウェアベンダを使っていたので、.NETコードを変更することはできませんでした。明らかに.NET 4は変更がない限りTLS v 1.2を使用しないでしょう。
私たちに対する修正は、レジストリにSchUseStrongCryptoキーを追加することでした。下記のコードをコピーして.reg拡張子の付いたテキストファイルに貼り付けて実行します。それは問題に対する私達の「パッチ」として役立ちました。
Windows Registry Editor Version 5.00
[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
私にとって問題なのは、WebサービスとしてIISにデプロイしようとしていたのですが、証明書をサーバーにインストールしましたが、IISを実行しているユーザーが正しくない証明書に対するアクセス許可.
この質問は一般的なエラーメッセージに関するものであるため、多くの回答を得ることができます。私たちはいくつかのサーバーでこの問題に遭遇しましたが、私たちの開発マシンではありませんでした。私たちの髪の毛の大部分を引き抜いた後、私たちはそれがマイクロソフトのバグであることがわかりました。
基本的に、MSはあなたがより弱い暗号化を望んでいると仮定しますが、OSはTLS 1.2のみを許可するようにパッチされているので、あなたは恐ろしい「要求は打ち切られました：
3つの修正があります。
1）OSに適切なアップデートを適用します。 http://www.catalog.update.Microsoft.com/Search.aspx?q=kb4458166
2）app.config/web.configファイルに設定を追加してください。
3）既に別の回答で述べられているレジストリ設定を追加します。
これらすべては、私が投稿したナレッジベースの記事に記載されています。
これを試して：
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
これはたった1つのサイトで私のために起こっていました、そしてそれはそれが利用可能なRC4暗号だけを持っていたことが判明しました。サーバーを強化するための以前の取り組みでは、RC4暗号を無効にしていましたが、再度有効にすると問題は解決しました。
問題が証明書の有効性に関連しているかどうかを確認するために、デモ証明書をインストールしてみることができます（一部のSSLプロバイダーは1か月間無料でそれらを提供します）。
上記の回答に加えて、PFXファイルではなくCER証明書をローカルのマシンストアにインポートしたことを確認してください。両方のファイルがあるとよくある間違いです。
これが比較的 "ライブ"のリンクである限り、私は新しいオプションを追加することにしました。その可能性は、Poodle攻撃の問題により、サービスがSSL 3.0をサポートしなくなったことです。これに関するGoogleの声明をご覧ください。私は一度にいくつかのWebサービスでこの問題に遭遇し、何かが起こっていなければならないことに気づきました。私はTLS 1.2に切り替えました、そして、すべては再び働いています。
http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
トップ投票の回答 は、たいていの人にとってはおそらく十分でしょう。ただし、状況によっては、TLS 1.2を強制した後でも「SSL/TLSセキュアチャネルを作成できませんでした」というエラーが表示され続ける可能性があります。そうであれば、追加のトラブルシューティング手順については この役に立つ記事 を参照してください。要約すると、TLS/SSLのバージョンの問題とは無関係に、クライアントとサーバーは「暗号スイート」に同意する必要があります。 SSL接続の「ハンドシェイク」フェーズ中に、クライアントはサーバーが自分自身のリストと照合するためにサポートされている暗号スイートをリストします。しかし一部のWindowsマシンでは（攻撃面を制限するための善意の試みのためと思われる）一般的な暗号スイートが無効にされていることがあり、クライアントとサーバーが暗号スイートで合意する可能性が低くなります。同意できない場合は、イベントビューアに「致命的なアラートコード40」が表示され、.NETプログラムに「SSL/TLSセキュアチャネルを作成できませんでした」と表示されることがあります。
前述の記事では、サポートされている可能性があるすべてのコンピュータの暗号スイートを一覧表示し、Windowsレジストリを介して追加の暗号スイートを有効にする方法について説明しています。クライアントでどの暗号スイートが有効になっているかを確認するには、MSIEの この診断ページ にアクセスしてください。どの暗号スイートがサーバーでサポートされているかを確認するには、 このオンラインツール （サーバーがインターネットにアクセス可能であると仮定して）を試してください。特にネットワークが関係している場合は、Registryの編集は慎重に行わなければならないことは言うまでもありません。 （あなたのマシンはリモートでホストされているVMですか？あなたがネットワーキングを中断することになっていたら、VMはまったくアクセス可能でしょうか？）
私の会社のケースでは、レジストリの編集によっていくつかの追加の "ECDHE_ECDSA"スイートを有効にして、当面の問題を修正し、将来の問題から保護しています。しかし、レジストリを編集できない（または編集できない）場合は、（必ずしもきれいではない）多数の回避策が思い浮かびます。たとえば、.NETプログラムがそのSSLトラフィックを別のPythonプログラムに委譲する可能性があります（影響を受けるコンピュータでMSIE要求が失敗した場合にChrome要求が成功する可能性があるため、それ自体が機能する場合があります）。
これは私のために修正された、アクセス許可にネットワークサービスを追加します。証明書を右クリックし、［すべてのタスク］> ［秘密キーの管理］> ［追加］> ［ネットワークサービス］の順にクリックします。
私の場合、WindowsサービスがWebサービスに接続しようとしたときにこの問題が発生しました。 Windowsのイベントを見ると、ようやくエラーコードが見つかりました。
イベントID 36888（Schannel）が発生します。
The following fatal alert was generated: 40. The internal error state is 808.
最後に、それはWindows Hotfixに関連していました。私の場合：KB3172605とKB3177186
Vmwareフォーラムで提案されている解決策は、ウィンドウズにレジストリエントリを追加することでした。次のレジストリを追加した後、すべてうまくいきます。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman]
"ClientMinKeyBitLength" = dword：00000200
どうやらそれはクライアント側のhttpsハンドシェイクの欠損値に関連しています。
Windows HotFixを一覧表示します。
wmic qfe list
ソリューションスレッド：
https://communities.vmware.com/message/2604912#2604912
それが役立つことを願っています。
デフォルトの.NET ServicePointManager.SecurityProtocolはSSLv3とTLSを使用します。 Apacheサーバーにアクセスしている場合は、SSLProtocolという設定変数があり、デフォルトはTLSv1.2です。 Webサーバでサポートされている適切なプロトコルを使用するようにServicePointManager.SecurityProtocolを設定するか、または SSLProtocolallのようにすべてのプロトコルを許可するようにApacheの設定を変更することができます。
私は最近同じ問題に遭遇しました。私の環境はVB.NETと.NET 4.6.1で動いています。それが私がそれを直した方法です：
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3
ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf util.ValidateServerCertificate)
そしてutil.ValidateServerCertificate関数は次のとおりです。
Public Function ValidateServerCertificate(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
Return True
End Function
あなたがしたくない、簡単にできない、またはすぐにあなたのコードにパッチを当てられないのであれば、代わりにあなたはフレームワークのあなたの.NETコードでTLS 1.2の使用を強制することができます。
これは私のアプリではありませんが、以前の.NET 4.5アプリ（Server 2008r2上で実行されているもの）をPaypal Payflow Gatewayで再び機能させるのに役立ちました。彼らは6/25/18と7/8/18の間のペイフローゲートウェイコールバックでTLS 1.2への接続を強制的に開始したにちがいありません。
詳細： https://github.com/TheLevelUp/pos-tls-patcher ダウンロード： https://github.com/TheLevelUp/pos-tls-patcher/releases
答えのどれも私のために働きませんでした。
これはうまくいったことです：
このようにX509Certifiacte2を初期化する代わりに、
var certificate = new X509Certificate2(bytes, pass);
私はこのようにしました：
var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);
X509KeyStorageFlags.Exportable に注意してください。
私は残りのコード（WebRequestそのもの）を変更しませんでした。
// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://Hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
// etc...
}
実際、最初の2行が必要かどうかさえわかりません….
私は店頭とファイルに証明書を持っていました。ファイルに接続しようとしましたが、このエラーメッセージが表示されました。私が店でそれを使ったときそれは働いた。私は、ファイル上で証明書を使用しようとしたときに証明書が保管されていたために、何らかの衝突が発生したと考えています。 （同じマシン上の異なるサービスが店内の証明書を使用していて、ファイル上の証明書を使用して別のサービスを開発しました。テストまでdevの魅力のように働きました）。