Запрос был прерван: не удалось создать безопасный канал 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. Это что-то меняет?

Ответ 1

Я, наконец, нашел ответ (я не заметил свой источник, но это был поиск);

Хотя код работает в 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 об этом.

Ответ 2

Решение этого в.NET 4.5 является

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Если у вас нет.NET 4.5, используйте

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Ответ 3

Убедитесь, что настройки 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;

Ответ 4

Проблема, с которой вы сталкиваетесь, заключается в том, что пользователь aspNet не имеет доступа к сертификату. Вы должны предоставить доступ, используя winhttpcertcfg.exe

Пример настройки этого параметра: http://support.microsoft.com/kb/901183

На шаге 2 в дополнительной информации

EDIT: в более поздних версиях IIS эта функция встроена в инструмент диспетчера сертификатов - и к ней можно получить доступ, щелкнув правой кнопкой мыши по сертификату и используя опцию для управления секретными ключами. Подробнее здесь: https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

Ответ 5

Ошибка является общей и существует много причин, по которым переговоры SSL/TLS могут завершиться неудачей. Наиболее распространенным является недействительный или устаревший сертификат сервера, и вы позаботились об этом, предоставив свой собственный сертификат проверки подлинности сертификата сервера, но это не обязательно единственная причина. Сервер может требовать взаимной аутентификации, он может быть настроен с наборами шифров, не поддерживаемых вашим клиентом, у него может быть слишком большой дрейф времени, чтобы рукопожатие преуспело и еще много причин.

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

Также см. Как включить ведение журнала событий Schannel.

Ответ 6

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

Вместо того, чтобы указывать Ssl3, как в ответе Саймонса, я смог исправить его, перейдя к Tls12 следующим образом:

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

Ответ 7

После долгих часов с этой же проблемой я обнаружил, что учетная запись ASP.NET, на которой работает клиентская служба, не имела доступа к сертификату. Я исправил его, перейдя в пул приложений IIS, с которым работает веб-приложение, перейдя в "Дополнительные настройки" и изменив идентификатор на LocalSystem с NetworkService.

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

Ответ 8

Что-то, чего не было в первоначальном ответе. Я добавил еще один код, чтобы сделать его пуленепробиваемым.

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

Ответ 9

Другая возможность - это неправильный импорт сертификата в поле. Обязательно установите флажок в окружении. Первоначально я этого не делал, поэтому код либо выходил из строя, либо выдавал такое же исключение, что и закрытый ключ.

certificate importation dialog

Ответ 10

"Запрос был прерван: не удалось создать безопасный канал SSL/TLS". Исключение может возникнуть, если сервер возвращает ответ HTTP <4 > Неавторизованный запрос HTTP.

Вы можете определить, происходит ли это, включив ведение журнала System.Net на уровне трассировки для вашего клиентского приложения, как описано в этом ответе.

Как только эта конфигурация регистрации будет на месте, запустите приложение и воспроизведите ошибку, а затем посмотрите в выводе журнала для такой строки:

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

В моей ситуации я не смог установить конкретный файл cookie, ожидаемый сервером, что привело к тому, что сервер ответил на запрос с ошибкой 401, что в свою очередь привело к созданию "Не удалось создать безопасный канал SSL/TLS", исключение.

Ответ 11

Корень этого исключения в моем случае состоял в том, что в какой-то момент кода вызывалось следующее:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

Это действительно плохо. Он не только инструктирует .NET использовать небезопасный протокол, но это влияет на каждый новый запрос WebClient (и аналогичный), сделанный впоследствии в вашем приложении. (Обратите внимание, что входящие веб-запросы не затрагиваются в вашем приложении ASP.NET, но новые запросы WebClient, например, для общения с внешней веб-службой).

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

  • Это глобальная настройка в вашем приложении, и если у вас есть одновременная деятельность, вы не можете надежно установить ее на одно значение, выполнить свое действие и затем установить его обратно. Другое действие может иметь место во время этого маленького окна и быть затронутым.
  • Правильная настройка - оставить ее по умолчанию. Это позволяет .NET продолжать использовать все, что является самым безопасным значением по умолчанию, с течением времени и обновлять фреймворки. Установка его в TLS12 (который является самым безопасным на момент написания этой статьи) будет работать сейчас, но через 5 лет может возникнуть таинственные проблемы.
  • Если вам действительно нужно установить значение, вы должны подумать об этом в отдельном специализированном приложении или приложении домена и найти способ поговорить между ним и вашим основным пулом. Поскольку это единственное глобальное значение, попытка управлять им в пределах загруженного пула приложений приведет только к неприятностям. Этот ответ: fooobar.com/questions/45920/... предоставляет возможное решение с помощью специального прокси. (Примечание. Я лично не реализовал его.)

Ответ 12

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

Если вы установите значение 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 ...

Ответ 13

Этот работает для меня в веб-клиенте MVC

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

Ответ 14

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

Чтобы изучить эту возможность, вы можете загрузить Microsoft Message Analyzer и использовать его для запуска трассировки в согласовании SSL, возникающего при попытке установить HTTPS-соединение с сервером (в вашем приложении С#).

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

Надеемся, вы увидите некоторую разницу между двумя сообщениями Hello Hello, которые позволят вам точно определить, что из-за неудачного согласования SSL приводит к сбою. Затем вы сможете внести изменения в конфигурацию Windows, что позволит ей добиться успеха. IISCrypto - отличный инструмент для этого (даже для клиентских компьютеров, несмотря на имя "IIS").

Следующие два ключа реестра Windows управляют значениями cipher_suites, которые ваш компьютер будет использовать:

  • HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
  • HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

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

Ответ 15

У меня была эта проблема, потому что у моего web.config было:

<httpRuntime targetFramework="4.5.2" />

и не:

<httpRuntime targetFramework="4.6.1" />

Ответ 16

Я боролся с этой проблемой весь день.

Когда я создал новый проект с .NET 4.5, я, наконец, получил его для работы.

Но если я понизил до 4.0, я снова получил ту же проблему, и это было необратимо для этого проекта (даже когда я снова попытался обновить до 4.5).

Странное другое сообщение об ошибке, но "Запрос был прерван: не удалось создать безопасный канал SSL/TLS". придумал эту ошибку

Ответ 17

В случае, если клиент является машиной Windows, возможной причиной может быть то, что протокол tls или ssl, требуемый службой, не активирован.

Это можно установить в:

Панель управления → Сеть и Интернет → Свойства обозревателя → Дополнительно

Прокрутите настройки до "Безопасность" и выберите между

  • Использовать SSL 2.0
  • Использовать SSL 3.0
  • Использовать TLS 1.0
  • Использовать TLS 1.1
  • Использовать TLS 1.2

enter image description here

Ответ 18

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

  • ММС
  • сертификаты
  • Развернуть до личного
  • выберите cert
  • щелкните правой кнопкой мыши
  • Все задачи
  • Управление секретными ключами
  • Добавить

Ответ 19

Если вы запускаете свой код из Visual Studio, попробуйте запустить Visual Studio в качестве администратора. Исправлена ошибка.

Ответ 20

У меня была такая же проблема, и я нашел, что этот ответ работал правильно для меня. Ключ - 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

Ответ 21

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

Ответ 22

Попробуй это:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Ответ 23

Ответа с наибольшим количеством голосов, вероятно, будет достаточно для большинства людей. Однако в некоторых случаях вы можете продолжить получать сообщение об ошибке "Не удалось создать безопасный канал SSL/TLS" даже после принудительного использования TLS 1.2. Если это так, вы можете обратиться к этой полезной статье за дополнительными шагами по устранению неполадок. Подводя итог: независимо от проблемы версии TLS/SSL, клиент и сервер должны договориться о "наборе шифров". На этапе "рукопожатия" SSL-соединения клиент перечислит свои поддерживаемые комплекты шифров, которые сервер будет проверять по собственному списку. Но на некоторых компьютерах с Windows некоторые общие наборы шифров могут быть отключены (по-видимому, из-за благих намерений попыток ограничить поверхность атаки), уменьшая вероятность клиента & согласие сервера на набор шифров. Если они не могут согласиться, вы можете увидеть "код фатального оповещения 40" в средстве просмотра событий и "Не удалось создать безопасный канал SSL/TLS" в вашей .NET-программе.

В вышеупомянутой статье объясняется, как составить список всех потенциально поддерживаемых наборов шифров на компьютере и включить дополнительные наборы шифров через реестр Windows. Чтобы проверить, какие наборы шифров включены на клиенте, попробуйте посетить эту страницу диагностики в MSIE. (Использование трассировки System.Net может дать более точные результаты.) Чтобы проверить, какие наборы шифров поддерживаются сервером, попробуйте этот онлайн-инструмент (при условии, что сервер доступен через Интернет). Само собой разумеется, что изменения в реестре должны выполняться с осторожностью, особенно когда речь идет о работе в сети. (Является ли ваша машина виртуальной машиной с удаленным размещением? Если бы вы прервали работу сети, была бы она вообще доступна?)

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

Ответ 24

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

Как предоставить доступ ASP.NET к закрытому ключу в сертификате в хранилище сертификатов?

Ответ 25

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

Идентификатор события 36888 (Schannel) поднят:

The following fatal alert was generated: 40. The internal error state is 808.

Наконец, это связано с исправлением Windows. В моем случае: KB3172605 и KB3177186

Предлагаемое решение в форуме vmware - это добавить запись в Windows. После добавления следующего реестра все работает нормально.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Диффи-Хеллмана]

"ClientMinKeyBitLength" = DWORD: 00000200

По-видимому, это связано с отсутствующим значением в рукопожатии https на стороне клиента.

Список Windows HotFix:

wmic qfe list

Решение Тема:

https://communities.vmware.com/message/2604912#2604912

Надеюсь, что это поможет.

Ответ 26

На этот вопрос может быть много ответов, поскольку он касается общего сообщения об ошибке. Мы столкнулись с этой проблемой на некоторых наших серверах, но не на наших машинах для разработки. После удаления большинства наших волос мы обнаружили, что это ошибка 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) Добавьте параметр реестра, который уже упоминался в другом ответе.

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

Ответ 27

Ни один из ответов не сработал для меня.

Вот что сработало:

Вместо инициализации моего X509Certifiacte2 вот так:

   var certificate = new X509Certificate2(bytes, pass);

Я сделал это так:

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

Обратите внимание на X509KeyStorageFlags.Exportable !!

Я не изменил остальную часть кода (сам WebRequest):

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // etc...
}

На самом деле я даже не уверен, что первые две строки необходимы...

Ответ 28

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

Ответ 29

Пока это относительно "живая" ссылка, я думал, что добавлю новый вариант. Эта возможность заключается в том, что служба больше не поддерживает SSL 3.0 из-за проблемы с атакой пуделя. Ознакомьтесь с инструкцией Google по этому вопросу. Я столкнулся с этой проблемой сразу с несколькими веб-службами и понял, что что-то должно было произойти. Я переключился на TLS 1.2, и все снова работает.

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Ответ 30

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