Msxml6 dll ошибка поддержки безопасных каналов 1с 77

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


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

Номер: -2147012739

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

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

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

  • 1 Мне удалось убедиться, что в том же пуле приложений я смог успешно выполнить точно такой же запрос в коде программной части страницы ASP.NET, когда он выдавал ошибку на классической странице ASP.
  • Я только что попытался преобразовать классическую страницу ASP из объекта MSXML2.ServerXMLHTTP в WinHttp.WinHttpRequest.5.1. Опять же, это отлично работает для многих запросов, но в конечном итоге также возникла ошибка поддержки безопасного канала.
  • Теперь я переключил сайт из интегрированного режима в классический, чтобы он работал как IIS 6. Тем не менее, проблема возникала по крайней мере дважды за последние 24 часа.
  • 1 Я полагаю, что это проблема сети на уровне ниже HTTP (S). Просмотрите журнал событий системы, приложений и безопасности на обоих серверах. Кроме того, если возможно, измените свой сценарий для записи простейшего текстового файла, указав «время начала» (до метода ) и «время остановки» (после метода ). Посмотрите на разницу во времени при сбое обслуживания. Также попробуйте вызвать метод со значением — я не верю, что это может помочь, но попробуйте.
  • 1 Относится ли отправляемый вами запрос к тому же серверу, на котором запущен скрипт?

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

кому:

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

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

  • «MSXML2.XMLHTTP.6.0» не поддерживает метод «waitForResponse». Это афера.

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

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

Эта проблема

Попытка протестировать PayPal IPN на Windows Server 2008 с использованием классического ASP и песочницы PayPal возвращает ошибку «Произошла ошибка в поддержке безопасного канала».

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

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

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

Мое решение

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

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

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

  4. В вашем коде вам нужно использовать , а не , как упоминалось выше.

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

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

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

Ошибки PayPal SSL Windows 2008

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

классические ошибки SSL в песочнице ASP PayPal

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

Ни один из приведенных выше ответов не относится к моей ситуации. Затем я перешел по ссылке здесь:

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

Это обновление обеспечивает поддержку Transport Layer Security (TLS) 1.1 и TLS 1.2 в Windows Server 2012, Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 SP1.

Приложения и службы, написанные с использованием соединений WinHTTP для Secure Sockets Layer (SSL), которые используют флаг WINHTTP_OPTION_SECURE_PROTOCOLS, не могут использовать протоколы TLS 1.1 или TLS 1.2. Это связано с тем, что определение этого флага не включает эти приложения и службы.

Это обновление добавляет поддержку записи реестра DefaultSecureProtocols, которая позволяет системному администратору указывать, какие протоколы SSL следует использовать, когда используется флаг WINHTTP_OPTION_SECURE_PROTOCOLS.

Это может позволить определенным приложениям, которые были созданы с использованием флага по умолчанию WinHTTP, иметь возможность использовать новые протоколы TLS 1.2 или TLS 1.1 изначально без необходимости обновлять приложение.

Так обстоит дело с некоторыми приложениями Microsoft Office, когда они открывают документы из библиотеки SharePoint или веб-папки, туннелей IP-HTTPS для подключения DirectAccess и других приложений с использованием таких технологий, как WebClient, с использованием WebDav, WinRM и других.

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

на сервере , исходящий на сервер через TLS, ответил на рассматриваемую ошибку. Я подумал, что это может быть совместимость с набором шифров. трассировка указанная версия в запросе была TLS 1.0, но серверу требуется TLS 1.2. Наборы шифров, отправленные на исходящий сервер из клиентской службы, были в порядке. Проблема в том, что клиентская служба или приложение на сервере Windows по умолчанию использует системное значение по умолчанию, а не TLS 1.2.

Решение состоит в том, чтобы добавить подраздел реестра с именем со значением, соответствующим тому, какие версии TLS должны поддерживаться. Добавьте указанный подраздел реестра с типом в следующие места:

  • HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Internet Settings WinHttp
  • HKEY_LOCAL_MACHINE SOFTWARE Wow6432Node Microsoft Windows CurrentVersion Internet Settings WinHttp

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

  • HKEY_CURRENT_USER Software Microsoft Windows CurrentVersion Настройки Интернета
  • HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Internet Settings

Ниже вы можете найти таблицу значений для обоих подключей:


Например:

Администратор хочет изменить значения по умолчанию для WINHTTP_OPTION_SECURE_PROTOCOLS, чтобы указать TLS 1.1 и TLS 1.2.

Возьмите значение TLS 1.1 (0x00000200) и значение TLS 1.2 (0x00000800), затем сложите их вместе в калькуляторе (в режиме программиста), получившееся значение реестра будет 0x00000A00.

Я обратился 0x00000A00 как значение для обоих подключей, и проблема успешно решена.

Также есть Легко исправить (ссылка здесь: https://aka.ms/easyfix51044) доступна от Microsoft, если вы не хотите вручную вводить подразделы и значения реестра.

  • В Windows 7 это Easy Fix отлично работает даже с MSXML2.ServerXMLHTTP.6.0 (нет необходимости переходить на MSXML2.XMLHTTP.6.0). Придется перезагрузить машину после ее установки.
  • Отдельный вопрос о том, как настроить параметр реестра. Я рекомендовал это проверить. Это однострочный текст в командной строке, и я могу подтвердить, что он работает. superuser.com/questions/1080317/…

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


Надеюсь, это избавит вас от лишних хлопот, перезагрузок и головокружения!

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


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

  1. -2147012739 — это HRESULT.
  2. В шестнадцатеричном формате это 0x80072F7D.
  3. Посмотрите на LOWORD: 0x2F7D.
  4. Преобразуйте это обратно в десятичное: 12157.
  5. Найдите коды ошибок 12157.
  6. Найдите соответствие: 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 процесс не может выполнять более двух одновременных запросов к одному и тому же удаленному серверу. т.е. третий, четвертый … запросы будут заблокированы до завершения первых двух.

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

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

Симптом: наши клиенты теперь получают спорадические сообщения об ошибках при повторных вызовах winHTTP с использованием команды «POST». Сообщения либо «Буферы, предоставленные функции, были слишком маленькими», либо «Произошла ошибка в поддержке безопасного канала». После долгих поисков мы обнаружили, что клиентский сервер регистрирует «Schannel Event ID 36887 alert code 20» в средстве просмотра событий, что соответствует видимому сообщению об ошибке.

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

В классическом сценарии ASP для Windows Server 2016, извлекающем URL-адрес HTTPS из Windows Server 2012 R2, мне недавно пришлось удалить SSL 2.0 из SecureProtocols, чтобы остановить эту ошибку безопасного канала -2147012739.


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

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

Обновлено 28.11.2022

directum logoДобрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз мы с вами решали проблему, когда у нас тормозил Directum на терминальной ферме. В сегодняшней ситуации я опять вернусь к данному программному обеспечению и покажу, что мне удалось раскопать в ситуации, что при попытке создать договорной документ и выбрать его из конструктора документов, я получаю предупреждение «Ошибка поддержки безопасных каналов«. Давайте смотреть в чем дело и что можно поменять, чтобы все заработало.

Устранение ошибки поддержки безопасных каналов

Данную проблему я поймал в Directum на своей RDS-ферме. Стало увеличиваться количество обращений со стороны пользователей, что они при попытке создания договорного документа стали видеть ошибку:

Ошибка поддержки безопасных каналов

Ошибка поддержки безопасных каналов

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

  • 1️⃣В интернете все копипастят друг у друга, что в данной ситуации помогает включение TLS, но я проверил и правки в реестре не дают ничего, тем более у меня уже они были активированы, я с этим еще сталкивался, когда получал ошибку «Unable to resolve package source» при установке модуля PowerShell.
  • 2️⃣Далее если у вас есть антивирусное решение, то я вам советую его отключить на время, пока будите производить тестирование. Антивирус Касперского тут так же был ни причем
  • 3️⃣Далее, что я обычно проверяю, это не производилась ли установка нового софта или обновлений Windows. Обязательно выведите список установленных программ и посмотрите, нет ли там чего-то нового. Бывает ситуация, что некоторые программы могут конфликтовать при совместном использовании, например очень частая ситуация с КриптоПРО, старыми версиями. Если она есть, то попробуйте ее удалить.
  • 4️⃣Проверьте не было ли установки новых обновлений, это можно посмотреть в истории параметров Windows или в оснастке appwiz.cpl.

История установки обновлений Windows Server 2019

В результате на Windows Server прилетело KB5018411 на клиентские Windows 10 и Windows 11 прилетело kb5018410, что в итоге делать, на текущий момент просто удалять и ждать новых обновлений от Microsoft.

Если у вас есть поддержка от Directum, то стоит задать вопрос туда возможно. что-то подскажут, у меня такой возможности нет

Чтобы удалить KB5018411  я воспользуюсь командной строкой и утилитой wusa. Введите:

wusa /uninstall /kb:5018411

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

Удаление обновления Windows через WUSA

Так же вы можете сделать, и тихое удаление добавим ключи: /quiet /norestart

wusa /uninstall /kb:5018411 /quiet /norestart

Удаление автономного пакета Windows

После этого мой Directum заработал, посмотрю что будет со следующими обновлениями, может Mixrosoft пофиксит это.

Обновление 28.11.2022

Как и ожидалось, данная ошибка была устранена установкой ноябрьских обновлений KB5019964. С вами был Иван Семин, автор и создатель IT проекта Pyatilistnik.org.

Цитата:

MWWRuza ➤ Отправляю GET запрос

Откуда отправляешь? это не какое-то старое … которое с сертификатами не дружит?
Решил погуглить… так и есть

Как оказалось, далеко не все знают, что причина этих ошибок кроется в обновлении протокола шифрования на стороне сайта. Сейчас повсеместно начинает использоваться протокол TLS версии 1.2, поддержка которого в 1С полноценно начата с релиза 8.3.9

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

Но часто мне попадаются обработки работы с сайтом, которые используют средства Windows: объекты класса «WinHTTP.WinHTTPRequest.5.1» или «MSXML2.ServerXMLHTTP.6.0» и т.п. В этом случае необходимо активировать поддержку протокола TLS 1.2 в самой Windows.

Для этого достаточно внести в реестр следующие записи, после чего перезагрузить Windows:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2]

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client]
«DisabledByDefault»=dword:00000000
«Enabled»=dword:00000001

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server]
«DisabledByDefault»=dword:00000000
«Enabled»=dword:00000001

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp]
«DefaultSecureProtocols»=dword:00000800

[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionInternet SettingsWinHttp]
«DefaultSecureProtocols»=dword:00000800

Небольшое замечание к двум последним параметрам. В указанном коде указано значение 00000800 — это значение активирует протокол TLS 1.2 по умолчанию. Если необходимо использовать TLS 1.1 то значение необходимо заменить на 00000200, а если оба протокола, то на 00000A00.

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

Мое решение

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

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

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

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

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

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

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

Ошибки PayPal SSL Windows 2008

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

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

I’d like to publicly thank Rackspace and GoDaddy for their help with this. I’d like to publicly state that I found paypal have the worst technical support ever and just do not care, constantly pointing to their own docs, if they ever respond. They say they’ve been sending emails out about this since September 2014 but I never received one. These new requirements are active on the PayPal Sandbox but go live in September 2016. I only came across it as developing a new solution so needed the sandbox — if you’re running live you won’t know about Проблема until it hits and then you’re dead in the water. Test your entire payment system on the PayPal sandbox asap is my advice!!

Ошибка при вызове метода контекста (Send): Произошла исключительная ситуация (WinHttp.WinHttpRequest): Ошибка поддержки безопасных каналов

Использую вот такую процедуру

WinHttp = Новый COMОбъект(«WinHttp.WinHttpRequest.5.1»);

    WinHttp.Option(2,»utf-8″);                  

    WinHttp.Open(«GET», «https://api.unisender.com/ru/api/importContacts?format=json&api_key=»; + Ключ, 0);  

    

    WinHttp.SetRequestHeader(«Accept-Language», «ru»);

    WinHttp.SetRequestHeader(«Accept-Charset», «utf-8»);

    WinHttp.setRequestHeader(«Content-Language», «ru»);

    WinHttp.setRequestHeader(«Content-Charset», «utf-8»);

    WinHttp.setRequestHeader(«Content-Type», «application/x-www-form-urlencoded; charset=utf-8»);    

    
    СтрокаЗапроса = «https://api.unisender.com/ru/api/importContacts?format=json&api_key=6qwibe9uewm7x6n9karscy6a7ze73q6tic3s65ty&field_names[0]=email&field_names[1]=email_list_ids&field_names[2]=Name&field_names[3]=will&field_names[4]=DR&field_names[5]=DR_end&data[0][0]=test@mail.ru&data[0][1]=15231245&data[0][2]=Петров Джон Биллович&data[0][3]=3555&data[0][4]=28.11.2018 0:00:00&data[0][5]=28.11.2018 0:00:00»;

        Попытка

            WinHttp.Send(СтрокаЗапроса);

        Исключение

            Сообщить(ОписаниеОшибки());

        КонецПопытки;

Причем если запуская с компа на win 8, проблем нет, но если запускаю с сервера Win 2008 R2, то такая вот фигня


Offline

YuryL

 


#1
Оставлено
:

6 февраля 2014 г. 16:06:29(UTC)

YuryL

Статус: Новичок

Группы: Участники

Зарегистрирован: 06.02.2014(UTC)
Сообщений: 5
Российская Федерация
Откуда: Kirov

Доброго времени суток!

На Windows 7 установлено следующее ПО КриптоПро:
Версия ядра — 3.6.5364 KC1
Версия продукта — 3.6.7491

В реестр импортирован личный сертификат, через оснастку установлен в хранилище сертификатов.

Далее js-скриптом пытаемся осуществить запрос к контент-провайдеру:

Код:

function start()
{
    var strRequest = "SomeRequestHere";
         
   WScript.Echo("Sending request...");
   strResult = doRequest(strRequest); 
   WScript.Echo(strResult);   
   WScript.Echo("Done!");   
}
 

function doRequest(sReqBody)
{
 
    var HTTPREQUEST_PROXYSETTING_DEFAULT = 0;
    var HTTPREQUEST_PROXYSETTING_DIRECT = 1;
    var HTTPREQUEST_PROXYSETTING_PROXY = 2;
    var strResult;
 
    try
 {
// Create the WinHTTPRequest ActiveX Object.
     var WinHttpReq = new ActiveXObject("WinHttp.WinHttpRequest.5.1");
     
//Set Proxy Server if necessary
      WinHttpReq.SetProxy( HTTPREQUEST_PROXYSETTING_PROXY, "proxy.server.ru:3128", "*.e-i.ru");
     
     
//Create an HTTP request
 WinHttpReq.Open("POST", "https://www.rb-ei.com/cpuEnquiry.asp", true);     
    
//Select a client certificate
//CN = Иванов Иван Иванович
 
      WinHttpReq.SetClientCertificate("CURRENT_USER\My\Иванов Иван Иванович");
      WScript.Echo("Certificate is: " + "CURRENT_USER\My\Иванов Иван Иванович");
      
       
     WinHttpReq.SetRequestHeader("Content-Type","application/x-www-form-urlencoded; Charset=windows-1251");
          
//  Send the HTTP request
     WinHttpReq.Send(sReqBody);
     WinHttpReq.WaitForResponse();
           
     WScript.Echo("Request status: " + WinHttpReq.StatusText);
     strResult = WinHttpReq.ResponseText;
     WScript.Echo(strResult);
 }
    catch (objError)
 {
     var err = objError + "n";
     err += "WinHTTP returned error: " + (objError.number & 0xFFFF).toString() + "nn";
     err += objError.description;
     WScript.Echo(err);
 }
  
//Return the response text
    return strResult;
}
 

//Start the script
 
start();

В ответ получаю ошибку: WinHTTP returned error: 12157. Ошибка поддержки безопасных каналов
Причем заход через IE по адресу https://www.rb-ei.com/cpuEnquiry.asp успешен.
Тот же пример через WinHTTPна любой другой адрес по https, не использующий криптопро также успешен.
Служба поддержки контент-провайдера помочь не может, переадресовала на вас для решения вопроса.


Вверх

Offline

YuryL

 


#2
Оставлено
:

6 февраля 2014 г. 16:40:33(UTC)

YuryL

Статус: Новичок

Группы: Участники

Зарегистрирован: 06.02.2014(UTC)
Сообщений: 5
Российская Федерация
Откуда: Kirov

Дополню. Данная проблема проявляется только на ресурсах, которые требуют авторизацию на сертификатах.
Если протестировать на ресурсе без авторизации, но использующих SSL на ГОСТах (пример https://icrs.nbki.ru/main/), то все ок.


Вверх

Offline

Vladislav Osmanov

 


#3
Оставлено
:

6 февраля 2014 г. 18:18:11(UTC)

Vladislav Osmanov

Статус: Сотрудник

Группы: Участники

Зарегистрирован: 19.08.2009(UTC)
Сообщений: 8

Поблагодарили: 4 раз в 4 постах

Юрий, добрый вечер.

Судя по всему, это не совсем js, как Вы пишите, а Windows Script. Как он у вас выполняется?

Попробуйте использовать подключение через XMLHttpRequest с исполнением кода в браузере Internet Explorer.

Примерный код:

Код:

	var request = new XMLHttpRequest();

	request.open("GET", "https://www.rb-ei.com/cpuEnquiry.asp", false);
	request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; Charset=windows-1251");
	request.send(sReqBody);

	if (request.readyState == 4) {
		if (request.status == 200) {
			//Success
			var svcResponse = request.responseText;
		}
		else {
			//Failure
		}
	}

Браузер сам предложит Вам выбрать клиентский сертификат.


Вверх

WWW


Offline

YuryL

 


#4
Оставлено
:

6 февраля 2014 г. 18:58:19(UTC)

YuryL

Статус: Новичок

Группы: Участники

Зарегистрирован: 06.02.2014(UTC)
Сообщений: 5
Российская Федерация
Откуда: Kirov

Автор: Vladislav Osmanov Перейти к цитате

Юрий, добрый вечер.

Судя по всему, это не совсем js, как Вы пишите, а Windows Script. Как он у вас выполняется?

Попробуйте использовать подключение через XMLHttpRequest с исполнением кода в браузере Internet Explorer.

Примерный код:

Код:

	var request = new XMLHttpRequest();

	request.open("GET", "https://www.rb-ei.com/cpuEnquiry.asp", false);
	request.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; Charset=windows-1251");
	request.send(sReqBody);

	if (request.readyState == 4) {
		if (request.status == 200) {
			//Success
			var svcResponse = request.responseText;
		}
		else {
			//Failure
		}
	}

Браузер сам предложит Вам выбрать клиентский сертификат.

Владислав, спасибо за ответ!

Извиняюсь, конечно же WScript. Путем множества экспериментов пришел к такой зависимости:
Если запустить данный скрипт из под Администратора (повышение привилегий), то запрос все таки проходит. Такое ощущение что без повышения прав компонент не может получить клиентский сертификат методом WinHttpReq.SetClientCertificate.

И попутно появилась вторая проблема. Никак не могу использовать компонент для проверки ЭЦП:

Код:

function doVerify(strMessage) {
    try {
        var SignedData = new ActiveXObject("CAPICOM.SignedData");

        SignedData.Verify( strMessage, false, 0);
        return SignedData.Content;
	}
    catch (objError)
	{
	    var err = objError + "n";
	    err += "CAPICOM returned error: " + (objError.number & 0xFFFF).toString() + "nn";
	    err += objError.description;
	    WScript.Echo(err);
	}
}

Ругается что компонент не найден. Устанавливал по инструкции с вашего сайта. У меня Windows 7 x64. Неужели под эту ОС нет возможности использовать данный компонент?


Вверх

Offline

Максим Коллегин

 


#5
Оставлено
:

6 февраля 2014 г. 19:01:45(UTC)

Максим Коллегин

Статус: Сотрудник

Группы: Администраторы

Зарегистрирован: 12.12.2007(UTC)
Сообщений: 6,253
Мужчина
Откуда: КРИПТО-ПРО

Сказал «Спасибо»: 21 раз
Поблагодарили: 658 раз в 582 постах

в 64-х битах нет CAPIcom, на аналогичный интерфейс предоставляет наш browser плагин.

Отредактировано пользователем 6 февраля 2014 г. 19:02:26(UTC)
 | Причина: Не указана

Знания в базе знаний, поддержка в техподдержке


Вверх

WWW


Offline

Андрей Писарев

 


#6
Оставлено
:

6 февраля 2014 г. 23:35:35(UTC)

Андрей *

Статус: Сотрудник

Группы: Участники

Зарегистрирован: 26.07.2011(UTC)
Сообщений: 11,736
Мужчина
Российская Федерация

Сказал «Спасибо»: 451 раз
Поблагодарили: 1838 раз в 1421 постах

Автор: YuryL Перейти к цитате

Ругается что компонент не найден. Устанавливал по инструкции с вашего сайта. У меня Windows 7 x64. Неужели под эту ОС нет возможности использовать данный компонент?

И браузер IE используется х64?

Техническую поддержку оказываем тут
Наша база знаний


Вверх

WWW


Offline

YuryL

 


#7
Оставлено
:

7 февраля 2014 г. 10:21:48(UTC)

YuryL

Статус: Новичок

Группы: Участники

Зарегистрирован: 06.02.2014(UTC)
Сообщений: 5
Российская Федерация
Откуда: Kirov

Автор: Андрей * Перейти к цитате

Автор: YuryL Перейти к цитате

Ругается что компонент не найден. Устанавливал по инструкции с вашего сайта. У меня Windows 7 x64. Неужели под эту ОС нет возможности использовать данный компонент?

И браузер IE используется х64?

Андрей, я использую данные компоненты не в браузере, а в автономных скриптах. Т.е. фактически вызываются они console-mode.


Вверх

Offline

YuryL

 


#8
Оставлено
:

7 февраля 2014 г. 11:39:15(UTC)

YuryL

Статус: Новичок

Группы: Участники

Зарегистрирован: 06.02.2014(UTC)
Сообщений: 5
Российская Федерация
Откуда: Kirov

Автор: maxdm Перейти к цитате

в 64-х битах нет CAPIcom, на аналогичный интерфейс предоставляет наш browser плагин.

Пробую использовать ваш плагин. Контент-провайдер возвращает мне документ подписанные ЭЦП в кодировке BASE64. Сертификат отправителя с открытым ключом для ЭЦП я импортировал в хранилище сертификатов.

Пробую снять ЭЦП так:

Код:

function doVerify(strSignedMessage) {
 
    var CADESCOM_CADES_X_LONG_TYPE_1 = 0x5d;

    try {
        var SignedData = new ActiveXObject("CAdESCOM.CadesSignedData");
         
        SignedData.Verify( strSignedMessage, false, 0);
        return SignedData.Content;
	}
    catch (objError)
	{
	    var err = objError + "n";
	    err += "CAdESCOM returned error: " + (objError.number & 0xFFFF).toString() + "nn";
	    err += objError.description;
	    WScript.Echo(err);
	}
}

Данный код возвращает исключение: 4111 (Криптографическое сообщение не содержит всех запрошенных атрибутов).
Что я делаю не так?


Вверх
Пользователи, просматривающие эту тему

Guest (2)

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Ошибка при вызове метода контекста (Send): Произошла исключительная ситуация (WinHttp.WinHttpRequest): Ошибка поддержки безопасных каналов

Использую вот такую процедуру

WinHttp = Новый COMОбъект(«WinHttp.WinHttpRequest.5.1»);

    WinHttp.Option(2,»utf-8″);                  

    WinHttp.Open(«GET», «https://api.unisender.com/ru/api/importContacts?format=json&api_key=»; + Ключ, 0);  

    
    WinHttp.SetRequestHeader(«Accept-Language», «ru»);

    WinHttp.SetRequestHeader(«Accept-Charset», «utf-8»);

    WinHttp.setRequestHeader(«Content-Language», «ru»);

    WinHttp.setRequestHeader(«Content-Charset», «utf-8»);

    WinHttp.setRequestHeader(«Content-Type», «application/x-www-form-urlencoded; charset=utf-8»);    

    
    СтрокаЗапроса = «https://api.unisender.com/ru/api/importContacts?format=json&api_key=6qwibe9uewm7x6n9karscy6a7ze73q6tic3s65ty&field_names[0]=email&field_names[1]=email_list_ids&field_names[2]=Name&field_names[3]=will&field_names[4]=DR&field_names[5]=DR_end&data[0][0]=test@mail.ru&data[0][1]=15231245&data[0][2]=Петров Джон Биллович&data[0][3]=3555&data[0][4]=28.11.2018 0:00:00&data[0][5]=28.11.2018 0:00:00»;

        Попытка

            WinHttp.Send(СтрокаЗапроса);

        Исключение

            Сообщить(ОписаниеОшибки());

        КонецПопытки;

Причем если запуская с компа на win 8, проблем нет, но если запускаю с сервера Win 2008 R2, то такая вот фигня

Я видел этот вопрос, но ответа пока нет. Мой сервер использует TLS 1.2, как и сервер, с которого я запрашиваю

      <!--#INCLUDE virtual="/json/jsonObject.class.asp"-->
<%
    Session.LCID=2057
    Dim jsonString, jsonObj, outputObj

    Set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP.6.0")
    xmlhttp.SetOption 2, xmlhttp.GetOption(2)
    xmlhttp.open "POST", "https://xxx.domain/api/auth", 0
    xmlhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
    xmlhttp.send "ClientId=X&ClientSecret=Y&GrantType=Z"
    jsonString = xmlhttp.responseText    
    response.write(jsonString)
    Set xmlhttp = Nothing 

    set jsonObj = new JSONobject
    set outputObj = jsonObj.parse(jsonString)

    'response.write(outputObj("access_token"))
%>

Это дает мне

      msxml6.dll error '80072f7d'

An error occurred in the secure channel support

Я видел несколько предложений по удалению сервера с ServerXMLHTTP, поэтому я сделал это и получил

      Microsoft VBScript runtime error '800a01b6'

Object doesn't support this property or method: 'xmlhttp.GetOption'

Я разрешаю это, а затем он говорит, что SetOption не поддерживается. Я полностью удаляю эту строку, а затем говорится, что ClientID не отправляется

Когда я пытаюсь использовать https://markohoven.com/2020/03/06/msxml2-serverxmlhttp-and-tls1-2/, я получаю

      Microsoft VBScript runtime error '800a0005'

Invalid procedure call or argument: 'XMLServer.Option'

Затем я попробовал следующее

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

Из этого следует, что я не использую TLS 1.2?

      {
    "given_cipher_suites": ["TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "TLS_DHE_RSA_WITH_AES_256_CBC_SHA", "TLS_DHE_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_256_CBC_SHA", "TLS_RSA_WITH_AES_128_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA", "TLS_DHE_DSS_WITH_AES_256_CBC_SHA", "TLS_DHE_DSS_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_3DES_EDE_CBC_SHA", "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA", "TLS_RSA_WITH_RC4_128_SHA", "TLS_RSA_WITH_RC4_128_MD5"],
    "ephemeral_keys_supported": true,
    "session_ticket_supported": false,
    "tls_compression_supported": false,
    "unknown_cipher_suite_supported": false,
    "beast_vuln": true,
    "able_to_detect_n_minus_one_splitting": false,
    "insecure_cipher_suites": {
        "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA": ["uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"],
        "TLS_RSA_WITH_3DES_EDE_CBC_SHA": ["uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"],
        "TLS_RSA_WITH_RC4_128_MD5": ["uses RC4 which has insecure biases in its output"],
        "TLS_RSA_WITH_RC4_128_SHA": ["uses RC4 which has insecure biases in its output"]
    },
    "tls_version": "TLS 1.0",
    "rating": "Bad"
}

Сервер, на котором я использую Windows Server 2008. Что еще я могу сделать?

Обновлено 28.11.2022

directum logoДобрый день! Уважаемые читатели и гости IT портала Pyatilistnik.org. В прошлый раз мы с вами решали проблему, когда у нас тормозил Directum на терминальной ферме. В сегодняшней ситуации я опять вернусь к данному программному обеспечению и покажу, что мне удалось раскопать в ситуации, что при попытке создать договорной документ и выбрать его из конструктора документов, я получаю предупреждение «Ошибка поддержки безопасных каналов«. Давайте смотреть в чем дело и что можно поменять, чтобы все заработало.

Устранение ошибки поддержки безопасных каналов

Данную проблему я поймал в Directum на своей RDS-ферме. Стало увеличиваться количество обращений со стороны пользователей, что они при попытке создания договорного документа стали видеть ошибку:

Ошибка поддержки безопасных каналов

Ошибка поддержки безопасных каналов

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

  • 1️⃣В интернете все копипастят друг у друга, что в данной ситуации помогает включение TLS, но я проверил и правки в реестре не дают ничего, тем более у меня уже они были активированы, я с этим еще сталкивался, когда получал ошибку «Unable to resolve package source» при установке модуля PowerShell.
  • 2️⃣Далее если у вас есть антивирусное решение, то я вам советую его отключить на время, пока будите производить тестирование. Антивирус Касперского тут так же был ни причем
  • 3️⃣Далее, что я обычно проверяю, это не производилась ли установка нового софта или обновлений Windows. Обязательно выведите список установленных программ и посмотрите, нет ли там чего-то нового. Бывает ситуация, что некоторые программы могут конфликтовать при совместном использовании, например очень частая ситуация с КриптоПРО, старыми версиями. Если она есть, то попробуйте ее удалить.
  • 4️⃣Проверьте не было ли установки новых обновлений, это можно посмотреть в истории параметров Windows или в оснастке appwiz.cpl.

История установки обновлений Windows Server 2019

В результате на Windows Server прилетело KB5018411 на клиентские Windows 10 и Windows 11 прилетело kb5018410, что в итоге делать, на текущий момент просто удалять и ждать новых обновлений от Microsoft.

Если у вас есть поддержка от Directum, то стоит задать вопрос туда возможно. что-то подскажут, у меня такой возможности нет

Чтобы удалить KB5018411  я воспользуюсь командной строкой и утилитой wusa. Введите:

wusa /uninstall /kb:5018411

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

Удаление обновления Windows через WUSA

Так же вы можете сделать, и тихое удаление добавим ключи: /quiet /norestart

wusa /uninstall /kb:5018411 /quiet /norestart

Удаление автономного пакета Windows

После этого мой Directum заработал, посмотрю что будет со следующими обновлениями, может Mixrosoft пофиксит это.

Обновление 28.11.2022

Как и ожидалось, данная ошибка была устранена установкой ноябрьских обновлений KB5019964. С вами был Иван Семин, автор и создатель IT проекта Pyatilistnik.org.

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


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

Номер: -2147012739

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

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

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

  • 1 Мне удалось убедиться, что в том же пуле приложений я смог успешно выполнить точно такой же запрос в коде программной части страницы ASP.NET, когда он выдавал ошибку на классической странице ASP.
  • Я только что попытался преобразовать классическую страницу ASP из объекта MSXML2.ServerXMLHTTP в WinHttp.WinHttpRequest.5.1. Опять же, это отлично работает для многих запросов, но в конечном итоге также возникла ошибка поддержки безопасного канала.
  • Теперь я переключил сайт из интегрированного режима в классический, чтобы он работал как IIS 6. Тем не менее, проблема возникала по крайней мере дважды за последние 24 часа.
  • 1 Я полагаю, что это проблема сети на уровне ниже HTTP (S). Просмотрите журнал событий системы, приложений и безопасности на обоих серверах. Кроме того, если возможно, измените свой сценарий для записи простейшего текстового файла, указав «время начала» (до метода ) и «время остановки» (после метода ). Посмотрите на разницу во времени при сбое обслуживания. Также попробуйте вызвать метод со значением — я не верю, что это может помочь, но попробуйте.
  • 1 Относится ли отправляемый вами запрос к тому же серверу, на котором запущен скрипт?

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

кому:

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

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

  • «MSXML2.XMLHTTP.6.0» не поддерживает метод «waitForResponse». Это афера.

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

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

Эта проблема

Попытка протестировать PayPal IPN на Windows Server 2008 с использованием классического ASP и песочницы PayPal возвращает ошибку «Произошла ошибка в поддержке безопасного канала».

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

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

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

Мое решение

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

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

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

  4. В вашем коде вам нужно использовать , а не , как упоминалось выше.

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

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

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

Ошибки PayPal SSL Windows 2008

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

классические ошибки SSL в песочнице ASP PayPal

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

Ни один из приведенных выше ответов не относится к моей ситуации. Затем я перешел по ссылке здесь:

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

Это обновление обеспечивает поддержку Transport Layer Security (TLS) 1.1 и TLS 1.2 в Windows Server 2012, Windows 7 с пакетом обновления 1 (SP1) и Windows Server 2008 R2 SP1.

Приложения и службы, написанные с использованием соединений WinHTTP для Secure Sockets Layer (SSL), которые используют флаг WINHTTP_OPTION_SECURE_PROTOCOLS, не могут использовать протоколы TLS 1.1 или TLS 1.2. Это связано с тем, что определение этого флага не включает эти приложения и службы.

Это обновление добавляет поддержку записи реестра DefaultSecureProtocols, которая позволяет системному администратору указывать, какие протоколы SSL следует использовать, когда используется флаг WINHTTP_OPTION_SECURE_PROTOCOLS.

Это может позволить определенным приложениям, которые были созданы с использованием флага по умолчанию WinHTTP, иметь возможность использовать новые протоколы TLS 1.2 или TLS 1.1 изначально без необходимости обновлять приложение.

Так обстоит дело с некоторыми приложениями Microsoft Office, когда они открывают документы из библиотеки SharePoint или веб-папки, туннелей IP-HTTPS для подключения DirectAccess и других приложений с использованием таких технологий, как WebClient, с использованием WebDav, WinRM и других.

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

на сервере , исходящий на сервер через TLS, ответил на рассматриваемую ошибку. Я подумал, что это может быть совместимость с набором шифров. трассировка указанная версия в запросе была TLS 1.0, но серверу требуется TLS 1.2. Наборы шифров, отправленные на исходящий сервер из клиентской службы, были в порядке. Проблема в том, что клиентская служба или приложение на сервере Windows по умолчанию использует системное значение по умолчанию, а не TLS 1.2.

Решение состоит в том, чтобы добавить подраздел реестра с именем со значением, соответствующим тому, какие версии TLS должны поддерживаться. Добавьте указанный подраздел реестра с типом в следующие места:

  • HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Internet Settings WinHttp
  • HKEY_LOCAL_MACHINE SOFTWARE Wow6432Node Microsoft Windows CurrentVersion Internet Settings WinHttp

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

  • HKEY_CURRENT_USER Software Microsoft Windows CurrentVersion Настройки Интернета
  • HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Internet Settings

Ниже вы можете найти таблицу значений для обоих подключей:


Например:

Администратор хочет изменить значения по умолчанию для WINHTTP_OPTION_SECURE_PROTOCOLS, чтобы указать TLS 1.1 и TLS 1.2.

Возьмите значение TLS 1.1 (0x00000200) и значение TLS 1.2 (0x00000800), затем сложите их вместе в калькуляторе (в режиме программиста), получившееся значение реестра будет 0x00000A00.

Я обратился 0x00000A00 как значение для обоих подключей, и проблема успешно решена.

Также есть Легко исправить (ссылка здесь: https://aka.ms/easyfix51044) доступна от Microsoft, если вы не хотите вручную вводить подразделы и значения реестра.

  • В Windows 7 это Easy Fix отлично работает даже с MSXML2.ServerXMLHTTP.6.0 (нет необходимости переходить на MSXML2.XMLHTTP.6.0). Придется перезагрузить машину после ее установки.
  • Отдельный вопрос о том, как настроить параметр реестра. Я рекомендовал это проверить. Это однострочный текст в командной строке, и я могу подтвердить, что он работает. superuser.com/questions/1080317/…

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


Надеюсь, это избавит вас от лишних хлопот, перезагрузок и головокружения! :)

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


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

  1. -2147012739 — это HRESULT.
  2. В шестнадцатеричном формате это 0x80072F7D.
  3. Посмотрите на LOWORD: 0x2F7D.
  4. Преобразуйте это обратно в десятичное: 12157.
  5. Найдите коды ошибок 12157.
  6. Найдите соответствие: 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 процесс не может выполнять более двух одновременных запросов к одному и тому же удаленному серверу. т.е. третий, четвертый … запросы будут заблокированы до завершения первых двух.

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

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

Симптом: наши клиенты теперь получают спорадические сообщения об ошибках при повторных вызовах winHTTP с использованием команды «POST». Сообщения либо «Буферы, предоставленные функции, были слишком маленькими», либо «Произошла ошибка в поддержке безопасного канала». После долгих поисков мы обнаружили, что клиентский сервер регистрирует «Schannel Event ID 36887 alert code 20» в средстве просмотра событий, что соответствует видимому сообщению об ошибке.

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

В классическом сценарии ASP для Windows Server 2016, извлекающем URL-адрес HTTPS из Windows Server 2012 R2, мне недавно пришлось удалить SSL 2.0 из SecureProtocols, чтобы остановить эту ошибку безопасного канала -2147012739.


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

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

Понравилась статья? Поделить с друзьями:
  • Mt4 общая ошибка устранение
  • Multivac c100 ошибки
  • Must declare the scalar variable sql ошибка
  • Msz ge35va коды ошибок
  • Msz ge22va коды ошибок