Excel datasource error запрос был прерван не удалось создать защищенный канал ssl tls

Поизучали возможность обновления этих пакетов

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

вроде бы неудача.
но, в форумах часто проскальзывает что «хром работает, а .NET Framework приложения — нет». Причина в том, что баузер хром использует свои пакеты шифрования а не полагается ОС.
Мы зацепились за эту идею.

В одном из проектов мы использовали компонент — внедренный браузер на Chromium

пакет в Nuget: CefSharp.Winforms, CefSharp.Common.

Попробовали загрузить страницу через этот механизм — работает!

Решения

то есть у вас есть 2 варианта решения

1. переход на свежий Windows Server 2016

2. использование пакета CefSharp но предупреждаю, он увеличивает размер приложения (в нашем случае на 100+ МБ)

Если нужны будут детальные инструкции по CefSharp -напишите в комментах: сделаю отдельную статью.

Источник

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

Мы не можем подключиться к серверу HTTPS с помощью WebRequest из-за этого сообщения об ошибке:

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

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

Проблема в том, что сервер никогда не проверяет сертификат и не выполняет вышеуказанную ошибку. Кто-нибудь знает, что мне делать?

Я должен упомянуть, что несколько лет назад мы с коллегой проводили тесты, и он отлично работал с чем-то похожим на то, что я написал выше. Единственное “основное отличие”, которое мы обнаружили, это то, что я использую Windows 7, и он использовал Windows XP. Это что-то меняет?

Я, наконец, нашел ответ (я не заметил свой источник, но это был поиск);

Хотя код работает в Windows XP, в Windows 7, вы должны добавить это в начале:

И теперь он работает отлично.

ДОПОЛНЕНИЕ

Как упоминал Робин Франс; если вы получаете эту проблему при настройке PayPal, обратите внимание, что они не будут поддерживать SSL3, начиная с 3 декабря 2018 года. Вам нужно будет использовать TLS. Здесь страница Paypal об этом.

Решение этого в.NET 4.5 является

Если у вас нет.NET 4.5, используйте

Убедитесь, что настройки ServicePointManager заданы до создания HttpWebRequest, иначе он не будет работать.

Проблема, с которой вы сталкиваетесь, заключается в том, что пользователь aspNet не имеет доступа к сертификату. Вы должны предоставить доступ, используя winhttpcertcfg.exe

На шаге 2 в дополнительной информации

EDIT: в более поздних версиях IIS эта функция встроена в инструмент диспетчера сертификатов – и к ней можно получить доступ, щелкнув правой кнопкой мыши по сертификату и используя опцию для управления секретными ключами. Подробнее здесь: https://serverfault.com/questions/131046/how-to-grant-iis-7-5-access-to-a-certificate-in-certificate-store/132791#132791

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

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

У меня была эта проблема с попыткой нажать https://ct.mob0.com/Styles/Fun.png, который представляет собой изображение, распространяемое CloudFlare на нем CDN, которое поддерживает сумасшедшие вещи, такие как SPDY и странные перенаправления сертификатов SSL.

Вместо того, чтобы указывать Ssl3, как в ответе Саймонса, я смог исправить его, перейдя к Tls12 следующим образом:

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

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

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

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

“Запрос был прерван: не удалось создать безопасный канал SSL/TLS”. Исключение может возникнуть, если сервер возвращает ответ HTTP Неавторизованный запрос HTTP.

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

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

В моей ситуации я не смог установить конкретный файл cookie, ожидаемый сервером, что привело к тому, что сервер ответил на запрос с ошибкой 401, что в свою очередь привело к созданию “Не удалось создать безопасный канал SSL/TLS”, исключение.

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

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

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

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

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

Если вы установите значение WebRequest.Timeout на 0 , это будет исключение. Ниже приведен код, который у меня был… (За исключением жестко закодированного 0 для значения таймаута у меня был параметр, который был непреднамеренно установлен на 0 ).

Этот работает для меня в веб-клиенте MVC

Другая возможная причина The request was aborted: Could not create SSL/TLS secure channel ошибку The request was aborted: Could not create SSL/TLS secure channel – это несоответствие между вашими значениями cipher_suites вашего клиентского ПК и значениями, которые сервер настроил как желающий и способный принять. В этом случае, когда ваш клиент отправляет список значений cipher_suites, которые он может принять в своем первоначальном сообщении об установлении связи/согласовании SSL “Клиент Hello”, сервер видит, что ни одно из предоставленных значений не является приемлемым и может возвращать “Предупреждение” “вместо того, чтобы перейти к шагу” Приветствие Сервера “SSL-квитирования.

Чтобы изучить эту возможность, вы можете загрузить Microsoft Message Analyzer и использовать его для запуска трассировки в согласовании SSL, возникающего при попытке установить HTTPS-соединение с сервером (в вашем приложении С#).

Если вы можете сделать успешное соединение HTTPS из другой среды (например, упомянутой вами машины Windows XP, или, возможно, нажав URL-адрес HTTPS в браузере, отличном от Microsoft, который не использует настройки набора шифров ОС, например Chrome или Firefox), запустите еще одну трассировку анализатора сообщений в этой среде, чтобы зафиксировать, что происходит, когда переговоры по SSL успешно завершены.

Надеемся, вы увидите некоторую разницу между двумя сообщениями Hello Hello, которые позволят вам точно определить, что из-за неудачного согласования SSL приводит к сбою. Затем вы сможете внести изменения в конфигурацию Windows, что позволит ей добиться успеха. IISCrypto – отличный инструмент для этого (даже для клиентских компьютеров, несмотря на имя “IIS”).

Следующие два ключа реестра Windows управляют значениями cipher_suites, которые ваш компьютер будет использовать:

Здесь полная запись того, как я исследовал и решил экземпляр этого многообразия. Could not create SSL/TLS secure channel проблему Could not create SSL/TLS secure channel : http://blog.jonschneider.com/2016/08/fix-ssl-handshaking-error-in -windows.html

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

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

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

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

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

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

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

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

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

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

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

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

Если вы запускаете свой код из Visual Studio, попробуйте запустить Visual Studio в качестве администратора. Исправлена ошибка.

У меня была такая же проблема, и я нашел, что этот ответ работал правильно для меня. Ключ – 3072. Эта ссылка содержит сведения об исправлении 3072.

В моем случае два канала потребовали исправления:

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

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

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

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

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

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

Проблема для меня заключалась в том, что я пытался развернуть IIS в качестве веб-службы, я установил сертификат на сервере, но у пользователя, который запускает IIS, не было правильных разрешений на сертификат.

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

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

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

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

“ClientMinKeyBitLength” = DWORD: 00000200

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

Список Windows HotFix:

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

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

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

Есть три исправления.

2) Добавьте настройку в файл app.config/web.config.

3) Добавьте параметр реестра, который уже упоминался в другом ответе.

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

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

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

Вместо инициализации моего X509Certifiacte2 вот так:

Я сделал это так:

Обратите внимание на X509KeyStorageFlags.Exportable !!

Я не изменил остальную часть кода (сам WebRequest ):

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

Вы можете попробовать установить демонстрационный сертификат (некоторые провайдеры ssl предлагают их бесплатно в течение месяца), чтобы убедиться, что проблема связана с действительностью сертификата или нет.

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

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

Источник

Adblock
detector

Проблема

Ошибка ‘Запрос был прерван: Не удалось создать защищенный канал SSL/TLS’ или что то же самое ‘The request was aborted: Could not create SSL/TLS secure channel’ может возникнуть в обновляторе при операциях скачивания, например, исправлений (патчей) к конфигурациям с сайта 1С.

Если эта ошибка возникает изредка и не влияет на общий ход операции (так как обновлятор делает 3 попытки с паузой при неудачном скачивании), то делать с этим ничего не нужно. Тут причина скорее во временных сбоях при работе сети или самого сервиса 1С.

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

Он требуется обновлятору при подключении, например, к сервисам 1С. А так как обновлятор написан на .Net Framework, то он опирается во многих своих возможностях на библиотеки операционной системы (в случае c TLS речь идёт о библиотеке schannel.dll).

Windows 7 и Windows 2008 R2

1. Для этих ОС, прежде всего, вам нужно установить Service Pack 1, если он у вас ещё не установлен.

2. Далее нужно установить KB3140245.

3. После этого KB3020369.

4. И, наконец, KB3172605.

5. После этого перезагрузите сервер, чтобы изменения вступили в силу.

Windows RT 8.1, Windows 8.1, Windows Server 2012 R2

1. Для этих ОС нужно установить KB2919355

2. После этого перезагрузите сервер, чтобы изменения вступили в силу.

Другая ОС

Если вы столкнулись с этой ошибкой на ОС, отличной от описанных выше, пожалуйста напишите мне на helpme1c.box@gmail.com и я постараюсь совместно с вами подготовить такую же подробную инструкцию по точечной установке только необходимых обновлений для вашей ОС.

Проблема с корневыми сертификатами в ОС

Ошибка с созданием защищенного канала может быть также связана с тем, что в ОС не обновлены корневые сертификаты.

Подробнее об этом здесь: ссылка.