リクエストは中止されました：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 XPでは機能しますが、Windows 7では最初に追加する必要があります。

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

そして今、それは完全に動作します。

補遺

ロビン・フレンチが述べたように; PayPalの設定中にこの問題が発生した場合は、2018年12月3日までにSSL3がサポートされなくなることに注意してください。TLSを使用する必要があります。こちらが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ツールと設定。

「Schannelイベントログを有効にする方法」も参照してください。

私はこの問題を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.SecurityProtocol = SecurityProtocolType.Tls12

Tls1.2は安全なプロトコルの最新バージョンであるため、問題ないようです。しかし、私はより深く見て、ハードコードする必要があるのか​​と答えました。

仕様：Windows Server 2012R2 x64。

インターネットから、.NetFramework 4.6+はデフォルトでTls1.2を使用する必要があると言われています。しかし、プロジェクトを4.6に更新しても何も起こりませんでした。デフォルトでTls1.2を有効にするためにいくつかの変更を手動で行う必要があることを示す情報が見つかりました

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

しかし、提案されたWindows UpdateはR2バージョンでは機能しません

しかし、私を助けたのはレジストリに2つの値を追加することです。次のPSスクリプトを使用して、自動的に追加されるようにすることができます

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

そういうものを探していました。しかし、それでもなぜNetFramework 4.6+がこれを自動的に設定しないのか疑問に答えることはできません...プロトコル値を自動的に？

元の答えにはなかったもの。私はそれを弾丸証明にするためにいくつかのコードを追加しました。

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

別の可能性は、ボックスでの不適切な証明書のインポートです。丸で囲まれたチェックボックスを必ず選択してください。最初は私はそれをしなかったので、秘密鍵が見つからなかったため、コードがタイムアウトになるか、同じ例外をスローしました。

サーバーがHTTP要求に対してHTTP 401 Unauthorized応答を返している場合、「要求は中止されました：SSL / TLSセキュアチャネルを作成できませんでした」という例外が発生する可能性があります。

この回答で説明されているように、クライアントアプリケーションのトレースレベルのSystem.Netログをオンにすることで、これが発生しているかどうかを確認できます。

ロギング構成が整ったら、アプリケーションを実行してエラーを再現し、ロギング出力で次のような行を探します。

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

私の状況では、サーバーが予期していた特定のCookieを設定できず、サーバーが要求に応答して401エラーが返され、「SSL / TLSセキュアチャネルを作成できませんでした」という例外が発生しました。

The request was aborted: Could not create SSL/TLS secure channelエラーの別の考えられる原因は、クライアントPCの構成されたcipher_suites値と、サーバーが受け入れ可能であるように構成されている値との不一致です。この場合、クライアントが最初のSSLハンドシェイク/ネゴシエーション「Client Hello」メッセージで受け入れることができるcipher_suites値のリストを送信すると、サーバーは提供された値のいずれも受け入れられないことを認識し、「アラートSSLハンドシェイクの「Server Hello」ステップに進む代わりに、「応答」。

この可能性を調査するには、Microsoft Message Analyzerをダウンロードし、それを使用して（C＃アプリで）サーバーへのHTTPS接続を確立しようとして失敗したときに発生するSSLネゴシエーションのトレースを実行します。

別の環境（例：言及したWindows XPマシン）からHTTPS接続を正常に確立できた場合、またはOSの暗号スイート設定を使用していないMicrosoft以外のブラウザーでHTTPS URLにアクセスした場合ChromeまたはFirefox）、その環境で別のメッセージアナライザートレースを実行して、SSLネゴシエーションが成功したときに何が起こるかをキャプチャします。

うまくいけば、失敗したSSLネゴシエーションがそれを失敗させている原因を正確に特定できるようにする2つのClient Helloメッセージの間にいくつかの違いが見られるでしょう。次に、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

私の場合、この例外の原因は、コードのある時点で次のものが呼び出されていたことです。

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

これは本当に悪いです。これは、.NETに安全でないプロトコルを使用するように指示するだけでなく、アプリドメイン内で後で行われるすべての新しいWebClient（および同様の）リクエストに影響を与えます。（ASP.NETアプリでは着信Webリクエストは影響を受けませんが、外部Webサービスと通信するなどの新しいWebClientリクエストは影響を受けます）。

私の場合、それは実際には必要ではなかったので、ステートメントを削除するだけで、他のすべてのWeb要求が再び正常に機能し始めました。他の場所での私の読書に基づいて、私はいくつかのことを学びました：

• これはアプリドメインのグローバル設定であり、同時アクティビティがある場合、確実に1つの値に設定し、アクションを実行してから、元に戻すことはできません。その小さなウィンドウの間に別のアクションが発生し、影響を受ける可能性があります。
• 正しい設定は、デフォルトのままにします。これにより、時間が経過してフレームワークをアップグレードしても、.NETは最も安全なデフォルト値を使用し続けることができます。これをTLS12（この記事の執筆時点で最も安全です）に設定すると、現在は機能しますが、5年後には不可解な問題が発生する可能性があります。
• 本当に値を設定する必要がある場合は、別の専用アプリケーションまたはアプリドメインで行うことを検討し、値とメインプールの間でやり取りする方法を見つける必要があります。これは単一のグローバル値であるため、ビジーなアプリプール内で管理しようとしても問題が発生するだけです。この回答：https : //stackoverflow.com/a/26754917/7656 は、カスタムプロキシを介して可能なソリューションを提供します。（私はそれを個人的に実装していないことに注意してください。）

私のweb.configに次のものがあったため、この問題が発生しました：

<httpRuntime targetFramework="4.5.2" />

ではなく：

<httpRuntime targetFramework="4.6.1" />

ご存知のように、これが起こる理由はたくさんあります。私が遭遇した原因を追加すると思いました...

の値を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 ...

の上位投票の回答、おそらくほとんどの人々のために十分でしょう。ただし、状況によっては、TLS 1.2を強制した後でも、「SSL / TLSセキュアチャネルを作成できませんでした」というエラーが発生し続ける場合があります。もしそうなら、あなたはこの役に立つ記事を参照したいかもしれません追加のトラブルシューティング手順。要約すると、TLS / SSLバージョンの問題とは関係なく、クライアントとサーバーは「暗号スイート」に同意する必要があります。SSL接続の「ハンドシェイク」フェーズ中に、クライアントはサポートされている暗号スイートを一覧表示し、サーバーが独自のリストと照合します。ただし、一部のWindowsマシンでは、特定の一般的な暗号スイートが無効になっている可能性があり（攻撃対象を制限しようとする意図的な試みが原因）、クライアントとサーバーが暗号スイートに同意する可能性が低くなります。同意できない場合は、イベントビューアに「致命的なアラートコード40」、。NETプログラムに「SSL / TLSセキュアチャネルを作成できませんでした」と表示されることがあります。

前述の記事では、マシンでサポートされている可能性のある暗号スイートをすべてリストし、Windowsレジストリを介して追加の暗号スイートを有効にする方法について説明しています。クライアントで有効になっている暗号スイートを確認するには、MSIEのこの診断ページにアクセスしてみてください。（System.Netトレースを使用すると、より明確な結果が得られる場合があります。）サーバーがサポートしている暗号スイートを確認するには、このオンラインツールを試してください（サーバーがインターネットにアクセスできる場合）。言うまでもなく、レジストリの編集は、特にネットワークが関係している場合は、慎重に行う必要があります。（ご使用のマシンはリモートでホストされているVMですか？ネットワークを切断した場合、VMはまったくアクセスできますか？）

私の会社の場合、差し迫った問題を修正し、将来の問題から保護するために、レジストリ編集を介していくつかの追加の「ECDHE_ECDSA」スイートを有効にしました。ただし、レジストリを編集できない（または編集しない）場合は、多数の回避策（必ずしもきれいではない）が思い浮かびます。たとえば、.NETプログラムは、SSLトラフィックを別のPythonプログラムに委任できます（影響を受けるマシンでMSIEリクエストが失敗した場合にChromeリクエストが成功するのと同じ理由で、それ自体が機能する場合があります）。

この問題の最大の原因の1つは、アクティブな.NET Frameworkバージョンです。.NET Frameworkランタイムバージョンは、デフォルトで有効になっているセキュリティプロトコルに影響します。

異なるバージョンで具体的にどのように機能するかについての信頼できるドキュメントはないようですが、デフォルトは多かれ少なかれ次のように決定されているようです：

• .NET Framework 4.5およびそれ以前-SSL 3.0、TLS 1.0
• .NET Framework 4.6.x-TLS 1.0、1.1、1.2、1.3
• .NET Framework 4.7以降-システム（OS）のデフォルト

（古いバージョンの場合、システムにインストールされている.NETランタイムに応じて、距離は多少異なります。たとえば、非常に古いフレームワークを使用していて、TLS 1.0がサポートされていない、または4.6を使用している場合があります。 xおよびTLS 1.3はサポートされていません）

Microsoftのドキュメントでは、4.7以降とシステムデフォルトを使用することを強くお勧めしています。

次のことをお勧めします。

• アプリの.NET Framework 4.7以降のバージョンをターゲットにします。WCFアプリで.NET Framework 4.7.1以降のバージョンをターゲットにします。
• TLSバージョンを指定しないでください。OSがTLSバージョンを決定するようにコードを構成します。
• 徹底的なコード監査を実行して、TLSまたはSSLバージョンを指定していないことを確認します。

ASP.NETサイトの場合、<httpRuntime>要素で.NETフレームワークのバージョンを確認します。これにより、サイトで実際に使用されるランタイムが決まります。

<httpRuntime targetFramework="4.5" />

より良い：

<httpRuntime targetFramework="4.7" />

これは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;
        }
    }

クライアントがWindowsマシンの場合、考えられる理由は、サービスに必要なtlsまたはsslプロトコルがアクティブ化されていないことです。

これは次の場所で設定できます。

コントロールパネル->ネットワークとインターネット->インターネットオプション->詳細設定

[セキュリティ]まで設定をスクロールして、どちらかを選択します

• SSL 2.0を使用する
• SSL 3.0を使用する
• TLS 1.0を使用する
• TLS 1.1を使用する
• TLS 1.2を使用する

私の場合、アプリケーションを実行しているサービスアカウントには、秘密鍵にアクセスする権限がありませんでした。この許可を与えると、エラーはなくなりました

1. mmc
2. 証明書
3. 個人に拡大
4. 証明書を選択
5. 右クリック
6. すべてのタスク
7. 秘密鍵を管理する
8. 追加

Visual Studioからコードを実行している場合は、管理者としてVisual Studioを実行してみてください。私の問題を修正しました。

私は一日中この問題に取り組んできました。

.NET 4.5で新しいプロジェクトを作成したとき、ようやく動作しました。

しかし、4.0にダウングレードすると同じ問題が再び発生し、そのプロジェクトではそれを元に戻すことができませんでした（4.5に再度アップグレードしようとした場合でも）。

奇妙なエラーメッセージはありませんが、「リクエストは中止されました：SSL / TLSセキュアチャネルを作成できませんでした。」このエラーが発生しました

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

これを試して：

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

これは私のために修正され、ネットワークサービスを権限に追加します。証明書を右クリック> [すべてのタスク]> [秘密キーの管理...]> [追加...]> [ネットワークサービス]を追加します。

私の問題は、IISをWebサービスとして展開しようとしていたことです。サーバーに証明書をインストールしましたが、IISを実行するユーザーには、証明書に対する適切なアクセス許可がありませんでした。

証明書ストア内の証明書の秘密キーへのASP.NETアクセスを許可する方法

私はこれと同じ問題を抱えていて、この答えが私にとって適切に機能することがわかりました。キーは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

この質問は一般的なエラーメッセージに関するものであるため、多くの回答が得られます。一部のサーバーではこの問題が発生しましたが、開発マシンでは発生しませんでした。私たちの髪のほとんどを抜いた後、それはマイクロソフトのバグであることがわかりました。

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

基本的に、MSはより弱い暗号化が必要であることを前提としていますが、OSはTLS 1.2のみを許可するようにパッチが適用されているため、恐ろしい「リクエストが中止されました：SSL / TLSセキュアチャネルを作成できませんでした」と表示されます。

3つの修正があります。

1）適切なアップデートでOSにパッチを適用します。http：//www.catalog.update.microsoft.com/Search.aspx？q = kb4458166

2）app.config / web.configファイルに設定を追加します。

3）別の回答ですでに言及されているレジストリ設定を追加します。

これらはすべて、私が投稿したナレッジベースの記事に記載されています。

別の可能性として、実行されているコードに必要な権限がありません。

私の場合、Visual Studioデバッガーを使用してWebサービスへの呼び出しをテストすると、このエラーが発生しました。Visual Studioが管理者として実行されていなかったため、この例外が発生しました。

これは私にとってたった1つのサイトで発生しており、RC4暗号しか利用できないことがわかりました。サーバーを強化する以前の取り組みでは、RC4暗号を無効にしていました。これを再度有効にすると、問題は解決しました。