Регистрация на облачном сервере ошибка aborted

Ситуация: 

С недавних пор наши приложения на .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.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

When using a .NET application that communicates with a web server, you may encounter the following error.

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

This exception message typically indicates that a secure channel could not be created due to the client application failing to specify a cryptographic protocol that is supported by the server.

If you are dealing with a .NET application for which you do not have access to the source code in order to recompile it, you can usually resolve the problem with a simple configuration file change instead.

In this post, I explain how to update the configuration of the application to resolve this particular issue.

Issue background

The ‘request was aborted’ error described above is an exception that can be thrown by methods of the WebRequest and WebClient classes. For example, the DownloadFileAsync method.

As time goes on, this issue is more likely to crop up, as an increasing number of servers remove support for the older TLS 1.0 and TLS 1.1 protocols. At the time of writing, TLS 1.2 and TLS 1.3 are the current standards for secure network communications.

If you come across this issue, it will usually be a .NET Framework application that is raising the error, as opposed to .NET Core. By default, older .NET Framework versions do not specify that more modern versions of cryptographic protocols such as TLS 1.2 and TLS 1.3 should be used.

Before showing you the configuration file fix, let me briefly make you aware of two other possible ways of correcting the issue if you happen to own the affected application.

.NET Framework upgrade

The problem is addressed in newer versions of the .NET Framework, without requiring any code changes. For example, if you are using .NET 4.7 or greater, your application will automatically select the most secure protocol by querying the operating system before a web request is made.

If you’re able to update the .NET Framework version to v4.7 or greater, then aside from deploying a new version of the application, you’ve nothing else to do.

Code changes

If you have access to the source code for the application and for some reason you cannot upgrade the .NET Framework version, it is possible to manually specify the cryptographic protocols to use, as per the following code.

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

Note that ServicePointManager requires a using statement for the System.Net namespace.

The code that sets the SecurityProtocol should be called soon after your application has started and before any web requests are attempted. Usually, this would be in the Main method of your Program class, or in a method that gets called shortly after application startup to configure the application.

Note that if one or more of the specified TLS protocols are not supported, the code will throw an exception. For example, when running on an old operating system such as Windows XP.

The above code will compile for projects that are targeting .NET 4.5 or greater.

If your project is targeting an older .NET Framework version such as 4.0, you will need to specify numeric values for TLS versions that do not exist in the targeted .NET version libraries, as follows.

ServicePointManager.SecurityProtocol = 
    (SecurityProtocolType)3072 | // TLS 1.2
    (SecurityProtocolType)768  | // TLS 1.1
    (SecurityProtocolType)192;   // TLS 1.0

Note that in .NET 4.0 SecurityProtocolType.Tls (TLS 1.0) is the newest available protocol. For .NET 4.0 the above code could be changed to specify Tls instead of 192 and it would still compile.

It is important to bear in mind that even though the above code compiles in .NET 4.0, it will only work on a machine that has .NET 4.5 or greater installed on it.

One of the problems with the above code is that it ties the application down to using only the specified security protocols, thereby preventing the application from using another protocol such as TLS 1.3 in the future. However, this is manageable if you have access to the source code and are able to redeploy the application later down the line.

In the next section, I’ll cover a non-intrusive way of correcting the issue which doesn’t involve changing code and recompiling/reinstalling the software.

Configuration file

Sometimes it isn’t possible (or practical) to change and redeploy the affected application. Despite this, the issue can be fixed in most cases with a simple configuration file update.

Note that this solution will only work on .NET 4.5+ applications running on Windows 8+ devices.

Most .NET Framework applications are deployed with an XML configuration (app.config) file that can be used to configure many different aspects of how the application behaves at runtime.

The configuration file is always named after the main application executable file with a ‘.config’ extension and should exist in the same directory as said executable. For example, an application with a main executable file named ‘MyApp.exe’ will have a corresponding configuration file named ‘MyApp.exe.config’.

Suppose the application you are using doesn’t have a configuration file already. In that case, you can create one according to the naming convention specified above i.e. APP_NAME.exe.config and then paste in the following as its contents.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/>
  </runtime>
</configuration>

If the application already has a configuration file it should have a ‘configuration’ element in it and may already contain a ‘runtime’ element (if it doesn’t then create the appropriate opening and closing tags for the element). Add the self-closing ‘AppContextSwitchOverrides’ element as per the above example and save the file.

Restart the application and you should now find that the ‘request was aborted’ error is no longer occurring.

Summary

In this post, I have documented how to fix the ‘request was aborted’ error that you may encounter when running applications that are targeting older versions of the .NET Framework.

I explained the background of the issue and how it can be resolved if you have access to the source code.

I then demonstrated how to resolve the problem in a non-invasive way that doesn’t require recompilation and reinstallation of the affected application by making a simple configuration change.

«1С-Битрикс: Управление сайтом» — одна из самых популярных коммерческих CMS. Как и в случае с любой другой CMS, при работе с Битриксом возникают разные ошибки, мешающие нормальной работе сайта. Выявить их можно с помощью встроенного функционала проверки системы в панели администратора Битрикс.

Чтобы запустить проверку системы, перейдите в панель администратора по ссылке https://example.com/bitrix/admin (замените example.com на ваш домен), введите логин и пароль учетной записи администратора сайта, перейдите в Настройки — Инструменты — Проверка системы и нажмите на кнопку Начать тестирование. Дождитесь окончания проверки. В форме Проверка системы могут быть ошибки, которые, на первый взгляд, не влияют на работу сайта, однако требуют внимания владельца или системного администратора сайта.

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

Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт

Такая ошибка в большинстве случаев означает некорректное подключение к базе данных. В первую очередь проверьте, работает ли СУБД, введя следующую команду в терминал:

# systemctl status mysql

Если СУБД работает, проверьте файлы, расположенные в /home/bitrix/www/bitrix/.settings.php и /home/bitrix/www/bitrix/php_interface/dbconn.php (при необходимости замените /home/bitrix/www на корневую директорию вашего проекта, далее в статье будут использованы относительные пути вида /bitrix/php_interface/dbconn.php). В этих файлах указываются доступы для подключения к базе данных сайта.

Для файла .settings.php

'host' => 'localhost',
'database' => 'database_name',
'login' => 'user_name',
'password' => 'secret_password',

Для файла dbconn.php

$DBHost = "localhost";
$DBLogin = 'user_name';
$DBPassword = 'secret_password’;
$DBName = "database_name";

Проверьте корректность указанных данных:

• хост базы данных (должен быть localhost, если СУБД установлена локально),
• название базы данных (замените в обоих файлах database_name на название своей базы данных),
• имя пользователя базы данных (замените user_name на имя своего пользователя базы данных)
• и пароль пользователя базы данных (замените secret_password на пароль пользователя вашей базы данных).

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

«Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы 

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

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

Однако такой способ срабатывает не всегда. Если в файле /bitrix/php_interface/dbconn.php есть строка define('BX_CRONTAB_SUPPORT', true); и в cron есть задание на ежеминутный запуск скрипта /var/www/bitrix/modules/main/tools/cron_events.php, попробуйте следующее решение.

Отключим выполнение агентов на хитах, для этого в панели администратора Битрикс переходим в Настройки — Инструменты — Командная PHP-строка, вводим следующую команду и нажимаем Выполнить:

COption::SetOptionString("main", "agents_use_crontab", "N"); 
echo COption::GetOptionString("main", "agents_use_crontab", "N"); 
COption::SetOptionString("main", "check_agents", "N"); 
echo COption::GetOptionString("main", "check_agents", "Y");

Результат выполнения PHP-команды должен быть «NN».

Далее в файле /bitrix/php_interface/dbconn.php закомментируем следующие строки (добавьте перед строками знак #):

define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);

После чего в этот же файл dbconn.php добавьте строки:

if(!(defined("CHK_EVENT") && CHK_EVENT===true))
define("BX_CRONTAB_SUPPORT", true);

Далее необходимо из учетной записи владельца сайта (если вы работаете в консоли сервера из-под учетной записи root, что не рекомендуется, после создания файла измените владельца файла с помощью команды chown) создать новый файл cron_events.php в директории /bitrix/php_interface/ и добавить в него следующий код:

<?php
$_SERVER["DOCUMENT_ROOT"] = realpath(dirname(__FILE__)."/../..");
$DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"];
define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS",true);
define('BX_NO_ACCELERATOR_RESET', true);
define('CHK_EVENT', true);
define('BX_WITH_ON_AFTER_EPILOG', true);
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
@set_time_limit(0);
@ignore_user_abort(true);
CAgent::CheckAgents();
define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);
CEvent::CheckEvents();
if(CModule::IncludeModule('sender'))
{
    \Bitrix\Sender\MailingManager::checkPeriod(false);
    \Bitrix\Sender\MailingManager::checkSend();
}
require($_SERVER['DOCUMENT_ROOT']."/bitrix/modules/main/tools/backup.php");
CMain::FinalActions();
?>

После того, как файл создан с нужными правами, добавляем его в cron. Обязательно делаем это для владельца сайта, так как задания cron для пользователя root могут стать серьезной угрозой безопасности для сайта и сервера. Выполним следующую команду (в нашем случае владелец сайта — bitrix, замените это значение на имя пользователя своего сайта при необходимости):

# crontab -ubitrix -e

Откроется файл с заданиями crontab пользователя сайта. Вставьте следующую строку:

*/1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php

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

Путь /usr/bin/php — путь для PHP, оставьте его таким же, если у вас на сервере нет альтернативных версий PHP. Если вы используете панель ISPmanager, возможно, ваш сайт работает на альтернативной версии PHP. Проверить версию можно в панели ISPmanager, а узнать корректный путь для PHP — с помощью команды whereis php в консоли сервера. Например, для альтернативной версии PHP 8.1 путь может быть таким: /opt/php81/bin/php. Замените путь к скрипту /home/bitrix/www/bitrix/php_interface/cron_events.php на свой в случае необходимости.

Если в cron есть запись для выполнения скрипта /var/www/bitrix/modules/main/tools/cron_events.php — ее лучше закомментировать.

Ошибка работы с сокетами при проверке системы

При проверке системы в панели администратора Битрикс может возникнуть ошибка «Работа с сокетами. Ошибка! Не работает».

Также из-за ошибки работы с сокетами другие тесты проводятся некорректно, выдавая ошибку «Замечание. Не удалось проверить из-за ошибки в работе с сокетами».

В большинстве случаев такая ошибка появляется после переноса проекта на новый сервер или при развертывании проекта на локальном компьютере для тестирования. Возникает данная ошибка из-за того, что IP-адрес сервера отличается от IP-адреса, указанного в А-записях домена на серверах DNS. Если вы переносите проект на новый сервер, необходимо указать IP-адрес нового сервера в А-записях и дождаться глобального обновления DNS.

Если А-записи указаны корректно, возможно в файле /etc/hosts на сервере указан неверный IP для вашего домена. Проверьте файл и укажите правильное значение:

1.2.3.4 example.com

Замените 1.2.3.4 на IP адрес вашего сервера, а example.com на доменное имя вашего сайта.

Бывает, что на сервере может возникнуть проблема с корневыми сертификатами. Можно попробовать обновить их. В CentOS 7 ведите в консоли сервера:

# yum install ca-certificates -y
# update-ca-trust

Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы

Из описания ошибки понятно, что она означает. В большинстве случаев для устранения данной ошибки требуется вмешательство системного администратора или технической поддержки Битрикс. Проблем, из-за которых почта не работает, много. Они могут быть на стороне сервера, в настройках проекта, либо из-за некорректно работающих модулей отправки почты.

Битрикс использует стандартную функцию php mail() для отправки почты, однако нередко используются другие способы, например, через внешний почтовый сервер. Для проверки работы php mail() можно воспользоваться инструкцией из ответов на часто задаваемые вопросы на форуме Битрикс. 

Также можно выполнить проверку с помощью следующего кода PHP (вставьте его в командную строку PHP в панели администратора Битрикс):

$mail="test@testmail.ru"; // укажите ваш почтовый ящик, на который нужно отправить тестовое письмо
$subject ="test" ; // укажите любую тему письма
$text= "test message"; // укажите любой текст письма
if( mail($mail, $subject, $text) )
{
echo 'Письмо отправлено!'; }
else{
echo 'Ошибка! Не отправлено';
}

Если письмо не пришло, но вы получили уведомление «Письмо отправлено», значит, письма уходят и проблема в настройках CMS либо в модуле отправки почты. В данном случае можно обратиться в техподдержку Битрикс для выявления проблем в настройках CMS или к разработчику модуля отправки почты.

Не исключено, что письмо просто попало в спам. Можно попробовать отправить на другой почтовый ящик (с другим почтовым доменом). Если письмо пришло — значит, адрес отправителя в черном списке почтового домена, до которого письмо не дошло. Если письмо не дошло — возможно, ваш почтовый домен или IP-адрес попали в глобальные черные списки.

Если письмо не пришло, а вы получили уведомление «Отправка не удалась» — необходимо более детальное изучение проблемы. В таком случае потребуется вмешательство системного администратора.

«Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы

Такая ошибка говорит о наличии в корне сайта служебных скриптов, например, restore.php. Данные скрипты, как правило, добавляют временно для проведения каких-либо работ (например, restore.php — для восстановления сайта из резервной копии). Так или иначе, после выполнения работ такие скрипты необходимо удалить с сервера, так как они представляют угрозу безопасности сайту и данным.

Ошибка «Загрузка файла» и «Загрузка файла больше 4Мб» при проверке системы

Проверка системы Битрикс загружает файл размером более 4Мб. В большинстве случаев такая ошибка говорит об ограничениях в параметре upload_max_filesize для PHP.

Необходимо в файле конфигурации PHP установить данное значение выше 4Мб и перезапустить веб-сервер. В зависимости от окружения файл конфигурации PHP может находится в разных местах. Обычно данное значение устанавливается в файле /etc/php.ini.

Если вы используете панель ISPmanager — поправить конфигурацию можно прямо в ней: выберите нужный сайт, нажмите на кнопку PHP в верхней панели, найдите параметр upload_max_filesize и укажите нужное значение. Если вы используете окружение BitrixVM, необходимо вносить изменения в специальные файлы конфигурации, чтобы после перезагрузки сервера они не вернулись в исходное состояние. Подробнее можете узнать по ссылке.