"권한이있는 SSL / TLS 보안 채널에 대한 신뢰 관계를 설정할 수 없음"해결 방법

"권한이있는 SSL / TLS 보안 채널에 대한 신뢰 관계를 설정할 수 없음"해결 방법

---

실제로이 문제가 해결되었다고 생각했지만 이전에는 위장되었습니다.

HTTPS를 사용하여 IIS 7에서 호스팅되는 WCF 서비스가 있습니다. 내가 Internet Explorer에서이 사이트를 탐색 할 때, 내가 때문이다, 매력처럼 작동 한 로컬 루트 인증 기관 저장소에 인증서를 추가했다.

하나의 컴퓨터에서 개발 중이므로 클라이언트와 서버가 동일한 컴퓨터입니다. 인증서는 IIS 7 관리 스냅인에서 직접 자체 서명됩니다.

나는 지금이 오류가 계속 발생합니다 ...

권한이있는 SSL / TLS 보안 채널에 대한 신뢰 관계를 설정할 수 없습니다.

... 클라이언트 콘솔에서 호출 될 때.

사용 findprivatekey하고 사용하여 인증서에 대한 권한과 네트워크 서비스를 수동으로 제공했습니다 cacls.exe.

SOAPUI를 사용하여 서비스에 연결하려고 시도했지만 작동하므로 클라이언트 응용 프로그램에서 문제가되어야합니다.

다른 곳에서 볼 수없는 이유는 내가 연결할 수없는 모든 가능성을 소진 한 것 같습니다.

---

해결 방법으로 클라이언트 측 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과 일치하도록 끝점을 변경하면 문제가 해결됩니다. 이것이 이것이이 문제의 유일한 원인은 아니라는 것을 알고 있습니다.

---

자체 서명 된 키를 사용하기 때문에 문제가 발생합니다. 클라이언트는이 키를 신뢰하지 않으며 키 자체가 유효성 검증을위한 체인 또는 인증서 해지 목록을 제공하지도 않습니다.

몇 가지 옵션이 있습니다.

1. 클라이언트에서 인증서 유효성 검사를 끕니다 (잘못된 이동, 중간 공격에있는 사람이 많음)

2. makecert를 사용하여 루트 CA를 작성하고 그로부터 인증서를 작성하십시오 (이전에는 CRL이 없습니다)

3. Windows 인증서 서버 또는 다른 PKI 솔루션을 사용하여 내부 루트 CA를 만든 다음 해당 루트 인증서를 신뢰합니다 (관리하기가 약간 어려움)

4. 신뢰할 수있는 CA 중 하나에서 SSL 인증서 구매

---

처음 두 개는 람다를 사용하고 세 번째는 정규 코드를 사용합니다. 도움이 되길 바랍니다.

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

---

A one line solution. Add this anywhere before calling the server on the client side:

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

This should only be used for testing purposes because the client will skip SSL/TLS security checks.

---

I encountered the same problem and I was able to resolve it with two solutions: First, I used the MMC snap-in "Certificates" for the "Computer account" and dragged the self-signed certificate into the "Trusted Root Certification Authorities" folder. This means the local computer (the one that generated the certificate) will now trust that certificate. Secondly I noticed that the certificate was generated for some internal computer name, but the web service was being accessed using another name. This caused a mismatch when validating the certificate. We generated the certificate for computer.operations.local, but accessed the web service using https://computer.internaldomain.companydomain.com. When we switched the URL to the one used to generate the certificate we got no more errors.

Maybe just switching URLs would have worked, but by making the certificate trusted you also avoid the red screen in Internet Explorer where it tells you it doesn't trust the certificate.

---

Please do following steps:

1. Open service link in IE.

2. Click on the certificate error mention in address bar and click on View certificates.

3. Check issued to: name.

4. Take the issued name and replace localhost mention in service and client endpoint base address name with A fully qualified domain name (FQDN).

For Example: https://localhost:203/SampleService.svc To https://INL-126166-.groupinfra.com:203/SampleService.svc

---

If you use .net core try this:

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

---

I had similar issue with self-signed certificate. I could resolve it by using the certificate name same as FQDN of the server.

Ideally, SSL part should be managed at the server side. Client is not required to install any certificate for SSL. Also, some of the posts mentioned about bypassing the SSL from client code. But I totally disagree with that.

---

I had the same problem. I also had added CA certificates in the local store, but I did in the WRONG way.

Using mmc Console (Start -> Run -> mmc ) you should add Certificates snap-in as Service account (choosing the service account of IIS) or Computer account (it adds for every account on the machine)

Here an image of what I'm talking about

From here now, you can add certificates of CAs (Trusted Root CAs and Intermediate CAs), and everything will work fine

---

In addition to the answers above, you could encounter this error if your client is running the wrong TLS version, for example if the server is only running TLS 1.2.

You can fix it by using:

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

---

I just dragged the certificate into the "Trusted Root Certification Authorities" folder and voila everything worked nicely.

Oh. And I first added the following from a Administrator Command Prompt:

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

I am not sure of the name you need for the user (mine is norwegian as you can see !): user=NT-AUTHORITY/INTERACTIVE ?

You can see all existing urlacl's by issuing the command: netsh http show urlacl

---

This occurred when trying to connect to the WCF Service via. the IP e.g. https://111.11.111.1:port/MyService.svc while using a certificate tied to a name e.g. mysite.com.

Switching to the https://mysite.com:port/MyService.svc resolved it.

---

This occurred when trying to connect to the WCF Service using only host name e.g. https://host/MyService.svc while using a certificate tied to a name e.g. host.mysite.com.

Switching to the https://host.mysite.com/MyService.svc and this resolved it.

---

Just fixed a similar issue.

I realized I had an application pool that was running under an account that only had reading permission over the certificate that it was used.

The .NET application could correctly retrieve the certificate but that exception was thrown only when GetRequestStream() was called.

Certificates permissions can be managed via MMC console

---

Add this to your client code :

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

참고URL : https://stackoverflow.com/questions/1742938/how-to-solve-could-not-establish-trust-relationship-for-the-ssl-tls-secure-chan