Error an error occurred in the secure channel support перевод

Зачастую после установки SSL-сертификатов многие пользователи сталкиваются с ошибками, которые препятствуют корректной работе защищенного протокола HTTPS.

Предлагаем разобраться со способами устранения подобных ошибок.

Что такое SSL?

SSL (Secure Socket Layer) — это интернет-протокол для создания зашифрованного соединения между пользователем и сервером, который гарантирует безопасную передачу данных.

Когда пользователь заходит на сайт, браузер запрашивает у сервера информацию о наличии сертификата. Если сертификат установлен, сервер отвечает положительно и отправляет копию SSL-сертификата браузеру. Затем браузер проверяет сертификат, название которого должно совпадать с именем сайта, срок действия сертификата и наличие корневого сертификата, выданного центром сертификации.

Причины возникновения ошибок SSL-соединения

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

Но при наличии ошибок она выглядит несколько иначе:

Существует множество причин возникновения таких ошибок. К числу основных можно отнести:

• Некорректную дату и время на устройстве (компьютер, смартфон, планшет и т.д.);
• Ненадежный SSL-сертификат;
• Брандмауэр или антивирус, блокирующие сайт;
• Включенный экспериментальный интернет-протокол QUIC;
• Отсутствие обновлений операционной системы;
• Использование SSL-сертификата устаревшей версии 3.0;
• Появление ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера.

Давайте рассмотрим каждую из них подробнее.

Проблемы с датой и временем

Если на устройстве установлены некорректные дата и время, ошибка SSL-соединения неизбежна, ведь при проверке сертификата происходит проверка срока его действия. Современные браузеры умеют определять такую ошибку самостоятельно и выводят сообщение о неправильно установленной дате или времени.

Для исправления этой ошибки достаточно установить на устройстве актуальное время. После этого необходимо перезагрузить страницу или браузер.

Ненадежный SSL-сертификат

Иногда при переходе на сайт, защищенный протоколом HTTPS, появляется ошибка «SSL-сертификат сайта не заслуживает доверия».

Одной из причин появления такой ошибки, как и в предыдущем случае, может стать неправильное время. Однако есть и вторая причина — браузеру не удается проверить цепочку доверия сертификата, потому что не хватает корневого сертификата. Для избавления от такой ошибки необходимо скачать специальный пакет GeoTrust Primary Certification Authority, содержащий корневые сертификаты. После скачивания переходим к установке. Для этого:

• Нажимаем сочетание клавиш Win+R и вводим команду certmgr.msc, жмем «Ок». В Windows откроется центр сертификатов.
• Раскрываем список «Доверенные корневые центры сертификации» слева, выбираем папку «Сертификаты», кликаем по ней правой кнопкой мышки и выбираем «Все задачи — импорт».

• Запустится мастер импорта сертификатов. Жмем «Далее».

• Нажимаем кнопку «Обзор» и указываем загруженный ранее сертификат. Нажимаем «Далее»:

• В следующем диалоговом окне указываем, что сертификаты необходимо поместить в доверенные корневые центры сертификации, и нажимаем «Далее». Импорт должен успешно завершиться.

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

Брандмауэр или антивирус, блокирующие сайт

Некоторые сайты блокируются брандмауэром Windows. Для проверки можно отключить брандмауэр и попробовать зайти на нужный сайт. Если SSL-сертификат начал работать корректно, значит дело в брандмауэре. В браузере Internet Explorer вы можете внести некорректно работающий сайт в список надежных и проблема исчезнет. Однако таким образом вы снизите безопасность своего устройства, так как содержимое сайта может быть небезопасным, а контроль сайта теперь отключен.

Также SSL может блокировать антивирусная программа. Попробуйте отключить в антивирусе проверку протоколов SSL и HTTPS и зайти на сайт. При необходимости добавьте сайт в список исключений антивируса.

Включенный экспериментальный протокол QUIC

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

Показываем как отключить QUIC на примере браузера Google Chrome:

• Откройте браузер и введите команду chrome://flags/#enable-quic;
• В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

• После этого просто перезапустите браузер.

Этот способ работает и в Windows и в Mac OS.

Отсутствие обновлений операционной системы

Проблемы с SSL-сертификатами могут возникать и из-за того, что на вашей операционной системе давно не устанавливались обновлений. Особенно это касается устаревших версий Windows (7, Vista, XP и более ранние). Установите последние обновления и проверьте работу SSL.

Использование SSL-сертификата версии 3.0

Некоторые сайты используют устаревший SSL-протокол версии 3.0, который не поддерживают браузеры. По крайней мере, по умолчанию. Чтобы браузер поддерживал устаревший SSL необходимо сделать следующее (на примере браузера Google Chrome):

• Откройте браузер и перейдите в раздел «Настройки».
• Прокрутите страницу настроек вниз и нажмите «Дополнительные».
• В разделе «Система» найдите параметр «Настройки прокси-сервера» и кликните на него.

• Откроется окно. Перейдите на вкладку «Дополнительно».
• В этой вкладке вы увидите чекбокс «SSL 3.0».

• Поставьте галочку в чекбоксе, нажмите кнопку «Ок» и перезагрузите браузер.

Ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера

В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:

• Неправильное имя FQDN (полное имя домена) в качестве Common Name (в некоторых панелях управления это поле может также называться Host Name или Domain Name). В этом поле должно быть указано полное доменное имя вида domain.com или subdomain.domain.com (для субдоменов). Имя домена указывается без https://. В качестве данного значения нельзя использовать интранет-имена (text.local). В запросе для wildcard-сертификатов доменное имя необходимо указывать как *.domain.com.
• В CSR или пароле есть не латинские буквы и цифры. В CSR поддерживаются только латинские буквы и цифры – спецсимволы использовать запрещено. Это правило распространяется и на пароли для пары CSR/RSA: они не должны содержать спецсимволов.
• Неверно указан код страны. Код страны должен быть двухбуквенным ISO 3166-1 кодом (к примеру, RU, US и т.д.). Он указывается в виде двух заглавных букв.
• В управляющей строке не хватает символов. CSR-запрос должен начинаться с управляющей строки ——BEGIN CERTIFICATE REQUEST—— и заканчиваться управляющей строкой ——END CERTIFICATE REQUEST——. С каждой стороны этих строк должно быть по 5 дефисов.
• В конце или начале строки CSR есть пробелы. Пробелы на концах строк в CSR не допускаются.
• Длина ключа меньше 2048 бит. Длина ключа должна быть не менее 2048 бит.
• В CRS-коде для сертификата для одного доменного имени есть SAN-имя. В CSR-коде для сертификата, предназначенного защитить одно доменное имя, не должно быть SAN (Subject Alternative Names). SAN-имена указываются для мультидоменных (UCC) сертификатов.
• При перевыпуске или продлении сертификата изменилось поле Common Name. Это поле не должно меняться.

Модератор: immortal

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

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

• 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.

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