Windows server 2008 r2 ошибка 2012

Ситуация: 

С недавних пор наши приложения на .net 4.5 в функционал которых, кроме прочего, входит загрузка страниц с сайтов. Перестали работать на серверах Windows Werver 2008 R2 и Windows Server 2012 R2

Ошибка

Не удалось создать защищенный канал ssl/tls
или она же на английском
The request was aborted: Could not create SSL/TLS secure channel

Причем эти же приложения работали нормально на машинах разработчиков на Windows 10.

Разбор ситуации. Что не помогло

Сразу скажу — много форумов читали, много советов перепробовали — нам
не помогли такие действия:

игры с настройкой протокола в приложении

ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(AlwaysGoodCertificate);

ServicePointManager.Expect100Continue = true;

ServicePointManager.DefaultConnectionLimit = 9999;

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

игры с переходом на более свежий фреймворк: 

пробовали и .NET 4.6.1 и .NET 4.7.2

Но попробуйте, может у вас другой случай (я думаю, в случае другой конфигурации машины — могут помочь)

Вот советы, которые нам не помогли

Disable SSL fallback and use only TLS for outbound connections in .NET? (Poodle mitigation)
https://stackoverflow.com/questions/26389899/disable-ssl-fallback-and-use-only-tls-for-outbound-connections-in-net-poodle

How to specify SSL protocol to use for WebClient class
https://stackoverflow.com/questions/30491716/how-to-specify-ssl-protocol-to-use-for-webclient-class

.Net WebClient: Could not create SSL/TLS secure channel
https://www.aspsnippets.com/Articles/Net-WebClient-Could-not-create-SSLTLS-secure-channel.aspx

Запрос был прерван: Не удалось создать защищенный канал SSL/TLS
https://answer-id.com/ru/74496884

Запрос был прерван: не удалось создать безопасный канал SSL / TLS
https://qastack.ru/programming/2859790/the-request-was-aborted-could-not-create-ssl-tls-secure-channel

Не удалось создать защищенный канал SSL/TLS только на сервере Windows Server 2012
https://coderoad.ru/59975964/%D0%9D%D0%B5-%D1%83%D0%B4%D0%B0%D0%BB%D0%BE%D1%81%D1%8C-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D1%82%D1%8C-%D0%B7%D0%B0%D1%89%D0%B8%D1%89%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9-%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB-SSL-TLS-%D1%82%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE-%D0%BD%D0%B0-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B5-Windows-Server

How to enable TLS 1.2 on the site servers and remote site systems
https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-server

How to enable TLS 1.2 on clients
https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client

Разбор ситуации 2: Варианты решения

Продолжили наши разбирательства, и, думаем, нашли причину ошибки и
2 возможных варианта решения:

Наиболее вероятная причина ошибки

Старые операционки не поддерживают новые наборы шифрования протокола TLS 1.2

Суть наших умозаключений 

похоже, что проблема в наборах шифрования (Cipher Suites)

попытался их внимательнее поразбирать с помощью статьи
https://docs.microsoft.com/en-us/answers/questions/227738/windows-server-2012-r2-tls-12-cipher-suites.html

не помогло.

Продолжили разбирательство

Вот Cipher Suites для разных операционных систем
https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel

по наводкам из статьи установил

IISCrypto
https://www.nartac.com/Products/IISCrypto

Увидел: на локальной машине есть такой набор 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

он же используется и на веб сайте с которого хотим загружать страницы

это я посмотрел через сайт
https://www.ssllabs.com/ssltest/analyze.html

Вот раздел с наборами шифрования

Cipher Suites
# TLS 1.3 (server has no preference)
TLS_AES_128_GCM_SHA256 (0x1301)   ECDH x25519 (eq. 3072 bits RSA)   FS	128
TLS_CHACHA20_POLY1305_SHA256 (0x1303)   ECDH x25519 (eq. 3072 bits RSA)   FS	256
TLS_AES_256_GCM_SHA384 (0x1302)   ECDH x25519 (eq. 3072 bits RSA)   FS	256
# TLS 1.3 (server has no preference)
TLS_AES_128_GCM_SHA256 (0x1301)   ECDH x25519 (eq. 3072 bits RSA)   FS	128
TLS_CHACHA20_POLY1305_SHA256 (0x1303)   ECDH x25519 (eq. 3072 bits RSA)   FS	256
TLS_AES_256_GCM_SHA384 (0x1302)   ECDH x25519 (eq. 3072 bits RSA)   FS	256
# TLS 1.2 (suites in server-preferred order)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH x25519 (eq. 3072 bits RSA)   FS	256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   ECDH x25519 (eq. 3072 bits RSA)   FS	256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH x25519 (eq. 3072 bits RSA)   FS	128

но, к сожалению, наборы не поддерживается в виндовс сервер 2012
https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-8-1

и тем более в Windows Server 2008
https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-7

а поддерживается только в Windows 10 (Windows Server 2016+)
https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1607

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

How to Update Your Windows Server Cipher Suite for Better Security
https://www.howtogeek.com/221080/how-to-update-your-windows-server-cipher-suite-for-better-security/

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

Вот более подробный разбор этой темы
Windows Server 2012 R2 TLS 1.2 Cipher Suites
https://docs.microsoft.com/en-us/answers/questions/227738/windows-server-2012-r2-tls-12-cipher-suites.html

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

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

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

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

Решения

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

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

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

Выбор за вами

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

Материалы по теме

Как узнать версию TLS на сайте
https://ru.wikihow.com/%D1%83%D0%B7%D0%BD%D0%B0%D1%82%D1%8C-%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8E-TLS-%D0%BD%D0%B0-%D1%81%D0%B0%D0%B9%D1%82%D0%B5

Страница для анализа SSL на нужном сайте(домене)
https://www.ssllabs.com/ssltest/analyze.html

How to Update Your Windows Server Cipher Suite for Better Security
https://www.howtogeek.com/221080/how-to-update-your-windows-server-cipher-suite-for-better-security/

Cipher Suites in TLS/SSL (Schannel SSP)
https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel

Demystifying Schannel
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/demystifying-schannel/ba-p/259233

Утро пятницы началось с жалоб некоторых пользователей на невозможность подключится к удаленному рабочему столу Windows Server 2008 R2 и Windows Server 2012 R2.

Произошла ошибка при проверке подлинности. Указанная функция не поддерживается.
Причиной ошибки может быть исправление шифрования CredSSP. Дополнительные сведения см. статье https://go.microsoft.com/fwlink/?linkid=866660

Причиной отказа в подключении послужило обновление безопасности Windows, закрывающее уязвимости в протоколе CredSSP (бюллетень CVE-2018-0886), в результате чего клиентам запрещалось подключаться к удаленным RDP серверам с непропатченой версией CredSSP. Таким образом, клиентские машины, установившие майские обновления остались не при делах.

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

В сети имеются компьютеры на старой версии Mac OS X (10.7.5), для которых не существует свежей версии RDP-клиента и после такого обновления теряется возможность работы с сервером. Вопрос безопасности соединения мобильных пользователей в таком случае решается VPN туннелем.

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

Отключение уведомления об ошибке шифрования CreedSSP на клиенте

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


REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

Если же вам удобнее использовать редактор локальных групповых политик, то запустив редактор gpedit.msc, переходим в раздел:


Конфигурация компьютера -> Административные шаблоны -> Система -> Передача учетных данных
(Computer Configuration -> Administrative Templates -> System -> Credentials Delegation)

Открываем параметр с именем «Исправление уязвимости шифрующего оракула» (Encryption Oracle Remediation), и нажимаем «Включено» («Enabled»). Уровень защиты ставим как «Оставить уязвимость» (Vulnerable).

Обновить политики на компьютере можно командой, после чего подключение по RDP должно заработать:

gpupdate /force

Установка обновления для исправления шифрования CreedSSP на сервере

Установить отсутствующие обновления безопасности на сервере можно через службу Windows Update или вручную. Чтобы не тянуть кучу лишнего, вот прямые ссылки на обновления для разных версий Windows Server:

• Windows Server 2012 R2 / Windows 8: KB4103715
• Windows Server 2008 R2 / Windows 7: KB4103712
• Windows Server 2016 / Windows 10 1607: KB4103723

Учтите, что после установки обновления сервер уйдет в перезагрузку.