Як вирішити "Не вдалося встановити довірчі відносини для безпечного каналу SSL / TLS з владою"

Дійсно думав, що я вирішив цю проблему, але це було замасковано лише раніше.

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

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

Я постійно отримую цю помилку зараз ...

Не вдалося встановити довірчі відносини для захищеного каналу SSL / TLS з повноваженнями.

... при виклику з консолі клієнта.

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

Я спробував підключитися до сервісу за допомогою SOAPUI, і це працює, тому це повинно бути проблемою в моїй клієнтській програмі, що є кодом на основі того, що раніше працювало з http.

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

В якості тимчасового рішення можна додати обробник до 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 для створення кореневого ЦС та створення сертифікатів із цього (нормально рухатись, але досі немає CRL)

3. створіть внутрішній кореневий центр сервісу за допомогою сервера сертифікатів Windows або іншого рішення PKI, після чого довіряйте цьому кореневому серту (трохи болю для управління)

4. придбати сертифікат SSL у одного із надійних ЦА (дорого)

Рішення на одну лінію Додайте це будь-де, перш ніж викликати сервер на стороні клієнта:

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

Це слід використовувати лише для тестування, оскільки клієнт буде пропускати перевірки безпеки SSL / TLS.

Я зіткнувся з тією ж проблемою, і мені вдалося вирішити її двома рішеннями: по-перше, я застосував оснащення MMC "Сертифікати" для "Облікового запису комп'ютера" і перетягнув самопідписаний сертифікат у папку "Довірені кореневі органи сертифікації" . Це означає, що локальний комп'ютер (той, який генерував сертифікат) тепер буде довіряти цьому сертифікату. По-друге, я помітив, що сертифікат генерується для якогось внутрішнього імені комп'ютера, але доступ до веб-сервісу здійснюється за допомогою іншого імені. Це спричинило невідповідність під час перевірки сертифіката. Ми створили сертифікат для computer.operations.local, але отримали доступ до веб-служби за допомогою https://computer.internaldomain.companydomain.com . Коли ми переключили URL на той, який використовується для створення сертифіката, у нас більше помилок не було.

Можливо, просто переключення URL-адрес спрацювало б, але довіряючи сертифікату, ви також уникаєте червоного екрана в Internet Explorer, де він говорить, що він не довіряє сертифікату.

Якщо ви використовуєте ядро ​​.net, спробуйте це:

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

Виконайте такі дії:

1. Відкрийте посилання служби в IE.

2. Клацніть на згадці про помилку сертифіката в адресному рядку та натисніть Переглянути сертифікати.

3. Чек видано на: ім'я.

4. Візьміть видане ім’я та замініть згадку localhost в службі та імені базової кінцевої точки клієнта на повністю кваліфіковане доменне ім’я (FQDN).

Наприклад: https: // localhost : 203 / SampleService.svc До https: // INL-126166.-.groupinfra.com : 203 / SampleService.svc

Окрім наведених вище відповідей, ви можете зіткнутися з цією помилкою, якщо ваш клієнт працює неправильною версією TLS, наприклад, якщо на сервері працює лише TLS 1.2.

Ви можете виправити це за допомогою:

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

У мене була така ж проблема. Я також додав сертифікати CA у місцевому магазині, але я це зробив WRONG.

За допомогою консолі 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

Це сталося при спробі підключення до служби WCF через. IP, наприклад, https://111.11.111.1:port/MyService.svcпід час використання сертифіката, прив'язаного до імені, наприклад, mysite.com.

Перехід до https://mysite.com:port/MyService.svcвирішеного.

Це сталося під час спроби підключитися до служби WCF, використовуючи лише ім'я хоста, наприклад https: //host/MyService.svc під час використання сертифіката, прив’язаного до імені, наприклад, 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;
    });