Подтвердить что ты не робот

Произошла ошибка в поддержке безопасного канала - классический HTTP-запрос ASP ASP

У меня есть классический веб-сайт ASP, работающий в окне Windows Server 2012. Одна страница делает HTTP-запрос другому приложению через https, используя такой код:

Sub ShopXML4http(url, inStr, outStr, method, xmlerror)
  Dim objhttp
  Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")
  objHttp.open method, url, false
  If Method="POST" Then
    objHttp.Send instr
  Else
    objHttp.Send
  End if   
  outstr=objHttp.responseText
  Set objhttp=nothing
End Sub

Этот код отлично работает почти все время (тысячи запросов в день), но спорадически он выйдет из строя с таким сообщением:

Номер: -2147012739

Описание: Произошла ошибка в поддержке защищенного канала

Источник: msxml6.dll

Приложение недавно было перенесено с старого сервера Windows 2003 на сервер 2012 года, и эта проблема никогда не казалась проблемой на старом сервере. Кроме того, пока эта ошибка происходит на веб-сайте, я могу запустить тот же самый код в VBScript, и он отлично работает. Сброс пула приложений, похоже, заставляет сайт снова выполнять защищенные HTTP-запросы (хотя он часто исправляет себя, прежде чем я могу добраться до сервера).

4b9b3361

ОТВЕТЫ

Ответ 1

У меня была такая же проблема после перехода с 2003 по 2008 R2 и нашел решение. Изменение:

Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")

в

Set objhttp = Server.CreateObject ("MSXML2.XMLHTTP.6.0")

и ваша проблема исчезнет.

Я попытался найти плюсы и минусы обо всех объектах, но еще не нашел причины не использовать XMLHTTP.

Ответ 2

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

Решение представляет собой комбинацию нескольких решений stackoverflow для похожих задач, но это, пожалуй, самое лучшее, что можно добавить.

Проблема

Попытка тестирования IP-адреса PayPal в Windows Server 2008 с использованием классического ASP с помощью Sandbox PayPal возвращает ошибку "Ошибка в поддержке защищенного канала".

Почему это проблема

PayPal требует, чтобы все коммуникации с их системами были максимально безопасными. Вам потребуется соединение, которое является TLS 1.2. Windows Server 2008 по умолчанию не является TLS 1.2.

PayPal бросила некоторую путаницу в микс, сказав, что вам нужен сертификат Verisign G5, который вы делаете для корневого сервера, а не для домена, на котором запущен ваш код. Я также не устанавливал никаких сертификатов PayPal, поскольку я не использую API. Я также не считаю, что вам нужны ваши коммиты с сайта HTTPS, хотя мой домен защищен с помощью стандартного сертификата GoDaddy EV, хотя после тестирования я работал над сайтом без HTTPS.

Мое решение

  • Сначала проверьте, какой тип безопасности используется вашим сервером через SSL Labs. Он должен быть TLS1.2 или выше, а другой TLS или SSL. Он также должен иметь шифрование SHA256. Возможно, вам потребуется исправить сервер: https://support.microsoft.com/en-us/kb/3106991.

  • Используйте IISCrypto для установки правильных TLS и шифров. Я использовал изменения реестра, предложенные в другом месте в stackoverflow, но это не сработало и на самом деле полностью напортачивало мой сервер для всего, используя сообщения HTTPS, а не только для моего сайта разработки! IISCrypto также обрабатывает шифры.

  • Убедитесь, что ваш пул приложений v4.5, что само по себе неясно, потому что IIS может предлагать только v4.0 в качестве опции. Однако это, вероятно, фактически v4.5. Вы можете проверить это через https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx.

  • В вашем коде вам нужно использовать Server.CreateObject ("MSXML2.XMLHTTP.6.0"), а не Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0"), как указано выше.

Теперь я понятия не имею, почему не-сервер XMLHTTP работает так, как будто это противоречит документации, стоящей за ним. Прямо сейчас, после 10 дней стресса, паники и разочарования, мне все равно! Надеюсь, это полезно для других.

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

Ошибка IPN PayPal с ошибкой сервера

Ошибки PayPal SSL Windows 2008

Произошла ошибка в поддержке защищенного канала

классические ошибки протокола ASP PayPal Sandbox

Я бы хотел поблагодарить Rackspace и GoDaddy за их помощь в этом. Я бы хотел публично заявить, что я нашел, что paypal имеет худшую техническую поддержку и просто не волнует, постоянно указывая на свои собственные документы, если они когда-либо отвечают. Говорят, что они отправляли электронные письма об этом с сентября 2014 года, но я так и не получил их. Эти новые требования активны в песочнице PayPal, но выходят в эфир в сентябре 2016 года. Я только наткнулся на нее как на разработку нового решения, поэтому мне нужна песочница - если вы бежите вживую, вы не будете знать о проблеме до тех пор, пока она не ударит, а затем вы мертвы в воде. Протестируйте всю свою платежную систему в песочнице PayPal как можно скорее.

Ответ 3

Коды ошибок устранения неполадок:

  • -2147012739 - HRESULT.
  • В шестнадцатеричном формате 0x80072F7D.
  • Посмотрите на LOWORD: 0x2F7D.
  • Преобразуем это в десятичное число: 12157.
  • Коды ошибок поиска 12157.
  • Найдите, что он соответствует: ERROR_WINHTTP_SECURE_CHANNEL_ERROR

Немного Google-fu находит http://msdn.microsoft.com/en-us/library/windows/desktop/aa383770 (v = vs .85).aspx, который гласит:

ERROR_WINHTTP_SECURE_CHANNEL_ERROR

12157

Указывает, что произошла ошибка с безопасным каналом (эквивалент кодов ошибок, начинающихся с "SEC_E_" и "SEC_I_", перечисленных в заголовочном файле "winerror.h" ).

Однако вы уже обнаружили это, поскольку появившееся сообщение было "Описание: произошла ошибка в поддержке безопасного канала". Таким образом, это ведет нас прямо туда, где мы начали.

Другое замечание, которое я делаю, заключается в том, что ваш код является неасинхронным запросом WinHTTP (я знаю, что он должен функционировать внутри ASP), но проблема состоит в том, что из-за высокой частоты ваша машина может обрабатывать больше чем один запрос WinHTTP. Я видел, как некоторые Windows преднамеренно дросселируют общее количество активных одновременных запросов WinHTTP, блокируя поздние запросы. Например, на машине под управлением Windows 7 процесс не может выполнять более двух одновременных запросов на один и тот же удаленный сервер. т.е. 3-й, 4-й... запросы будут заблокированы до тех пор, пока не будут выполнены первые два.

Одним из решений является загрузка баланса входящего запроса в более чем один пул приложений или на большее количество серверов.

Ответ 4

Все верно, однако "критический" недостающий бит для поддержки TLS1.2 в Windows 7 с IIS7.5 и классическим asp устанавливает это в реестре: -

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

Я надеюсь, что это спасет вас в день фальсификации, перезагрузки и головокружения!:)

Этот фрагмент кода полезен для тестирования. https://www.howsmyssl.com/

<%
Set winhttp = Server.CreateObject("WinHTTP.WinHTTPRequest.5.1")
winhttp.open "GET", "https://howsmyssl.com/a/check", False
winhttp.Send
Response.Write winhttp.responseText 
%>

Ответ 5

У нас была вариация по этим вопросам, и это действительно стоило нам времени, чтобы понять это.
Вот ситуация: старый сервер Linux, на котором размещается приложение, написанное на PHP, и предоставляет данные через вызовы webservice. Сервер использует HTTPS. Вызовы от разных клиентов производятся с помощью кода, использующего библиотеку winHTTP 5.2. (Winhttp.dll)

Симптом: наши клиенты теперь получают сообщения об ошибках при повторных вызовах winHTTP с помощью команды "POST". Сообщения - либо "Буферы, переданные функции, были маленькими", либо "Ошибка в поддержке защищенного канала". После долгих поисков мы обнаружили, что сервер клиентов регистрировал "предупреждающий код 2036" Уведомление о событии "в журнале просмотра событий, который соответствовал видимому сообщению об ошибке.

Решение. Мы обнаружили, что наш старый Linux-сервер не может поддерживать TLS 1.2. (CentOS 5.11). Мы также узнали, что недавно некоторые из наших клиентов (лето 2016) применили обновление для своих серверов Microsoft. (Server 2008, server 2012) Исправление заключалось в том, чтобы заставить их серверы использовать TLS 1.1 для вызовов webservice. Мне довольно странно, что настройки в Internet Explorer для изменения TLS не повлияли на проблему. Однако, изменив настройку в групповой политике, мы смогли решить эту проблему. Наш технический советник по этому вопросу отметил, что изменение действительно неясно, но сторонний поставщик предоставил быстрое решение. Этот инструмент называется IIS Crypto от Nartac. https://www.nartac.com/Products/IISCrypto/Download  Этот инструмент позволяет вам выбрать "Протоколы".  Теперь мы получаем новый сервер для размещения наших приложений (CentOS 6), а затем должны иметь возможность использовать протокол TLS 1.2!

Ответ 6

Я столкнулся с этой ошибкой несколько месяцев назад. Чаще всего эта проблема вызвана недействительным сертификатом SSL. Учитывая, что во время сообщения, которое вы только что перенесли на новый сервер, вам просто нужно переустановить сертификат SSL.

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