Запит перервано: Не вдалося створити захищений канал SSL / TLS

Не вдається підключитися до сервера HTTPS WebRequestчерез це повідомлення про помилку:

The request was aborted: Could not create SSL/TLS secure channel.

Ми знаємо, що на сервері немає дійсного сертифіката HTTPS з використовуваним шляхом, але для обходу цієї проблеми ми використовуємо такий код, який ми взяли з іншої публікації StackOverflow:

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

Проблема полягає в тому, що сервер ніколи не підтверджує сертифікат і не спрацьовує з вищевказаною помилкою. Хтось має уявлення про те, що мені робити?

Я мушу зазначити, що ми з колегою виконували тести кілька тижнів тому, і це добре працювало з чимось подібним до того, що я писав вище. Єдина «основна різниця», яку ми знайшли, - це те, що я використовую Windows 7, а він використовував Windows XP. Це щось змінює?

Нарешті я знайшов відповідь (свого джерела я не зазначив, але це було з пошуку);

Хоча код працює в Windows XP, в Windows 7 ви повинні додати це на початку:

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

І зараз це працює чудово.

ДОБАВЛЕННЯ

Як згадує Робін Френч; якщо у вас виникає ця проблема під час налаштування PayPal, зауважте, що вони не підтримуватимуть SSL3 з 3 грудня 2018 року. Вам потрібно буде використовувати TLS. Ось сторінка Paypal про це.

Рішення цього в .NET 4.5 є

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Якщо у вас немає .NET 4.5, тоді використовуйте

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

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

Працює:

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Помилки:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

Проблема у вас полягає в тому, що користувач aspNet не має доступу до сертифіката. Ви повинні надати доступ за допомогою winhttpcertcfg.exe

Приклад того, як це налаштувати, можна знайти на веб-сайті: http://support.microsoft.com/kb/901183

На кроці 2 додаткові відомості

EDIT: В останніх версіях IIS ця функція вбудована в інструмент диспетчера сертифікатів - до неї можна отримати, натиснувши правою кнопкою миші сертифікат та використовуючи опцію управління приватними ключами. Детальніше тут: /server/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

Помилка є загальною, і є багато причин, через які узгодження SSL / TLS може бути невдалим. Найчастіше це недійсний або закінчений термін дії сертифікату сервера, і ви подбали про це, надавши власний гачок перевірки сертифікату сервера, але це не обов'язково є єдиною причиною. Сервер може вимагати взаємної автентифікації, він може налаштовуватися набором шифрів, які не підтримуються вашим клієнтом, може виникнути занадто великий проміжок часу для успішного рукостискання та багато інших причин.

Найкраще рішення - використовувати набір інструментів усунення несправностей SChannel. SChannel - постачальник SSPI, відповідальний за SSL та TLS, і ваш клієнт використовуватиме його для рукостискання. Погляньте на інструменти та налаштування TLS / SSL .

Також див. Як увімкнути журнал подій Schannel .

У мене виникла ця проблема, намагаючись потрапити на https://ct.mob0.com/Styles/Fun.png , що є зображенням, розповсюдженим CloudFlare на своєму CDN, який підтримує шалені речі, такі як SPDY та дивні термосистеми перенаправлення SSL.

Замість того, щоб вказати Ssl3 як у відповіді Simons, я зміг це виправити, перейшовши на Tls12 так:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");

Через багато довгих годин із цим самим номером я виявив, що обліковий запис ASP.NET, під яким працює служба клієнта, не мав доступу до сертифіката. Я виправив це, зайшовши в пул додатків IIS, під яким працює веб-додаток, перейшовши в «Додаткові налаштування» та змінивши особу для LocalSystemоблікового запису NetworkService.

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

Підхід із постановкою

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Здається, це добре, тому що Tls1.2 - це остання версія захищеного протоколу. Але я вирішив заглянути глибше і відповісти, чи дійсно нам потрібно це жорстко кодувати.

Технічні характеристики: Windows Server 2012R2 x64.

З Інтернету сказано, що .NetFramework 4.6+ повинен використовувати Tls1.2 за замовчуванням. Але коли я оновив проект до 4,6, нічого не сталося. Я знайшов деяку інформацію, яка говорить про те, що мені потрібно вручну зробити деякі зміни, щоб включити Tls1.2 за замовчуванням

https://support.microsoft.com/en-in/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-wi

Але запропоноване оновлення Windows не працює для версії R2

Але мені допомогло додавання двох значень до реєстру. Ви можете використовувати наступний скрипт PS, щоб вони були додані автоматично

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Це щось таке, що я шукав. Але все ж я не можу відповісти на питання, чому NetFramework 4.6+ не встановлює це значення ... Протокол значення автоматично?

Щось оригінальна відповідь не мала. Я додав ще трохи коду, щоб зробити його кулезахисним.

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

Ще одна можливість - неналежний імпорт сертифікату на коробці. Переконайтесь, що встановлено прапорець. Спочатку я цього не робив, тому код був або вичерпаний, або викинув той самий виняток, як приватний ключ не міг бути знайдений.

Виняток "Запит перервано: Неможливо створити захищений канал SSL / TLS" може статися, якщо сервер повертає HTTP 401 Несанкціоновану відповідь на запит HTTP.

Ви можете визначити, чи це відбувається, включивши журнал System.Net для вашого клієнтського додатка, як описано в цій відповіді .

Після того, як ця конфігурація журналу встановлена, запустіть програму та відтворіть помилку, а потім подивіться у висновку журналу такий рядок:

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

У моїй ситуації мені не вдалося встановити певний файл cookie, якого очікував сервер, що призвело до того, що сервер відповів на запит із помилкою 401, що, в свою чергу, призвело до виключення "Не вдалося створити безпечний канал SSL / TLS".

Іншою можливою причиною The request was aborted: Could not create SSL/TLS secure channelпомилки є невідповідність між налаштованими вами ПК клієнтськими програмами cipher_suites та значеннями, які сервер налаштований як такі, що бажають і можуть прийняти . У цьому випадку, коли ваш клієнт надсилає список значень cipher_suites, який він може прийняти у своєму первісному повідомленні про рукостискання / переговори SSL "Клієнт привіт", сервер бачить, що жодне із наданих значень не є прийнятним, і може повернути "Сповіщення" "відповідь замість того, щоб перейти до кроку" Привіт сервера "рукостискання SSL.

Щоб дослідити цю можливість, ви можете завантажити аналізатор повідомлень Microsoft і використовувати його для простеження сліду за узгодженням SSL, що виникає при спробі і не вдалося встановити HTTPS-з'єднання з сервером (у вашому додатку C #).

Якщо ви зможете встановити успішне з'єднання HTTPS з іншого середовища (наприклад, згаданий вами апарат Windows XP - або, можливо, натиснувши URL-адресу HTTPS у браузері, не входить у Microsoft, який не використовує налаштування шифру ОС, наприклад, Chrome або Firefox), запустіть ще один слід аналізатора повідомлень у цьому середовищі, щоб зафіксувати те, що відбувається, коли SSL узгодження буде успішним.

Сподіваємось, ви побачите деяку різницю між двома повідомленнями Привіт про клієнта, які дозволять вам точно визначити, що про невдалі SSL-переговори спричиняє його збій. Тоді ви маєте змогу внести зміни в конфігурацію Windows, які дозволять їй досягти успіху. IISCrypto - чудовий інструмент для цього (навіть для клієнтських ПК, незважаючи на назву "IIS").

Наступні два ключі реєстру Windows керують значеннями cipher_suites, якими буде користуватися ваш ПК:

• HKLM \ ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ \ Політика \ Microsoft \ Криптографія \ Конфігурація \ SSL \ 00010002
• HKLM \ SYSTEM \ CurrentControlSet \ Control \ Криптографія \ Конфігурація \ Local \ SSL \ 00010002

Ось повний опис того, як я досліджував і вирішував екземпляр цієї різноманітності Could not create SSL/TLS secure channelпроблеми: http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in-windows.html

Корінь цього винятку в моєму випадку полягала в тому, що в якийсь момент коду було викликано наступне:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Це справді погано. Це не тільки вказівка ​​.NET використовувати незахищений протокол, але це впливає на кожен новий запит WebClient (і подібні), зроблені згодом у вашому додатку. (Зверніть увагу, що вхідні веб-запити не впливають на ваш додаток ASP.NET, але нові запити WebClient, такі як спілкування із зовнішньою веб-службою, є).

У моєму випадку це насправді не було потрібно, тому я міг просто видалити заяву, і всі інші мої веб-запити знову почали працювати нормально. На основі свого читання в іншому місці я дізнався кілька речей:

• Це глобальне налаштування у вашому додатку домену, і якщо у вас є паралельна діяльність, ви не можете надійно встановити його на одне значення, виконайте свою дію, а потім поверніть його назад. Інша дія може відбутися під час цього невеликого вікна та зазнати впливу.
• Правильна настройка - залишити його за замовчуванням. Це дозволяє .NET продовжувати використовувати те, що є найбезпечнішим значенням за замовчуванням у міру проходження часу та оновлення фреймворків. Якщо встановити його на TLS12 (що є найбільш безпечним на сьогоднішній день), то вже через 5 років це може почати створювати таємничі проблеми.
• Якщо вам дійсно потрібно встановити значення, вам варто розглянути це в окремому спеціалізованому додатку чи додатку та знайти спосіб поговорити між ним та основним пулом. Оскільки це єдина глобальна цінність, спроба керувати нею у зайнятому пулі додатків призведе лише до проблем. Ця відповідь: https://stackoverflow.com/a/26754917/7656 забезпечує можливе рішення за допомогою спеціального проксі. (Зауважте, я особисто не реалізував це.)

У мене була ця проблема, оскільки мій web.config мав:

<httpRuntime targetFramework="4.5.2" />

і ні:

<httpRuntime targetFramework="4.6.1" />

Як ви можете сказати, існує багато причин. Думав, я додам причину, з якою зіткнувся ...

Якщо ви встановите значення WebRequest.Timeoutдо 0, це виняток, який викидається. Нижче наведено код, який у мене був ... (За винятком жорсткого коду 0для значення тайм-ауту, у мене був параметр, який був ненавмисно встановлений 0).

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...

Для більшості людей, напевно, відповіді , ймовірно, вистачить. Однак, за деяких обставин, ви можете продовжувати отримувати помилку "Не вдалося створити безпечний канал SSL / TLS" навіть після вимушення TLS 1.2. Якщо так, то, можливо, ви захочете проконсультуватися цією корисною статтеюдля додаткових етапів усунення несправностей. Підводячи підсумок: незалежно від випуску версії TLS / SSL, клієнт та сервер повинні узгодити "набір шифрів". Під час фази «рукостискання» з'єднання SSL клієнт перелічить свої підтримувані шифрові набори для того, щоб сервер перевіряв його власний список. Але на деяких машинах Windows деякі загальні шифр-пакети, можливо, були відключені (здавалося б, через цілеспрямовані спроби обмежити поверхню атаки), зменшуючи можливість клієнта та сервера домовитися про шифр. Якщо вони не можуть погодитися, то у переглядачі подій може з’явитися "фатальний код попередження 40" та "Не вдалося створити захищений канал SSL / TLS" у вашій програмі .NET.

Вищезгадана стаття пояснює, як перелічити всі потенційно підтримувані шифрові набори машини та включити додаткові набори шифрів через Реєстр Windows. Щоб перевірити, які пакети шифрів увімкнено для клієнта, спробуйте відвідати цю діагностичну сторінку в MSIE. (Використання трасування System.Net може дати більш остаточні результати.) Щоб перевірити, які пакети шифрів підтримуються сервером, спробуйте цей онлайн-інструмент (припускаючи, що сервер доступний в Інтернеті). Само собою зрозуміло, що редагування реєстру потрібно проводити обережно , особливо там, де задіяні мережі. (Чи є ваша машина віддаленим комп'ютером? Якщо ви перервали мережу, чи буде взагалі доступний VM?)

У випадку моєї компанії ми ввімкнули кілька додаткових пакетів "ECDHE_ECDSA" за допомогою редагування реєстру, щоб виправити негайну проблему та захистити від майбутніх проблем. Але якщо ви не можете (або не бажаєте) редагувати Реєстр, то на думку приходять численні обхідні шляхи (не обов'язково досить). Наприклад: ваша .NET програма може делегувати свій SSL-трафік окремій програмі Python (яка може сама працювати, з тієї ж причини, що запити Chrome можуть бути успішними, коли запити MSIE не спрацьовують на ураженій машині).

Однією з найбільших причин цієї проблеми є активна версія .NET Framework. Версія виконання .NET Framework виконує вплив на те, які протоколи безпеки включені за умовчанням.

Здається, не існує жодної авторитетної документації про те, як вона спеціально працює в різних версіях, але, схоже, типові параметри визначаються більш-менш так:

• .NET Framework 4.5 і новіші версії - SSL 3.0, TLS 1.0
• .NET Framework 4.6.x - TLS 1.0, 1.1, 1.2, 1.3
• .NET Framework 4.7+ - за замовчуванням системи (OS)

(Для старих версій ваш пробіг може дещо відрізнятися, залежно від того, який час роботи .NET встановлений у системі. Наприклад, може виникнути ситуація, коли ви використовуєте дуже старий фреймворк, а TLS 1.0 не підтримується або використовуєте 4.6. x і TLS 1.3 не підтримується)

Документація Майкрософт настійно радить використовувати версії 4.7 і новіші настройки системи:

Ми рекомендуємо вам:

• Націліть на .NET Framework 4.7 або новіші версії ваших програм. Націліть .NET Framework 4.7.1 або новіші версії ваших програм WCF.
• Не вказуйте версію TLS. Налаштуйте свій код, щоб ОС вирішила версію TLS.
• Проведіть ретельний аудит коду, щоб переконатися, що ви не вказали версію TLS або SSL.

Для сайтів ASP.NET перевірте версію .NET Framework у своєму <httpRuntime>елементі, оскільки це визначає, який час виконання фактично використовується вашим сайтом:

<httpRuntime targetFramework="4.5" />

Краще:

<httpRuntime targetFramework="4.7" />

Цей працює для мене в MVC webclient

    public string DownloadSite(string RefinedLink)
    {
        try
        {
            Uri address = new Uri(RefinedLink);

            ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

            System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

            using (WebClient webClient = new WebClient())
            {
                var stream = webClient.OpenRead(address);
                using (StreamReader sr = new StreamReader(stream))
                {
                    var page = sr.ReadToEnd();

                    return page;
                }
            }

        }
        catch (Exception e)
        {
            log.Error("DownloadSite - error Lin = " + RefinedLink, e);
            return null;
        }
    }

У випадку, якщо клієнт є машиною Windows, можливою причиною може бути те, що протокол tls або ssl, необхідний службі, не активований.

Це можна встановити у:

Панель управління -> Мережа та Інтернет -> Параметри Інтернету -> Додатково

Прокрутіть налаштування вниз до "Безпека" та виберіть один із них

• Використовуйте SSL 2.0
• Використовуйте SSL 3.0
• Використовуйте TLS 1.0
• Використовуйте TLS 1.1
• Використовуйте TLS 1.2

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

1. ммс
2. сертифікати
3. Розгорніть на особисте
4. виберіть cert
5. клацніть правою кнопкою миші
6. Всі завдання
7. Керуйте приватними ключами
8. Додайте

Якщо ви запускаєте свій код від Visual Studio, спробуйте запустити Visual Studio як адміністратор. Виправлена ​​проблема для мене.

Я цілий день боровся з цією проблемою.

Коли я створив новий проект за допомогою .NET 4.5, я нарешті змусив його працювати.

Але якщо я знизив рівень до 4.0, у мене знову з’явилася та сама проблема, і це було незворотним для цього проекту (навіть коли я знову намагався оновити до 4,5).

Не дивно жодне інше повідомлення про помилку, окрім "Запит перервано: Не вдалося створити захищений канал SSL / TLS." виникла ця помилка

System.Net.WebException: Запит перервано: Не вдалося створити захищений канал SSL / TLS.

У нашому випадку ми використовуємо постачальника програмного забезпечення, щоб у нас не було доступу для зміни коду .NET. Мабуть. NET 4 не використовуватиме TLS v 1.2, якщо не буде змін.

Виправленням для нас було додавання ключа SchUseStrongCrypto до реєстру. Ви можете скопіювати / вставити наведений нижче код у текстовий файл із розширенням .reg та виконати його. Це послужило нашою «латкою» до проблеми.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

Спробуйте це:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Це виправлено для мене, додайте мережеві послуги до дозволів. Клацніть правою кнопкою миші сертифікат> Усі завдання> Керування приватними ключами ...> Додати ...> Додати "Служба мережі".

Проблема для мене полягала в тому, що я намагався розгорнути на IIS як веб-сервіс, я встановив сертифікат на сервер, але користувач, який працює з IIS, не мав правильних дозволів на сертифікат.

Як надати ASP.NET доступ до приватного ключа в сертифікаті в магазині сертифікатів?

У мене виникло те саме питання, і я виявив, що ця відповідь справно працює на мене. Ключ - 3072. Це посилання містить детальну інформацію про виправлення "3072".

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

У моєму випадку виправлення потребували два канали:

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

Це питання може мати багато відповідей, оскільки йдеться про загальне повідомлення про помилку. Ми зіткнулися з цим питанням на деяких наших серверах, але не на наших розробних машинах. Витягнувши більшу частину волосся, ми виявили, що це помилка Microsoft.

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

По суті, MS передбачає, що ви хочете слабкіше шифрування, але ОС виправлена, щоб дозволити лише TLS 1.2, тому ви отримуєте жахливий "Запит перервано: Не вдалося створити захищений канал SSL / TLS."

Є три виправлення.

1) Виправити ОС за допомогою належного оновлення: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Додайте налаштування до файлу app.config / web.config.

3) Додайте параметр реєстру, який уже згадувався в іншій відповіді.

Все це згадується у статті, яку я розмістив у базі знань.

Інша можливість полягає в тому, що виконаний код не має необхідних передумов.

У моєму випадку я отримав цю помилку під час використання відладчика Visual Studio для тестування виклику веб-сервісу. Visual Studio не працював як адміністратор, що спричинило це виключення.

Це сталося зі мною лише на одному сайті, і виявилося, що у нього був доступний лише шифр RC4. Попередньо намагаючись загартувати сервер, я відключив шифр RC4, як тільки я повторно включив цю проблему, було вирішено.