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

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

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

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

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

ДОБАВЛЕНИЕ

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

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

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

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Убедитесь, что настройки 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;

У меня была эта проблема при попытке нажать 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");

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

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

РЕДАКТИРОВАТЬ: в более поздних версиях 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.

См. Также Как включить ведение журнала событий Schannel.

Одна из основных причин этой проблемы - активная версия .NET Framework. Версия среды выполнения .NET framework влияет на то, какие протоколы безопасности включены по умолчанию.

• На сайтах ASP.NET версия среды выполнения фреймворка часто указывается в web.config. (см. ниже)
• В других приложениях версия среды выполнения - это обычно версия, для которой был создан проект, независимо от того, выполняется ли он на компьютере с более новой версией .NET.

Похоже, что нет какой-либо авторитетной документации о том, как это конкретно работает в разных версиях, но кажется, что значения по умолчанию определены более или менее следующим образом:

Для более старых версий ваш пробег может несколько отличаться в зависимости от того, какие среды выполнения .NET установлены в системе. Например, может возникнуть ситуация, когда вы используете очень старую структуру и TLS 1.0 не поддерживается, или использование 4.6.x и TLS 1.3 не поддерживается.

документация Microsoft настоятельно рекомендует использовать 4.7+ и систему значения по умолчанию:

Мы рекомендуем вам:

• Настройте таргетинг на .NET Framework 4.7 или более поздние версии в своих приложениях. Установите целевой .NET Framework 4.7.1 или более поздние версии в своих приложениях WCF.
• Не указывайте версию TLS. Настройте свой код, чтобы ОС определяла версию TLS.
• Выполните тщательный аудит кода, чтобы убедиться, что вы не указываете версию TLS или SSL.

Для сайтов ASP.NET: проверьте версию targetFramework в вашем элементе <httpRuntime>, поскольку он (если он есть) определяет, какая среда выполнения фактически используется вашим сайтом:

<httpRuntime targetFramework="4.5" />

Лучше:

<httpRuntime targetFramework="4.7" />

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

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

Подход с настройкой

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Кажется, все в порядке, потому что Tls1.2 - это последняя версия защищенного протокола. Но я решил посмотреть глубже и ответить, действительно ли нам нужно это жестко кодировать.

Технические характеристики: Windows Server 2012R2 x64.

Из Интернета сообщается, что .NetFramework 4.6+ по умолчанию должен использовать Tls1.2. Но когда я обновил свой проект до 4.6, ничего не произошло. Я нашел некоторую информацию, которая говорит, что мне нужно вручную внести некоторые изменения, чтобы включить Tls1.2 по умолчанию.

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

Но предлагаемое обновление Windows не работает для версии R2

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

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Это то, что я искал. Но все же я не могу ответить на вопрос, почему NetFramework 4.6+ не устанавливает это ... значение протокола автоматически?

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

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

Запрос был прерван: не удалось создать исключение безопасного канала SSL / TLS, если сервер возвращает ответ HTTP 401 Unauthorized на запрос HTTP.

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

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

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

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

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

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

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

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

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

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

• HKLM \ SOFTWARE \ Policies \ Microsoft \ Cryptography \ Configuration \ SSL \ 00010002
• HKLM \ SYSTEM \ CurrentControlSet \ Control \ Cryptography \ Configuration \ Local \ SSL \ 00010002

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

Это работает для меня в веб-клиенте 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;
    }
}

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

<httpRuntime targetFramework="4.5.2" />

и не:

<httpRuntime targetFramework="4.6.1" />

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

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

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

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

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

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

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

• Это глобальный параметр в вашем домене приложения, и если у вас есть одновременные действия, вы не можете надежно установить для него одно значение, выполнить свое действие, а затем вернуть его обратно. Во время этого маленького окна может произойти другое действие, на которое может повлиять.
• Правильная настройка - оставить значение по умолчанию. Это позволяет .NET продолжать использовать наиболее безопасное значение по умолчанию с течением времени и обновлением фреймворков. Установка TLS12 (который является наиболее безопасным на момент написания этой статьи) будет работать сейчас, но через 5 лет может начать вызывать загадочные проблемы.
• Если вам действительно нужно установить значение, вам следует подумать о том, чтобы сделать это в отдельном специализированном приложении или домене приложения и найти способ обмена данными между ним и вашим основным пулом. Поскольку это единое глобальное значение, попытка управлять им в загруженном пуле приложений приведет только к проблемам. Этот ответ: https://stackoverflow.com/a/26754917/7656 предоставляет возможное решение посредством настраиваемого прокси-сервера. . (Обратите внимание, что я лично не реализовал это.)

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

Если вы установите значение WebRequest.Timeout на 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. ммс
2. сертификаты
3. Развернуть до личного
4. выберите сертификат
5. щелкните правой кнопкой мыши
6. Все задачи
7. Управляйте приватными ключами
8. Добавлять

Это помогло мне:

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

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

Когда я создал новый проект с .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

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

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

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

XmlReader r = XmlReader.Create(url);
SyndicationFeed albums = SyndicationFeed.Load(r);

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

https://www.fbi.gov/feeds/fbi-in-the-news/atom.xml
https://www.wired.com/feed/category/gear/latest/rss

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

В нашем случае мы использовали поставщика программного обеспечения, поэтому у нас не было доступа для изменения кода .NET. Очевидно, .NET 4 не будет использовать TLS v 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

Ни один из ответов не помог мне.

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

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

   var certificate = new X509Certificate2(bytes, pass);

У меня так получилось:

   var certificate = new X509Certificate2(bytes, pass, X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable);

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

Остальную часть кода (сам WebRequest) я не менял:

// I'm not even sure the first two lines are necessary:
ServicePointManager.Expect100Continue = true; 
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

request = (HttpWebRequest)WebRequest.Create(string.Format("https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", server));
request.Method = "GET";
request.Referer = string.Format("https://hercules.sii.cl/cgi_AUT2000/autInicio.cgi?referencia=https://{0}.sii.cl/cvc_cgi/dte/of_solicita_folios", servidor);
request.UserAgent = "Mozilla/4.0";
request.ClientCertificates.Add(certificate);
request.CookieContainer = new CookieContainer();

using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
    // etc...
}

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

Это исправлено для меня, добавьте сетевую службу в разрешения. Щелкните сертификат правой кнопкой мыши> Все задачи> Управление закрытыми ключами ...> Добавить ...> Добавить «Сетевая служба».

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

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

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

Как предоставить ASP.NET доступ к закрытому ключу в сертификате в хранилище сертификатов?

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

https://support.microsoft.com/en-us/help/4458166/applications-that-rely-on-tls-1-2-strong-encryption-experience-connect

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

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

1) Исправьте ОС с помощью соответствующего обновления: http://www.catalog.update.microsoft.com/Search.aspx?q=kb4458166

2) Добавьте параметр в файл app.config / web.config.

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

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

ни один из этого ответа не работает для меня, google chrome и почтальон работают и рукопожатие сервера, но т.е. и .net не работают. в Google Chrome на вкладке безопасности> соединение показывает, что зашифровано и аутентифицировано с использованием набора шифров ECDHE_RSA с P-256 и AES_256_GCM для установления связи с сервером.

Я устанавливаю IIS Crypto и в списке наборов шифров на сервере Windows 2012 R2 не могу найти < strong> ECDHE_RSA с набором шифров P-256 и AES_256_GCM. затем я обновляю окна до последней версии, но проблема не решается. наконец, после поисков я понял, что Windows Server 2012 R2 не поддерживает GSM правильно и обновил мой сервер до Windows Server 2016, и моя проблема решена.

Наконец-то нашел для меня решение.

Попробуйте добавить следующую строку перед вызовом https url (для .Net framework 4.5):

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

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

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

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

The following fatal alert was generated: 40. The internal error state is 808.

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

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

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ KeyExchangeAlgorithms \ Diffie-Hellman]

«ClientMinKeyBitLength» = двойное слово: 00000200

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

Перечислите свой Windows HotFix:

wmic qfe list

Тема решения:

https://communities.vmware.com/message/2604912#2604912

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

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

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

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

У меня возникла проблема с загрузкой видео в Wistia через приложение командной строки. Наш системный администратор решил проблему, включив дополнительные комплекты шифров с использованием IIScrypto, которые были указаны в результатах сканирования SSL-лабораторий для upload.wistia.com.

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 бит FS 128 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 бит FS 256

Для пользователей SOAP / WCF эта ошибка также может возникать, когда сервер отклоняет вашу конфигурацию WS-Security. Информация об ошибке, которую получает клиент, очень расплывчата, но администратор сервера, вероятно, сможет определить причину.

Как только пример этого находится в профиле UsernameToken, где сообщение считается просроченным к <wsu:Created> времени, не является допустимой датой и временем ISO 8601 либо из-за неправильного форматирования, не из-за UTC, либо из-за несоответствия времени сервера.

<wsse:UsernameToken wsu:Id="Example-1">
   <wsse:Username> ... </wsse:Username>
   <wsse:Password Type="..."> ... </wsse:Password>
   <wsse:Nonce EncodingType="..."> ... </wsse:Nonce>
   <wsu:Created>2021-01-31T19:00:00.0000000Z</wsu:Created>
</wsse:UsernameToken>

По умолчанию .NET ServicePointManager.SecurityProtocol использует SSLv3 и TLS. Если вы обращаетесь к серверу Apache, существует переменная конфигурации с именем SSLProtocol, которая по умолчанию имеет значение TLSv1.2. Вы можете настроить ServicePointManager.SecurityProtocol на использование соответствующего протокола, поддерживаемого вашим веб-сервером, или изменить конфигурацию Apache, чтобы разрешить использование всех протоколов, подобных этому _ 4_ all.

Недавно я столкнулся с той же проблемой. Моя среда работает под .NET 4.6.1 с VB.NET. Вот как я это исправил:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3
ServicePointManager.ServerCertificateValidationCallback = New RemoteCertificateValidationCallback(AddressOf util.ValidateServerCertificate)

а функция util.ValidateServerCertificate:

Public Function ValidateServerCertificate(ByVal sender As Object, ByVal certificate As X509Certificate, ByVal chain As X509Chain, ByVal sslPolicyErrors As SslPolicyErrors) As Boolean
    Return True
End Function

Если вы не хотите, не можете легко или не можете быстро исправить свой код, вместо этого вы можете принудительно использовать TLS 1.2 своим кодом .NET в платформе.

Это не мое приложение, но оно помогло исправить наше старое приложение .NET 4.5 (работающее на Server 2008r2), чтобы оно снова работало со шлюзом Paypal Payflow. Должно быть, они начали принудительное подключение к TLS 1.2 на обратных вызовах шлюза потока платежей между 25.06.18 и 08.07.18.

Подробности: https://github.com/TheLevelUp/pos-tls-patcher Загрузить : https://github.com/TheLevelUp/pos-tls-patcher/releases

У меня был сертификат в магазине и в досье. Я попытался подключиться к файлу и получил это сообщение об ошибке. Когда я использовал тот, что был в магазине, он работал. Я предполагаю, что какой-то конфликт возник в результате наличия сертификата, когда я хотел использовать тот, который находится в файле. (Другой сервис на той же машине использовал сертификат в магазине, и я разработал другой сервис, используя сертификат в файле. Работал как шарм на dev до тестирования).

Я получаю ту же ошибку в приложении .NET 4.5.2 Winform на Windows 2008 Server.

Я попробовал следующее исправление:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls1|SecurityProtocolType.Tls11| SecurityProtocolType.Tls12;

Но это не сработало, и количество повторений ошибки по-прежнему сохранялось.

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

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

Удаление этого параметра из реестра помогло мне в Windows Server 2012 [HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ KeyExchangAlgorithms

В большинстве ответов выше упоминаются алгоритмы сеанса или алгоритмы обмена ключами.

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

Я понял это, добавив раздел в конфигурацию моего приложения.

<system.diagnostics>
    <trace autoflush="true" />
    <sources>
        <source name="System.Net">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
        <source name="System.Net.Sockets">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
        <source name="System.Net.Cache">
            <listeners>
                <add name="System.Net" />
            </listeners>
        </source>
    </sources>
    <sharedListeners>
        <add
            name="System.Net"
            type="System.Diagnostics.TextWriterTraceListener"
            initializeData="System.Net.trace.log"
        />
    </sharedListeners>
    <switches>
        <add name="System.Net" value="Verbose" />
        <add name="System.Net.Sockets" value="Verbose" />
        <add name="System.Net.Cache" value="Verbose" />
    </switches>
</system.diagnostics>

А затем ошибка в журнале привела меня к этому решению