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

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

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

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

Проблема

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

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

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

Подключение не защищено! ОШИБКА при входе на САЙТЫ из под Windows 7? Исправляем легко!

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!!

Источник: errorwin.ru

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

При обращении к сервису ОСМИ не происходит соединения и в журнале имеется ошибка:

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

Эта ошибка связана с тем, на стороне сервера 1С не включена поддержка протокола безопасного соединения TLSv1.2 а включены только устаревшие протоколы TLSv1.0 и TLSv1.1

Встроенная поддержка протокола TLSv1.2 полноценно появилась в 1С с версией платформы 8.3.9. Чтобы разрешить поддержку этого протокола без обновления вашей версии 1С, ознакомьтесь со статьей https://infostart.ru/public/1024217/

Путем добавления пары ключей в регистр Windows проблема исчезнет без обновления платформы.

Источник: support.osmicards.com

Честный знак, API. WinHttp.WinHttpRequest: Ошибка поддержки безопасных каналов : Маркировка

Я конечно понимаю все, хакерские атаки на ИС, в том числе и на Честный знак. Тут, все подробно расписано: https://olegon.ru/showthread.php?t=36795
Но, что-то уж очень странно себя ведут сервера честного знака, может я чего-то не понимаю, и можно все-таки как-то это обойти?
Давно(с самого начала, уже года два) рабочая обработка, для работы с API CRPT нужно получить токен.
Отправляю GET запрос, на который должен получить в ответ пару uuid и code, в структуре JSON, для дальнейшего подписания их ЭЦП, отправки подписанного обратно и получения токена для дальнейшей работы.
Но, в ответ получаю: «WinHttp.WinHttpRequest: Ошибка поддержки безопасных каналов»
Ладно, предположим, не работает.
Но, открываю тот-же УРЛ в браузере,

и вижу такой ответ:

Ошибка поддержки безопасных каналов». Давайте смотреть в чем дело и что можно поменять, чтобы все заработало.

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

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

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

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

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

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

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

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

wusa /uninstall /kb:5018411

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

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

wusa /uninstall /kb:5018411 /quiet /norestart

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

Обновление 28.11.2022

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

Популярные Похожие записи:

• Этот сеанс будет прекращен из-за ошибки шифрования данных
• Ошибка someone is currently logged into the APC
• Ошибка активации 0xC004F034 на KMS сервере
• Ошибка репликации 8524 в Active Directory
• Как ускорить Google и YouTube в России
• Ошибка Zabbix: service already exists

Источник: pyatilistnik.org

Проблемы безопасных каналов

Доменная инфраструктура Microsoft довольно сложна. Например, Active Directory (AD) использует общепринятым образом определяемую и работающую схему объектов и атрибутов в базе данных, требует сетевого подключения к одноранговым контроллерам домена (DC) для своевременного обновления элементов и корректной настройки конфигурации DNS, а также имеет другие взаимозависимости с сетевой средой

Каждый компьютер, присоединяемый к домену (клиентская рабочая станция, сервер или DC), требует подключения к DC для обеспечения выполнения обязательных требований по обслуживанию в домене AD. Для рабочих станций и серверов необходимо подключение к DC того домена, которому они принадлежат, а также к DC доменов-доверителей. DC одного домена должны иметь связь с DC доменов-доверителей и доверенных доменов. Кэшированные значения, определяющие междоменные соединения, описываются термином «безопасный канал домена». Существует два типа безопасных каналов: между членом домена и DC этого же домена; между DC домена-доверителя и DC доверенного домена.

Значение безопасных каналов

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

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

Для чего нужен безопасный канал? Напрашивается ответ: «для всего, что связано с доменом». Все службы, связанные с доменом, должны иметь возможность обнаружения DC для отправки запроса. Это верно как для члена домена (например, рабочей станции или рядового сервера), так и для DC. Обеспечение доступности эффективно реагирующего DC — функция безопасного канала.

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

В частности, пользователь, подключающийся к сайту SharePoint, настроенному на работу с Kerberos, должен запросить билет Kerberos, предъявляемый серверу SharePoint для авторизации. Компьютер пользователя просматривает кэшированные данные о безопасном канале домена (кэш, обслуживаемый службой NetLogon), определяя целевой DC для отправки запроса на билет Kerberos. Если по какой-либо причине DC не отвечает, то запрос на билет не формируется, и аутентификация с использованием Kerberos при подключении к SharePoint не работает. В зависимости от архитектуры SharePoint, результатом может быть отказ в доступе к сайту – и все из-за проблемы безопасного канала.

Рассмотрим типовой мультидоменный сценарий. Предположим, что пользователь из домена A регистрируется в системе на компьютере B в домене B. Регистрация пользователя обрабатывается в соответствии с групповой политикой, и на DC домена А по протоколу LDAP посылается запрос с тем, чтобы определить, какая политика применима к пользователю А. Как компьютер B, принадлежащий домену B, узнает, куда отправлять сетевой трафик, чтобы выяснить применяемую политику домена А? Это возможно благодаря тому, что сведения о сетевом расположении домена и DC постоянно обновляются.

Актуальность информации поддерживается службой NetLogon на каждом компьютере, присоединенном к домену Windows. NetLogon постоянно формирует список доступных DC и доменов (при наличии отношений доверия). На экране 1 приведен фрагмент журнала отладки NetLogon, иллюстрирующий этот непрерывный процесс. Вы можете просмотреть журнал отладки NetLogon на своем компьютере, следуя инструкциям, приведенным в статье Microsoft «Enabling debug logging for the NetLogon service» (http://support.microsoft.com/kb/109626).

Экран 1. Фрагмент журнала отладки NetLogon

На верхнем уровне проблемы безопасного канала могут быть сведены к неполадкам сетевого подключения. Если проблемы с подключением носят перемежающийся характер, то все службы работают тогда, когда работает сеть. Постоянные проблемы подключения порождают ситуацию неисправного безопасного канала, что, в свою очередь, приводит к несовпадению общего секрета между компьютером и AD, в результате чего компьютер перестает быть доверенным. Совокупный эффект заключается в том, что никто не может войти в домен и получить доступ к доменным ресурсам.

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

Выявление проблемы безопасного канала

Лучший способ обнаружить проблему безопасного канала – задействовать функцию I_NetLogonControl2. I_NetlogonControl2 – это одна из функций, используемых службой NetLogon (она есть на любом компьютере с Windows любой версии) для поддержания сведений о доступных доменах и DC.

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

NLTest.exe. Утилита NLTest.exe была выпущена в комплекте средств поддержки Windows 2000 и Windows Server 2003 и включена по умолчанию в большинство более новых версий Windows. Параметр sc_verify вызывает I_NetlogonControl2, и вам остается указать проблемный домен.

C:>nltest /sc_verify:americas Flags: b0 HAS_IP HAS_TIMESERV Trusted DC Name DD3-AM-DC-03.americas.fabrikam.com Trusted DC Connection Status Status = 0 0x0 NERR_Success Trust Verification Status = 0 0x0 NERR_Success The command completed successfully

Если проблема безопасного канала не исчезает, то есть если общий секрет на компьютере не совпадает с общим секретом в AD для этого компьютера, исправить ошибку поможет параметр sc_reset.

PowerShell. В PowerShell 2.0 добавлена команда PowerShell Test-ComputerSecureChannel, которая также вызывает I_NetLogonControl2, но обеспечивает минимум информации, возвращая ответ True, если безопасный канал домена исправен, а DC доступен, либо, в противном случае, ответ False.

PS C:> Test-ComputerSecureChannel True

Подобно NLTest.exe, команда Test-ComputerSecureChannel может применяться и для исправления ошибки с использованием ключа Repair.

WMI. С помощью класса win32_ntdomain инструментарий управления Windows (WMI) позволяет запросить все домены, о которых знает компьютер. WMI полезен в случаях, когда на тестируемом компьютере нельзя рассчитывать на средства PowerShell. Заметим, что в приведенном ниже примере (где Win32_NTDomain вызывается через команду PowerShell Get-WMIObject с использованием псевдонима GWMI) в качестве ответа возвращается только локальный домен, но может быть возвращен любой домен, связанный с локальным доменом отношениями доверия.

PS C:> gwmi win32_ntdomain ClientSiteName: TX DcSiteName: TX Description: AMERICAS DnsForestName: americas.fabrikam.com DomainControllerAddress: DomainControllerName: DD3-AM-DC-03 DomainName: AMERICAS Roles: Status: OK

Заметим, что состояние OK в этом примере соответствует ответу True или False, возвращаемому командой Test-ComputerSecureChannel, и указывает на работоспособность или неработоспособность безопасного канала.

Устранение проблемы безопасного канала

Пользователям, обращающимся в службу поддержки Microsoft, высылается дополнительный пакет сбора данных. Вместо собственной команды PowerShell Test-ComputerSecureChannel в пакете используется WMI-класс Win32_NTDomain (вызываемый из PowerShell), что позволяет запускать тест даже на более старых операционных системах, таких как Windows XP и Windows 2003. Для иллюстрации применения теста ниже приведены два примера сценариев, которые можно самостоятельно запустить в окне PowerShell, см. листинг 1 и листинг 2.

В первом примере выполняется сбор информации о безопасном канале текущего домена, а также основных сведений о лесе. На экране 2 приведены результаты.

Экран 2. Результаты работы первого сценария

Для выявления любой проблемы создается тест как сценарий PowerShell (файл. ps1), а к возвращаемому состоянию добавляется условный оператор ‘if’. Можно также указать имя домена, как показано в примере, показанном в Листинге 2.

В практике диагностики Microsoft этот сценарий превращен в простую функцию, которую можно использовать повторно.

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

Листинг 1. Сценарий проверки безопасного канала

PowerShell Get-Date >> $OutputFileName $ComputerName = Get-WmiObject -Class Win32_ComputerSystem $OutputFileName = Join-Path $Pwd.Path ($ComputerName.Name + «_Secure Channels.txt») $domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain() «This computers domain information is:» >> $OutputFileName $domain >> $OutputFileName «This computers secure channel information is:» >> $OutputFileName gwmi Win32_NTDomain >> $OutputFileName

Листинг 2. Усовершенствованный сценарий проверки

PowerShell $Domain = «americas» function SecureChannelCheck < #Function to give a simple «good» or «bad» result for secure channel health. #Accepts a flat domain name—not entire FQDN—as input. #To run as a script, not a function, just replace $DomainName with $env:userdomain. param ($DomainName) $v = «select * from win32_ntdomain where domainname = ‘» + $DomainName + «’» $v2 = get-wmiobject -query $v if ($v2.Status -eq «OK») elseif (($v2 -eq $null) -or ($v2 -ne»OK«)) > SecureChannelCheck($Domain)

Источник: www.osp.ru