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

첫 번째는 람다를 사용하고 세 번째는 정규 코드를 사용합니다.

            //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 중 하나에서 SSL 인증서 구매

한 줄 솔루션. 클라이언트 측에서 서버를 호출하기 전에이 위치를 추가하십시오.

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

클라이언트는 SSL / TLS 보안 검사를 건너 뛰므로 테스트 목적으로 만 사용해야합니다.

같은 문제가 발생하여 두 가지 해결 방법으로 문제를 해결할 수있었습니다. 먼저 "컴퓨터 계정"에 MMC 스냅인 "인증서"를 사용하고 자체 서명 된 인증서를 "신뢰할 수있는 루트 인증 기관"폴더로 끌어 놓았습니다. . 즉, 로컬 컴퓨터 (인증서를 생성 한 컴퓨터)는 이제 해당 인증서를 신뢰합니다. 두 번째로 내부 컴퓨터 이름에 대한 인증서가 생성되었지만 다른 이름을 사용하여 웹 서비스에 액세스하고 있음을 알았습니다. 인증서를 검증 할 때 불일치가 발생했습니다. computer.operations.local에 대한 인증서를 생성했지만 https://computer.internaldomain.companydomain.com을 사용하여 웹 서비스에 액세스했습니다 . 인증서를 생성하는 데 사용 된 URL로 URL을 전환하면 더 이상 오류가 발생하지 않습니다.

URL을 바꾸는 것만으로는 효과가 있었지만 인증서를 신뢰할 수있게하면 Internet Explorer에서 인증서를 신뢰하지 않는다는 빨간색 화면이 표시되지 않습니다.

.net core를 사용하는 경우 다음을 시도하십시오.

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

다음 단계를 수행하십시오.

1. IE에서 서비스 링크를 엽니 다.

2. 주소 표시 줄에서 인증서 오류 언급을 클릭하고 인증서보기를 클릭하십시오.

3. 수표 발행 : name.

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 서비스에 연결하려고 할 때 발생했습니다. IP 예https://111.11.111.1:port/MyService.svc 를 들어 mysite.com과 같은 이름으로 묶인 인증서를 사용하는

https://mysite.com:port/MyService.svc해결 된 것으로 전환 .

이는 호스트 이름 (예 : https : //host/MyService.svc) 만 사용하여 WCF 서비스에 연결하려고 할 때 발생했습니다 ( 예 : host.mysite.com).

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