「権限のあるSSL / TLSセキュアチャネルの信頼関係を確立できませんでした」を解決する方法

私はこの問題を修正したと本当に思っていましたが、以前は偽装されていました。

HTTPSを使用してIIS 7でホストされているWCFサービスがあります。私は、Internet Explorerでこのサイトを参照すると、それは私がするので、これは、魔法のように動作しているローカルルート証明機関ストアに証明書を追加しました。

私は1台のマシンで開発しているので、クライアントとサーバーは同じマシンです。証明書はIIS 7管理スナップインから直接自己署名されます。

私は今もこのエラーを受け取り続けています...

権限を持つSSL / TLSセキュアチャネルの信頼関係を確立できませんでした。

...クライアントコンソールから呼び出されたとき。

findprivatekeyとを使用して、証明書にアクセス許可とネットワークサービスを手動で付与しましたcacls.exe。

私はSOAPUIを使用してサービスに接続しようとしましたが、それは機能します。そのため、クライアントアプリケーションの問題である必要があります。これは、httpでの機能に基づいたコードです。

接続できない理由についてすべての可能性を使い果たしたように見えますか？

回避策として、あなたはにハンドラを追加することができますServicePointManagerのServerCertificateValidationCallbackクライアント側：

System.Net.ServicePointManager.ServerCertificateValidationCallback +=
    (se, cert, chain, sslerror) =>
        {
            return true;
        };

ただし、サーバー証明書を完全に無視し、サービスポイントマネージャーに、クライアントのセキュリティを著しく損なう可能性のある証明書であれば問題ないことを伝えるため、これは良い習慣ではないことに注意してください。これを改良して、いくつかのカスタムチェックを実行できます（証明書名、ハッシュなど）。テスト証明書を使用すると、少なくとも開発中の問題を回避できます。

私がこの問題を抱えているのは、client.configに次のようなエンドポイントがあるためです。

 https://myserver/myservice.svc 

証明書は期待していた

 https://myserver.mydomain.com/myservice.svc

サーバーのFQDNと一致するようにエンドポイントを変更すると、問題が解決します。これがこの問題の唯一の原因ではないことを知っています。

最初の2つはラムダを使用し、3つ目は通常のコードを使用します...

            //Trust all certificates
            System.Net.ServicePointManager.ServerCertificateValidationCallback =
                ((sender, certificate, chain, sslPolicyErrors) => true);

            // trust sender
            System.Net.ServicePointManager.ServerCertificateValidationCallback
                = ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));

            // validate cert by calling a function
            ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);

    // callback used to validate the certificate in an SSL conversation
    private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
    {
        bool result = false;
        if (cert.Subject.ToUpper().Contains("YourServerName"))
        {
            result = true;
        }

        return result;
    }

自己署名キーを使用しているため、問題が発生します。クライアントはこのキーを信頼せず、キー自体が検証するチェーンや証明書失効リストを提供することもありません。

いくつかのオプションがあります-できます

1. クライアントで証明書の検証をオフにする（悪い動き、中間者攻撃が豊富）

2. makecertを使用してルートCAを作成し、そこから証明書を作成します（移動できますが、CRLはまだありません）

3. Windows証明書サーバーまたはその他のPKIソリューションを使用して内部ルートCAを作成し、そのルート証明書を信頼する（管理が少し面倒）

4. 信頼できるCAの1つからSSL証明書を購入する（高価）

1行のソリューション。これをクライアント側のサーバーを呼び出す前に追加します。

System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };

クライアントはSSL / TLSセキュリティチェックをスキップするため、これはテスト目的でのみ使用する必要があります。

同じ問題が発生し、2つの解決策で解決できました。最初に、MMCスナップイン「証明書」を「コンピューターアカウント」に使用し、自己署名証明書を「信頼されたルート証明機関」フォルダーにドラッグしました。 。これは、ローカルコンピューター（証明書を生成したコンピューター）がその証明書を信頼することを意味します。次に、内部コンピュータ名の証明書が生成されているのに、別の名前でWebサービスにアクセスしていることに気付きました。これにより、証明書の検証時に不一致が発生しました。computer.operations.localの証明書を生成しましたが、https：//computer.internaldomain.companydomain.comを使用してWebサービスにアクセスしました。証明書の生成に使用したURLに切り替えたときに、エラーは発生しなくなりました。

URLを切り替えるだけで十分な場合もありますが、証明書を信頼できるものにすることで、証明書を信頼していないことを示すInternet Explorerの赤い画面も回避できます。

.netコアを使用している場合は、これを試してください：

client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
        new X509ServiceCertificateAuthentication()
        {
            CertificateValidationMode = X509CertificateValidationMode.None,
            RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
        };

次の手順を実行してください。

1. IEでサービスリンクを開きます。

2. アドレスバーの証明書エラーの言及をクリックし、証明書の表示をクリックします。

3. 小切手は名前に発行されました。

4. 発行された名前を取得し、サービスおよびクライアントエンドポイントのベースアドレス名のlocalhostの言及を完全修飾ドメイン名（FQDN）に置き換えます。

例：https：// localhost：203 / SampleService.svc To https：// INL-126166-.groupinfra.com：203 / SampleService.svc

上記の回答に加えて、クライアントが間違ったTLSバージョンを実行している場合、たとえばサーバーがTLS 1.2のみを実行している場合に、このエラーが発生する可能性があります。

あなたはそれを修正することができます：

// tested in .NET 4.5:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

同じ問題がありました。ローカルストアにもCA証明書を追加しましたが、間違った方法で追加しました。

mmcコンソール（[スタート]-> [実行]-> [ mmc]）を使用して、証明書スナップインをサービスアカウント（IISのサービスアカウントを選択）またはコンピューターアカウント（マシン上のすべてのアカウントに追加）として追加する必要があります。

ここで私が話しているものの画像

ここから、CA（信頼されたルートCAと中間CA）の証明書を追加でき、すべてが正常に動作します

自己署名証明書にも同様の問題がありました。サーバーのFQDNと同じ証明書名を使用して解決できました。

理想的には、SSL部分はサーバー側で管理する必要があります。クライアントはSSLの証明書をインストールする必要はありません。また、クライアントコードからSSLをバイパスすることについて言及した投稿のいくつか。しかし、私は完全にそれに同意しません。

証明書を "信頼されたルート証明機関"フォルダーにドラッグしたところ、すべてうまくいきました。

ああ。そして、私は最初に管理者コマンドプロンプトから以下を追加しました。

netsh http add urlacl url=https://+:8732/Servicename user=NT-MYNDIGHET\INTERAKTIV

ユーザーに必要な名前がわかりません（私の名前はノルウェー語user=NT-AUTHORITY/INTERACTIVEです！）：？

次のコマンドを発行すると、既存のurlaclをすべて表示できます。 netsh http show urlacl

これは、経由でWCFサービスに接続しようとしたときに発生しました。https://111.11.111.1:port/MyService.svcたとえば、mysite.comなどの名前に関連付けられた証明書を使用しているときのIP 。

https://mysite.com:port/MyService.svc解決済みに切り替えます。

これは、host.mysite.comなどの名前に関連付けられた証明書を使用して、https：//host/MyService.svcなどのホスト名のみを使用してWCFサービスに接続しようとしたときに発生しました。

https://host.mysite.com/MyService.svcに切り替えると、問題が解決しました。

同様の問題を修正しました。

使用されている証明書の読み取り権限しか持たないアカウントで実行されているアプリケーションプールがあることに気付きました。

.NETアプリケーションは証明書を正しく取得できましたが、その例外はGetRequestStream（）が呼び出されたときにのみスローされました。

証明書のアクセス許可はMMCコンソールで管理できます

.netコアを使用している場合は、開発中にコンパイラディレクティブを使用して証明書の検証をバイパスできます。この方法では、リリースでは証明書のみが検証され、デバッグでは検証されません。

#if (DEBUG)
        client.ClientCredentials.ServiceCertificate.SslCertificateAuthentication =
                new X509ServiceCertificateAuthentication()
                {
                    CertificateValidationMode = X509CertificateValidationMode.None,
                    RevocationMode = System.Security.Cryptography.X509Certificates.X509RevocationMode.NoCheck
                };   #endif

これをクライアントコードに追加します。

ServicePointManager.ServerCertificateValidationCallback = new RemoteCertificateValidationCallback(
    delegate
    {
        return true;
    });