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

Question

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

У меня есть служба WCF, размещенная в IIS 7 с использованием HTTPS. Когда я просматриваю этот сайт в Internet Explorer, он работает как чудо, потому что я добавил , добавил сертификат в локальное корневое хранилище сертификатов.

Я занимаюсь разработкой на 1 машине, поэтому клиент и сервер - это одна машина. Сертификат подписывается непосредственно из оснастки управления IIS 7.

Я постоянно получаю эту ошибку сейчас ...

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

... при вызове из клиентской консоли.

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

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

Куда еще я могу обратиться? Кажется, я исчерпал все возможности, почему я не могу подключиться?

Answer 1

В качестве обходного пути вы можете добавить обработчик к ServicePointManager ServerCertificateValidationCallback на стороне клиента:

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

но имейте в виду, что это не очень хорошая практика , поскольку он полностью игнорирует сертификат сервера и сообщает менеджеру точки обслуживания, что любой сертификат в порядке, который может серьезно подорвать безопасность клиента. Вы можете уточнить это и сделать некоторую пользовательскую проверку (для имени сертификата, хэша и т. Д.). по крайней мере, вы можете обойти проблемы во время разработки при использовании тестовых сертификатов.

Answer 2

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

 https://myserver/myservice.svc 

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

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

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

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

Answer 4

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

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

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

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

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

4. купить сертификат SSL у одного доверенных ЦС (дорого)

Answer 5

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

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

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

Answer 6

Я столкнулся с той же проблемой, и мне удалось решить ее двумя способами: Сначала я использовал оснастку MMC «Сертификаты» для «Учетной записи компьютера» и перетащил самозаверяющий сертификат в папку «Доверенные корневые центры сертификации». Это означает, что локальный компьютер (тот, который сгенерировал сертификат) теперь будет доверять этому сертификату. Во-вторых, я заметил, что сертификат был создан для какого-то внутреннего имени компьютера, но доступ к веб-службе осуществлялся с использованием другого имени. Это вызвало несоответствие при проверке сертификата. Мы сгенерировали сертификат для компьютера.

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

Answer 7

Пожалуйста, выполните следующие действия:

1. Открыть сервисную ссылку в IE.

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

3. Чек выдан: имя.

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

Например: https://localhost:203/SampleService.svc To https://INL -126166-.groupinfra.com : 203 / SampleService.svc

Answer 8

Если вы используете ядро ​​.net, попробуйте это:

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

Answer 9

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

Вы можете исправить это, используя:

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

Answer 10

У меня была такая же проблема. Я также добавил сертификаты CA в локальное хранилище, но сделал это НЕПРАВИЛЬНО.

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

Вот изображение того, о чем я говорю

Теперь вы можете добавлять сертификаты ЦС ( Доверенные корневые ЦС и Промежуточные ЦС ), и все будет работать нормально