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

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

Запрос был прерван: Could not create SSL/TLS secure channel.

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

private void Somewhere() {
    ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);
}

private static bool AlwaysGoodCertificate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors policyErrors) {
   return true;
}

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


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

Комментарии к вопросу (16)
Решение

Наконец-то я нашел ответ (я не указал источник, но он был получен в результате поиска);

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

// using System.Net;
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
// Use SecurityProtocolType.Ssl3 if needed for compatibility reasons

И теперь все работает идеально.


ADDENDUM

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

Комментарии (23)

Решение этой проблемы в .NET 4.5 следующее

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

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

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
Комментарии (5)

Убедитесь, что параметры servicepointmanager и сделаны до создания в HttpWebRequest есть, иначе он не будет работать.

Работает:

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

Не:

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

        ServicePointManager.Expect100Continue = true;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls
               | SecurityProtocolType.Tls11
               | SecurityProtocolType.Tls12
               | SecurityProtocolType.Ssl3;
Комментарии (4)

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

Пример того, как это настроить, находится здесь: http://support.microsoft.com/kb/901183

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

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

Комментарии (4)

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

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
new WebClient().DownloadData("https://ct.mob0.com/Styles/Fun.png");
Комментарии (3)

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

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

Также смотрите Как включить регистрацию событий Schannel.

Комментарии (2)

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

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

Комментарии (2)

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

ServicePointManager.Expect100Continue = true;
        ServicePointManager.DefaultConnectionLimit = 9999;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
Комментарии (5)

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

Комментарии (1)

В "запрос был прерван: не удалось создать защищенный протокол SSL/TLS для безопасного канала на" исключение может произойти, если сервер возвращает http 401 доступ запрещен ответ на HTTP-запрос.

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

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

System.Net Information: 0 : [9840] Connection#62912200 - Received status line: Version=1.1, StatusCode=401, StatusDescription=Unauthorized.

В моей ситуации, я был не в состоянии установить конкретное куки, что сервер ожидал, ведущим к серверу, в ответ на просьбу с 401 ошибку, которая, в свою очередь, привело к том, что "не удалось создать SSL и TLS безопасный канал" не исключение.

Комментарии (1)

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

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

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

  • Это глобальный параметр в свой AppDomain и если у вас есть одновременную работу, вы можете'т достоверно установить его к одному значению, не ваши действия, а затем установить его обратно. Другое действие может иметь место в течение этого небольшое окно и быть затронуты.
  • Правильные настройки оставить по умолчанию. Это позволяет .Чистая продолжать использовать все, что является наиболее безопасным значением по умолчанию, как время идет и обновлении базы. Установка TLS12 (что является наиболее безопасной на момент написания этой статьи) будет работать теперь *** а в 5 лет может начать вызывая загадочные проблемы.
  • Если вам действительно нужно, чтобы установить значение, вы должны рассмотреть возможность сделать это в отдельных специализированных приложений или AppDomain и найти способ соединиться между ним и свой главный бассейн. Потому что это'ы единого глобального значения, пытаясь управлять им в течение напряженного приложение бассейн приведет только к беде. Ответ: https://stackoverflow.com/a/26754917/7656 обеспечивает возможное решение с помощью пользовательской прокси. (Заметьте, я лично не реализовали его.)
Комментарии (1)

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

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

WebRequest webRequest = WebRequest.Create(@"https://myservice/path");
webRequest.ContentType = "text/html";
webRequest.Method = "POST";
string body = "...";
byte[] bytes = Encoding.ASCII.GetBytes(body);
webRequest.ContentLength = bytes.Length;
var os = webRequest.GetRequestStream();
os.Write(bytes, 0, bytes.Length);
os.Close();
webRequest.Timeout = 0; //setting the timeout to 0 causes the request to fail
WebResponse webResponse = webRequest.GetResponse(); //Exception thrown here ...
Комментарии (1)

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

    public string DownloadSite(string RefinedLink)
    {
        try
        {
            Uri address = new Uri(RefinedLink);

            ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

            System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

            using (WebClient webClient = new WebClient())
            {
                var stream = webClient.OpenRead(address);
                using (StreamReader sr = new StreamReader(stream))
                {
                    var page = sr.ReadToEnd();

                    return page;
                }
            }

        }
        catch (Exception e)
        {
            log.Error("DownloadSite - error Lin = " + RefinedLink, e);
            return null;
        }
    }
Комментарии (1)

Еще одна возможная причина запрос был прерван: не удалось создать защищенный протокол SSL/TLS для безопасного канала ошибка несоответствие между ПК клиента'ы настроены cipher_suites значения, что сервер настроен как хочет и может принять. В этом случае, когда ваш клиент отправляет список cipher_suites ценности, которые он способен принимать на начальной квитирования SSL/переговоры "по Клиент привет" сообщение, сервер видит, что ни одно из указанных значений являются допустимыми, и могут возвращать себе "Тревога" в ответ вместо того, чтобы переходить в "сервера привет" Шаг SSL-подтверждения.

Чтобы исследовать эту возможность, вы сможете скачать Майкрософт анализатор Сообщений, и использовать его, чтобы отследить согласования SSL, что происходит, когда вы попробовать и не создать https-подключение к серверу (в приложении).

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

Надеюсь, вы'll увидеть некоторые различия между двумя клиенте Привет сообщений, который позволит вам точно определить, что об отсутствии согласования SSL является причиной его сбоя. Тогда вы должны быть в состоянии сделать изменения конфигурации Windows, который позволит ему добиться успеха. IISCrypto является отличным инструментом, чтобы использовать для этого (даже для клиентских ПК, несмотря на то "ИИС" имя).

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

  • Политика\программное обеспечение\реестра HKLM\Майкрософт\криптография\настройки\протокол SSL\00010002
  • В HKLM\система\CurrentControlSet на\контроль\криптография\настройки\местные\с SSL\00010002

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

Комментарии (2)

Я имел эту проблему, потому что моя веб.конфиг был:

а не:

Комментарии (1)

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

  1. ГМК
  2. сертификаты
  3. Расширение личных
  4. выберите сертификат
  5. щелкните правой кнопкой мыши
  6. Все задачи
  7. Управление закрытыми ключами
  8. Добавить
Комментарии (0)

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

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

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

Странно, никаких других сообщений об ошибке, но "и запрос был прерван: не удалось создать защищенный протокол SSL/TLS для безопасного канала.&я пришел на эту ошибку

Комментарии (1)

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

Это может быть установлен в:

и GT; Панель управления gt; В сети Интернет-и gt; Настройки -&ГТ интернет; дополнительно

Настройки прокрутите вниз, чтобы "безопасности" и выбирать между

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

Комментарии (4)

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

Комментарии (1)

система.Чистая.Исключения webexception: запрос был прерван: не удалось создать протоколы SSL и TLS безопасный канал.

В нашем случае, мы где с помощью поставщика программного обеспечения, поэтому мы не'т иметь доступ к изменить .Net код. Видимо .Сеть 4 выиграл'т использовать TLS версии 1.2, если есть изменения.

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

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
Комментарии (2)