The request was aborted could not create ssl tls secure channel ошибка

• Remove From My Forums

• Question

• User-1353043493 posted

  Below curl request working fine but when i convert this request in c# web request then i got error.

  curl request working fine:

  curl --key private.pem --cert public.crt --data "{"branch_reference":"123"}" 
  --header "Content-type: application/json; profile=https://realtime-listings.webservices.zpg.co.uk/docs/v1.2/schemas/listing/list.json" 
  https://realtime-listings-api.webservices.zpg.co.uk/sandbox/v1/listing/list

  C# web request:

          ServicePointManager.Expect100Continue = true;
          ServicePointManager.DefaultConnectionLimit = 9999;
          ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3| SecurityProtocolType.Tls12; 
  
          string certificateText = File.ReadAllText(@"D:public.crt");
          string privateKeyText = File.ReadAllText(@"D:private.pem");
          ICertificateProvider provider = new CertificateFromFileProvider(certificateText, privateKeyText);
          X509Certificate2 clientCertificate = provider.Certificate;
  
          var httpWebRequest = (HttpWebRequest)WebRequest.Create("https://realtime-listings-api.webservices.zpg.co.uk/sandbox/v1/listing/list");
          httpWebRequest.ContentType = "application/json; profile=https://realtime-listings.webservices.zpg.co.uk/docs/v1.2/schemas/listing/list.json";
          httpWebRequest.Method = "POST";
          httpWebRequest.ClientCertificates.Add(clientCertificate);
  
          ServicePointManager.ServerCertificateValidationCallback +=new RemoteCertificateValidationCallback((sender, certificate, chain, policyErrors) =>{return true;});
  
          using (var streamWriter = new StreamWriter(httpWebRequest.GetRequestStream()))
          {
              string json = "{"branch_reference":"123"}";
              streamWriter.Write(json);
              streamWriter.Flush();
          }
  
          var httpResponse = (HttpWebResponse)httpWebRequest.GetResponse();
          using (var streamReader = new StreamReader(httpResponse.GetResponseStream()))
          {
              var result = streamReader.ReadToEnd();
          }

  Error Detail:

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

  error in below line

  var httpResponse = (HttpWebResponse)httpWebRequest.GetResponse();

Оглавление

• Проблема
• Windows 7 и Windows 2008 R2
• Windows RT 8.1, Windows 8.1, Windows Server 2012 R2
• Другая ОС
• Проблема с корневыми сертификатами в ОС

Мы не можем подключиться к серверу 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;

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

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

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

У меня была эта проблема с попыткой нажать 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");

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

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

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

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

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

“Запрос был прерван: не удалось создать безопасный канал 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”, исключение.

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

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

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

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

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

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

Этот работает для меня в веб-клиенте 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;
}
}

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

• HKLMSOFTWAREPoliciesMicrosoftCryptographyConfigurationSSL0010002
• HKLMSYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL0010002

Здесь полная запись того, как я исследовал и решил экземпляр этого многообразия. 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

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

<httpRuntime targetFramework="4.5.2" />

и не:

<httpRuntime targetFramework="4.6.1" />

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

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

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

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

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

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

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

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

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

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

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

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

System.Net.WebException: запрос был прерван: не удалось создать безопасный канал SSL/TLS.

В нашем случае мы используем поставщика программного обеспечения, поэтому у нас не было доступа для изменения кода.NET. По-видимому,.NET 4 не будет использовать TLS v 1.2, если не будет изменений.

Исправление для нас заключалось в добавлении ключа SchUseStrongCrypto в реестр. Вы можете скопировать/вставить приведенный ниже код в текстовый файл с расширением.reg и выполнить его. Это послужило нашим “патчем” к проблеме.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]
"SchUseStrongCrypto"=dword:00000001

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

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

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

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

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

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

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

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

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

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELKeyExchangeAlgorithmsДиффи-Хеллмана]

“ClientMinKeyBitLength” = DWORD: 00000200

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

Список Windows HotFix:

wmic qfe list

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

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

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

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

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

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

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

Вместо инициализации моего 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...
}

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

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

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