web-dev-qa-db-ja.com

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

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

HTTPSを使用してIIS 7でホストされているWCFサービスがあります。 Internet Explorerでこのサイトを参照すると、魅力のように機能します。これは、haveがローカルルート認証局ストアに証明書を追加したためです。

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

私は現在、このエラーを継続的に取得しています...

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

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

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

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

私が接続できない理由に関するすべての可能性を使い果たしたように見える他の場所はどこにありますか？

wcfiiscertificate
124
JL.

回避策として、クライアント側でServicePointManagerのServerCertificateValidationCallbackにハンドラーを追加できます。

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

ただし、これは良い習慣ではありません証明書は問題ありませんが、これはクライアントのセキュリティを著しく損なう可能性があります。これを改良して、いくつかのカスタムチェック（証明書名、ハッシュなど）を実行できます。少なくとも、テスト証明書を使用すると、開発中に問題を回避できます。

184
Joachim Kerschbaumer

この問題が発生するのは、client.configのエンドポイントが次のようなものだったためです。

 https://myserver/myservice.svc

しかし、証明書は期待していました

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

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

37
Mike Cheel

最初の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;
    }
19
Sebastian Castaldi

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

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

  1. クライアントで証明書の検証をオフにします（不正な移動、中間者攻撃が多数あります）

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

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

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

19
blowdart

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

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

クライアントはSSL/TLSセキュリティチェックをスキップするため、これはテスト目的でのみ使用してください。

13
Gaspa79

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

URLを切り替えるだけでうまくいくかもしれませんが、証明書を信頼できるようにすることで、Internet Explorerで証明書を信頼しないと表示される赤い画面も回避できます。

9
Jeroen-bart Engelen

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

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

  2. アドレスバーにある証明書エラーの説明をクリックし、[証明書の表示]をクリックします。

  3. 以下に対して発行されたチェック：name。

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

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

7
Rahul Rai

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

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

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

以下を使用して修正できます。

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

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

Mmcコンソール（スタート->実行-> mmc）を使用して、Certificatesスナップインをサービスアカウント（IISのサービスアカウントを選択）またはコンピューターアカウント（追加マシン上のすべてのアカウントに対して）

ここで私が話していることの画像 Add snap-in for a service account or the computer account

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

4
dar0x

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

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

4
Umesh Bhavsar

証明書を「Trusted Root Certification Authorities」フォルダーにドラッグするだけで、すべてうまくいきました。

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

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

ユーザーに必要な名前がわからない（私のようにノルウェー語です！）：user=NT-AUTHORITY/INTERACTIVE？

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

3
Haguna

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

https://Host.mysite.com/MyService.svc に切り替えると、これで解決しました。

1
sonia

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

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

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

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

0
Alberto

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

https://mysite.com:port/MyService.svcへの切り替えで解決しました。

0
lko