c# - リクエストは中止されました：SSL/TLSのセキュリティで保護されたチャネルを作成できませんでした

Question

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を使用していて、彼がWindowsXPを使用していたことです。それは何かを変えますか？

score 784 · Accepted Answer

私はついに答えを見つけました（私は私の出典を書き留めていませんが、それは検索からのものでした）。

コードはWindowsXPで機能しますが、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ページです。

score 227 · Accepted Answer

これに対する解決策は、.NET4.5では次のとおりです。

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

.NET 4.5をお持ちでない場合は、

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

score 165 · Accepted Answer

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;

score 47 · Accepted Answer

注：ここで最も投票数の多い回答のいくつかは設定ServicePointManager.SecurityProtocolを推奨していますが、Microsoftはそれを行わないように明示的に推奨しています。以下では、この問題の一般的な原因と、それを解決するためのベストプラクティスについて説明します。

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

ASP.NETサイトでは、フレームワークのランタイムバージョンは多くの場合web.configで指定されます。（下記参照）
他のアプリでは、ランタイムバージョンは通常、プロジェクトが新しい.NETバージョンのマシンで実行されているかどうかに関係なく、プロジェクトがビルドされたバージョンです。

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

フレームワークバージョン	デフォルトのプロトコル
4.5以前	SSL 3.0、TLS 1.0
4.6.x	TLS 1.0、1.1、1.2、1.3
4.7+	システム（OS）のデフォルト

古いバージョンの場合、マイレージは、システムにインストールされている.NETランタイムによって多少異なる場合があります。たとえば、非常に古いフレームワークを使用していてTLS 1.0がサポートされていない場合や、4.6.xを使用してTLS1.3がサポートされていない場合があります。

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

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

アプリで.NETFramework4.7以降のバージョンをターゲットにします。WCFアプリで.NETFramework4.7.1以降のバージョンをターゲットにします。

TLSバージョンを指定しないでください。OSがTLSバージョンを決定できるようにコードを構成します。

徹底的なコード監査を実行して、TLSまたはSSLバージョンを指定していないことを確認します。

ASP.NETサイトの場合：targetFramework要素のバージョンを確認します。<httpRuntime>これは（存在する場合）、サイトで実際に使用されているランタイムを決定するためです。

<httpRuntime targetFramework="4.5" />

より良い：

<httpRuntime targetFramework="4.7" />

score 42 · Accepted Answer

https://ct.mob0.com/Styles/Fun.pngをヒットしようとすると、この問題が発生しました。これは、CloudFlareがCDNで配布する画像で、SPDYや奇妙なリダイレクトSSL証明書などのクレイジーなものをサポートしています。

Simonsの回答のようにSsl3を指定する代わりに、次のようにTls12に移動することで修正できました。

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

score 38 · Accepted Answer

あなたが抱えている問題は、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

score 35 · Accepted Answer

エラーは一般的なものであり、SSL/TLSネゴシエーションが失敗する理由はたくさんあります。最も一般的なのは無効または期限切れのサーバー証明書であり、独自のサーバー証明書検証フックを提供することでそれを処理しましたが、必ずしも唯一の理由ではありません。サーバーは相互認証を必要とする場合があり、クライアントでサポートされていない一連の暗号で構成されている場合があります。ハンドシェイクが成功するには時間がかかりすぎる場合があります。その他多くの理由があります。

最善の解決策は、SChannelトラブルシューティングツールセットを使用することです。SChannelはSSLとTLSを担当するSSPIプロバイダーであり、クライアントはそれをハンドシェイクに使用します。TLS/SSLツールと設定を見てください。

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

score 33 · Accepted Answer

この同じ問題で何時間も過ごした後、クライアントサービスが実行されていたASP.NETアカウントに証明書へのアクセス権がないことがわかりました。Webアプリが実行されているIISアプリケーションプールに移動し、[詳細設定]に移動して、IDをからLocalSystemアカウントに変更することで修正しましたNetworkService。

より良い解決策は、証明書をデフォルトのNetworkServiceアカウントで機能させることですが、これは迅速な機能テストに役立ちます。

score 22 · Accepted Answer

設定によるアプローチ

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Tls1.2は安全なプロトコルの最新バージョンであるため、問題ないようです。しかし、私はもっと深く調べて、本当にそれをハードコーディングする必要があるのかと答えることにしました。

仕様：Windows Server2012R2x64。

インターネットから、.NetFramework4.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

しかし、提案されたWindowsUpdateは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+がこれを設定しない理由についての質問に答えることはできません...プロトコル値は自動的に設定されますか？

score 19 · Accepted Answer

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

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

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

うまくいけば、2つのClient Helloメッセージの間にいくつかの違いがあり、SSLネゴシエーションの失敗が失敗の原因となっていることを正確に特定できます。次に、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

score 18 · Accepted Answer

元の答えにはなかったもの。防弾にするために、さらにコードを追加しました。

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

score 15 · Accepted Answer

サーバーがHTTP要求に対してHTTP401Unauthorized応答を返している場合、「要求は中止されました：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のセキュリティで保護されたチャネルを作成できませんでした」という例外が発生しました。

score 14 · Accepted Answer

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

証明書のインポートダイアログ

score 14 · Accepted Answer

ほとんどの人にとって、投票数の多い回答で十分でしょう。ただし、状況によっては、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リクエストが成功するのと同じ理由で、それ自体が機能する可能性があります）。

score 13 · Accepted Answer

これはMVCWebクライアントで私のために働いています

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;
    }
}

score 12 · Accepted Answer

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

<httpRuntime targetFramework="4.5.2" />

ではなく：

<httpRuntime targetFramework="4.6.1" />

score 10 · Accepted Answer

お分かりのように、これが発生する理由はたくさんあります。私が遭遇した原因を追加すると思いました...

の値をに設定する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 ...

score 10 · Accepted Answer

私の場合のこの例外の根本は、コードのある時点で次のように呼び出されていたことです。

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

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

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

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

score 10 · Accepted Answer

これを行うことは私を助けました：

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

score 8 · Accepted Answer

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

mmc
証明書
個人に拡張
証明書を選択
右クリック
すべてのタスク
秘密鍵を管理する
追加

score 8 · Accepted Answer

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

score 7 · Accepted Answer

私は一日中この問題に苦しんでいます。

.NET 4.5で新しいプロジェクトを作成したとき、ようやく機能するようになりました。

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

他のエラーメッセージはありませんが、「要求は中止されました：SSL/TLSのセキュリティで保護されたチャネルを作成できませんでした。」このエラーが発生しました

score 7 · Accepted Answer

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

これは次のように設定できます。

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

設定を[セキュリティ]まで下にスクロールして、次のいずれかを選択します

SSL2.0を使用する
SSL3.0を使用する
TLS1.0を使用する
TLS1.1を使用する
TLS1.2を使用する

score 7 · Accepted Answer

ついに私のための解決策を見つけました。

https url（.Net Framework 4.5の場合）を呼び出す前に、以下の行を追加してみてください。

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

score 6 · Accepted Answer

この答えはどれも私には機能しません。グーグルクロームとポストマンは機能し、サーバーをハンドシェイクしますが、つまり.netは機能しません。グーグルクロームのセキュリティタブ>接続は、ECDHE_RSAとP-256およびAES_256_GCM暗号スイートを使用して暗号化および認証され、サーバーとハンドシェイクすることを示しています。

IIS Cryptoをインストールし、Windows Server2012R2の暗号スイートリストにP-256およびAES_256_GCM暗号スイートのECDHE_RSAが見つかりません。次に、ウィンドウを最後のバージョンに更新しますが、問題は解決しません。最後に検索した後、Windows Server 2012 R2がGSMを正しくサポートしていないことを理解し、サーバーをWindows Server 2016に更新すると、問題が解決しました。

score 5 · Accepted Answer

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

score 5 · Accepted Answer

System.Net.WebException：要求は中止されました：SSL/TLSのセキュリティで保護されたチャネルを作成できませんでした。

私たちの場合、ソフトウェアベンダーを使用しているため、.NETコードを変更するためのアクセス権がありませんでした。どうやら、変更がない限り、.NET4はTLSv1.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

score 5 · Accepted Answer

答えはどれも私にはうまくいきませんでした。

これがうまくいったことです：

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行が必要かどうかさえわかりません...

score 4 · Accepted Answer

これは私のために修正されました。ネットワークサービスをアクセス許可に追加してください。証明書を右クリック>[すべてのタスク]>[秘密鍵の管理...]>[追加...]>[ネットワークサービス]を追加します。

score 4 · Accepted Answer

もう1つの可能性は、実行中のコードに必要な前提条件がないことです。

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

score 3 · Accepted Answer

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

ASP.NETに証明書ストアの証明書の秘密鍵へのアクセスを許可するにはどうすればよいですか？

score 3 · Accepted Answer

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

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）別の回答ですでに言及されているレジストリ設定を追加します。

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

score 3 · Accepted Answer

回答が遅れていることはわかっていますが、Win Server 2012 R2（クライアント）からAPI（Win Server 2016でホストされている）を呼び出そうとすると、同じ問題が発生しました。

多くの調査の結果、この問題はオペレーティングシステムレベルでのハンドシェイクの問題に関連していました。具体的には、クライアントからの暗号のリストがホストサーバーでサポートされていません。

Wiresharkを使用して接続をトレースしたときに問題を知り、送信された暗号がサポートされていないことがわかりました。

Window server 2012 R2は、TLS/SSLハンドシェイクを引き起こす可能性のある新しい暗号のサポートを制限しています。

開始点は、イベントビューア（イベントビューア>>カスタムビュー>>管理イベント）でこのエラー「リモートエンドポイントから致命的なアラートを受信しました。TLSプロトコルで定義された致命的なアラートコードは40です」を見たときでした。

score 2 · Accepted Answer

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

score 2 · Accepted Answer

私の場合、WindowsサービスがWebサービスに接続しようとしたときにこの問題が発生しました。Windowsのイベントを調べてみると、ついにエラーコードが見つかりました。

イベントID36888（Schannel）が発生します：

The following fatal alert was generated: 40. The internal error state is 808.

最後に、それはWindowsHotfixに関連していました。私の場合：KB3172605とKB3177186

vmwareフォーラムで提案されたソリューションは、Windowsにレジストリエントリを追加することでした。次のレジストリを追加すると、すべて正常に機能します。

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ KeyExchangeAlgorithms \ Diffie-Hellman]

"ClientMinKeyBitLength" = dword：00000200

どうやらそれはクライアント側のhttpsハンドシェイクの欠落した値に関連しています。

WindowsHotFixを一覧表示します。

wmic qfe list

ソリューションスレッド：

https://communities.vmware.com/message/2604912#2604912

お役に立てば幸いです。

score 2 · Accepted Answer

上記のほとんどの回答は、セッションアルゴリズムまたはキー交換アルゴリズムに言及しています。

私の場合、どちらも問題なく、問題はサーバーの証明書ハッシュアルゴリズムにあり、クライアントのPCでは有効になりませんでした。

アプリケーションの構成にセクションを追加することがわかりました。

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
        <source name="System.Net">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
        <source name="System.Net.Sockets">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
        <source name="System.Net.Cache">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
    </sources>
    <sharedListeners>
        <add
            name="System.Net"
            type="System.Diagnostics.TextWriterTraceListener"
            initializeData="System.Net.trace.log"
        />
    </sharedListeners>
    <switches>
        <add name="System.Net" value="Verbose" />
        <add name="System.Net.Sockets" value="Verbose" />
        <add name="System.Net.Cache" value="Verbose" />
    </switches>
</system.diagnostics>

そして、ログのエラーが私をこの解決策に導きました

score 1 · Accepted Answer

問題が証明書の有効性に関連しているかどうかを確認するために、デモ証明書のインストールを試みることができます（一部のSSLプロバイダーは1か月間無料で提供しています）。

score 1 · Accepted Answer

これが比較的「ライブ」なリンクである限り、私は新しいオプションを追加すると思いました。その可能性は、Poodle攻撃の問題により、サービスがSSL3.0をサポートしなくなったことです。これに関するGoogleの声明をチェックしてください。私は一度に複数のWebサービスでこの問題に遭遇し、何かが起こっている必要があることに気づきました。TLS 1.2に切り替えましたが、すべてが再び機能しています。

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

score 1 · Accepted Answer

コマンドラインアプリを介してWistiaにビデオをアップロードするときにこの問題が発生しました。システム管理者は、upload.wistia.comのSSLラボスキャンにリストされているIIScryptoを使用して追加の暗号スイートを有効にすることで問題を解決しました。

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256（0x9e）DH2048ビットFS128 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384（0x9f）DH2048ビットFS256

score 1 · Accepted Answer

SOAP / WCFユーザーの場合、このエラーは、サーバーがWS-Security構成を拒否した場合にも発生する可能性があります。クライアントが受け取るエラー情報は非常にあいまいですが、サーバー管理者が理由を特定できる可能性があります。

この例がUsernameTokenプロファイルの下にある場合、メッセージは有効なISO 8601日時ではないと見なされます。これは、<wsu:Created>フォーマットが正しくないか、UTCでないか、サーバー時刻が一致していないためです。

<wsse:UsernameToken wsu:Id="Example-1">
   <wsse:Username> ... </wsse:Username>
   <wsse:Password Type="..."> ... </wsse:Password>
   <wsse:Nonce EncodingType="..."> ... </wsse:Nonce>
   <wsu:Created>2021-01-31T19:00:00.0000000Z</wsu:Created>
</wsse:UsernameToken>

score 1 · Accepted Answer

私の場合、VisualStudio2022で実行していました。何度もこのエラーが発生していました。コードを調べてみると、証明書が正常に取得されていることがわかりました。セキュリティはTLS1.2に設定されており、どちらも上記の回答です。何らかの理由で、管理者としてVisual Studioを実行すると、それが機能しました。たぶん誰かが私にコードがどのようにストアから証明書をうまく取得したかを説明することができます。私はそれとすべてのプロパティを見ることができました。なぜこの世界の名において、私が管理者モードでVSを実行しない限り、それは要求を処理しないのでしょうか？

score 0 · Accepted Answer

デフォルトの.NETServicePointManager.SecurityProtocolはSSLv3とTLSを使用します。Apacheサーバーにアクセスしている場合は、SSLProtocolデフォルトでTLSv1.2と呼ばれる構成変数があります。ServicePointManager.SecurityProtocolWebサーバーでサポートされている適切なプロトコルを使用するようにを設定するか、Apache構成を変更してこのようなすべてのプロトコルを許可することができます。SSLProtocolall

score 0 · Accepted Answer

私は最近同じ問題に遭遇しました。私の環境は、VB.NETを使用した.NET4.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

score 0 · Accepted Answer

コードにパッチを適用したくない、簡単にできない、またはパッチを適用できない場合は、代わりに、フレームワークの.NETコードでTLS1.2を強制的に使用できます。

これは私のアプリではありませんが、古い.NET 4.5アプリ（Server 2008r2で実行）をホットフィックスしてPaypalPayflowGatewayで再び動作させるのに役立ちました。6/25/18から7/8/18の間に、ペイフローゲートウェイコールバックでTLS1.2への接続の強制を開始している必要があります。

詳細：https ：//github.com/TheLevelUp/pos-tls-patcher ダウンロード：https ：//github.com/TheLevelUp/pos-tls-patcher/releases

score 0 · Accepted Answer

私は店とファイルに証明書を持っていました。ファイルに接続しようとすると、このエラーメッセージが表示されます。私が店でそれを使ったとき、それは働きました。私の推測では、ファイルにある証明書を使用したいときに証明書が保管されていた結果、ある種の競合が発生したと思います。（同じマシン上の別のサービスがストア内の証明書を使用し、ファイル内の証明書を使用して別のサービスを開発しました。テストまで開発者の魅力のように機能しました）。

score 0 · Accepted Answer

Windows2008Serverの.NET4.5.2Winformアプリケーションで同じエラーが発生しています。

私は次の修正を試みました：

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls1|SecurityProtocolType.Tls11| SecurityProtocolType.Tls12;

しかし、それはうまくいきませんでした、そして、エラーの発生の数はまだそこにありました。

上記の回答の1つに従って、レジストリのSchUseStrongCryptoキーをオーバーライドする必要がありますか。このキーを設定した場合、副作用はありますか？

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

score 0 · Accepted Answer

レジストリからこのオプションを削除すると、WindowsServer2012で役に立ちました[HKEY_LOCAL_MACHINE\SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ KeyExchangAlgorithms

c# - リクエストは中止されました：SSL/TLSのセキュリティで保護されたチャネルを作成できませんでした

47 に答える 47

Related

Reference