Как решить "не удалось установить доверительные отношения для безопасного канала SSL / TLS с полномочиями"

когда у меня такая проблема, это потому что клиент.config имел свои конечные точки, такие как:

 https://myserver/myservice.svc 

но сертификат ожидал

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

изменение конечных точек в соответствии с FQDN сервера решает мою проблему. Я знаю, что это не единственная причина этой проблемы.

ваша проблема возникает потому, что вы используете самоподписанным ключом. Клиент не доверяет этому ключу, а сам ключ не предоставляет цепочку для проверки или список отзыва сертификата.

У вас есть несколько вариантов - вы можете

1. выключить проверку сертификата клиент (плохой ход, человек в средних атак предостаточно)

2. используйте makecert для создания корневого ЦС и создайте сертификаты из этого (ok двигаться, но все равно нет CRL)

3. создайте внутренний корневой CA, используя Сервер сертификатов Windows или другое Решения PKI, то поверьте, что корень cert (немного больно управлять)

4. приобретите сертификат SSL от одного доверенного CAs (дорогой)

первые два используют лямбда, третий использует обычный код... надеюсь, вы найдете это полезным

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

одно решение. Добавьте это в любом месте перед вызовом сервера на стороне клиента:

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

Это должно использоваться только для целей тестирования, потому что клиент пропустит проверки безопасности SSL/TLS.

Я столкнулся с той же проблемой и смог решить ее с двумя решениями: Во-первых, я использовал оснастку MMC "сертификаты" для "учетной записи компьютера" и перетащил самозаверяющий сертификат в папку "Доверенные корневые центры сертификации". Это означает, что локальный компьютер (тот, который создал сертификат) теперь будет доверять этому сертификату. Во-вторых, я заметил, что сертификат был создан для некоторого внутреннего имени компьютера, но доступ к веб-службе осуществлялся с помощью другое имя. Это вызвало несоответствие при проверке сертификата. Мы создали сертификат для компьютера.оперативный.локальный, но доступ к веб-службе с помощью https://computer.internaldomain.companydomain.com. Когда мы переключили URL-адрес на тот, который используется для создания сертификата, мы больше не получили ошибок.

возможно, просто переключение URL-адресов сработало бы, но, сделав сертификат надежным, вы также избегаете красного экрана в Internet Explorer, где он говорит вам об этом не доверяет сертификату.

пожалуйста, сделайте следующие шаги:

1. открыть ссылку на службу в IE.

2. нажмите на упоминание ошибки сертификата в адресной строке и нажмите на Просмотр сертификатов.

3. проверка выдана на: имя.

4. возьмите выданное имя и замените упоминание localhost в имени базового адреса службы и конечной точки клиента полным доменным именем (FQDN).

Например: https://localhost в:203/SampleService.ВПВ Для https://INL-126166-.groupinfra.com: 203 / SampleService.svc

У меня была та же проблема. Я также добавил сертификаты CA в местный магазин, но я сделал это неправильно.

использование консоли mmc (Пуск - > Выполнить ->mmc ) вы должны добавить сертификаты оснастка как учетная запись службы (выбор учетной записи службы IIS) или учетной записи компьютера (она добавляет для каждой учетной записи на компьютере)

У меня была аналогичная проблема с самоподписанным сертификатом. Я мог бы решить его, используя имя сертификата, такое же, как 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

в дополнение к ответам выше, вы можете столкнуться с этой ошибкой, если ваш клиент работает с неправильной версией TLS, например, если на сервере работает только TLS 1.2.

вы можете исправить это с помощью:

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

Это произошло при попытке подключиться к службе WCF, используя только имя хоста, например https://host/MyService.svc при использовании сертификата, привязанного к имени, например host.mysite.com.

переключение на https://host.mysite.com/MyService.svc и решили его.

Это произошло при попытке подключиться к службе WCF через. ИС, например,https://111.11.111.1:port/MyService.svc при использовании сертификата, привязанного к имени, например mysite.com - ...

переключение на https://mysite.com:port/MyService.svc разрешить его.

просто исправлена аналогичная проблема.

Я понял, что у меня есть пул приложений, который работает под учетной записью, у которой есть только разрешение на чтение сертификата, который он использовал.

приложение .NET может правильно получить сертификат, но это исключение было вызвано только при вызове GetRequestStream ().

разрешения сертификатов можно управлять через консоль MMC

добавьте это в ваш код клиента :

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