Интеграция с банковскими сервисами, такими как МКБ для приема платежей по QR-кодам, часто требует настройки двухстороннего защищенного соединения (Mutual TLS). В этой схеме не только клиент проверяет сертификат сервера, но и сервер требует от клиента (вашей базы 1С) предъявить сертификат для подтверждения личности. Ошибка "Failure when receiving data from the peer" является классическим признаком того, что на этапе «рукопожатия» (SSL Handshake) возникли проблемы: либо сертификат не был предоставлен, либо он не прошел проверку на стороне сервера.
Рассмотрим подробно, как правильно настроить это взаимодействие, разберем типичные ошибки и проанализируем различные способы реализации в среде 1С:Предприятие.
Разберем пример кода, который часто используется для инициирования такого соединения. На первый взгляд он выглядит корректно, но содержит нюансы, которые могут привести к отказу в соединении.
стСтруктураДанныхJSON = Новый Структура;
// ... заполнение структуры данными ...
ЗаписьJSON = Новый ЗаписьJSON;
ПараметрыJSON = Новый ПараметрыЗаписиJSON(ПереносСтрокJSON.Нет, " ", Истина);
ЗаписьJSON.УстановитьСтроку(ПараметрыJSON);
ЗаписатьJSON(ЗаписьJSON, стСтруктураДанныхJSON);
СтрокаJSON = ЗаписьJSON.Закрыть();
// Инициализация защищенного соединения
ssl = Новый ЗащищенноеСоединениеOpenSSL(
Новый СертификатКлиентаWindows(СпособВыбораСертификатаWindows.Авто),
Новый СертификатыУдостоверяющихЦентровWindows());
HTTPСоединение = Новый HTTPСоединение("host", port,,,,, ssl);
Заголовки = Новый Соответствие;
запросPOST = Новый HTTPЗапрос("address", Заголовки);
запросPOST.УстановитьТелоИзСтроки(СтрокаJSON, "utf-8", ИспользованиеByteOrderMark.НеИспользовать);
Ответ = HTTPСоединение.ОтправитьДляОбработки(запросPOST);
Проанализируем ситуацию: если в Postman запрос проходит успешно, а в 1С возникает ошибка Failure when receiving data from the peer, проблема чаще всего кроется не в сетевой доступности, а в контексте исполнения и цепочке доверия сертификата.
Одной из самых частых причин отказа является отсутствие промежуточных или корневых сертификатов банка в хранилище доверенных лиц. Даже если клиентский сертификат установлен, 1С (через OpenSSL) должна иметь возможность проверить всю цепочку до доверенного корня.
Выполним следующие шаги для проверки:
certlm.msc для локального компьютера или certmgr.msc для пользователя).Важный момент: Если код 1С выполняется на сервере, сертификаты ОБЯЗАТЕЛЬНО должны быть установлены в хранилище "Локальный компьютер" (Local Machine), так как служба сервера 1С не имеет доступа к личному хранилищу вашей учетной записи пользователя.
Когда вы используете СертификатКлиентаWindows, 1С пытается обратиться к закрытому ключу сертификата. Если служба Агент сервера 1С:Предприятия запущена от имени системной учетной записи (например, USR1CV8), у этой учетной записи может не быть прав на чтение закрытого ключа.
Рассмотрим, как выдать права:
mmc (добавьте модуль "Сертификаты" для локального компьютера).USR1CV8 или LocalService), и дайте ему права на Чтение.Если вы решите уйти от системного хранилища Windows и использовать файл напрямую через объект СертификатКлиентаФайл, вы можете столкнуться с несовместимостью алгоритмов шифрования.
Платформа 1С (особенно версии до 8.3.20) использует библиотеки OpenSSL, которые могут не поддерживать современные алгоритмы шифрования контейнеров .p12 или .pfx, созданных в OpenSSL 3.0. Если вы получаете ошибку при чтении файла, попробуйте перепаковать сертификат с использованием "Legacy" алгоритмов:
openssl pkcs12 -in original.p12 -out legacy.p12 -nodes -legacy
Затем в 1С используйте полученный файл:
Сертификат = Новый СертификатКлиентаФайл("D:\certificates\legacy.p12", "пароль");
ssl = Новый ЗащищенноеСоединениеOpenSSL(Сертификат, Новый СертификатыУдостоверяющихЦентровWindows());
Если штатный объект HTTPСоединение продолжает выдавать ошибки, специфичные для внутренней реализации OpenSSL в 1С, можно воспользоваться системным объектом WinHttp.WinHttpRequest.5.1. Этот метод работает более нативно для ОС Windows и часто "видит" сертификаты там, где 1С их теряет.
Рассмотрим пример реализации:
WinHttp = Новый COMОбъект("WinHttp.WinHttpRequest.5.1");
WinHttp.Open("POST", "https://bank-api-url.ru/api/v1/pay", Ложь);
// Указываем имя сертификата из хранилища (Subject)
// Или оставляем пустым, если нужно выбрать первый подходящий
WinHttp.SetClientCertificate("LOCAL_MACHINE\My\ИмяВашегоСертификата");
WinHttp.SetRequestHeader("Content-Type", "application/json");
WinHttp.Send(СтрокаJSON);
Статус = WinHttp.Status;
ОтветТекст = WinHttp.ResponseText;
Обратите внимание: Строка идентификации сертификата в методе SetClientCertificate может варьироваться в зависимости от настроек системы. Обычно используется формат LOCATION\STORE\SUBJECT.
В самых сложных случаях, когда 1С категорически не хочет принимать специфический банковский сертификат (например, из-за редких ГОСТ-алгоритмов или особенностей TLS-протокола), рекомендуется использовать Stunnel. Это внешняя утилита, которая создает локальный "туннель".
Схема работы будет выглядеть так:
HTTP запрос на localhost:8080.HTTPS, подкладывает клиентский сертификат и отправляет запрос в банк.Конфигурация stunnel.conf может выглядеть следующим образом:
[bank_integration]
client = yes
accept = 127.0.0.1:8080
connect = api.bank.ru:443
cert = client_cert.pem
key = private_key.pem
В коде 1С при этом вы просто создаете соединение без объекта ЗащищенноеСоединениеOpenSSL на локальный адрес, что полностью исключает проблемы с SSL внутри платформы.
Проанализировав ситуацию, можно сделать вывод, что наиболее вероятная причина ошибки — неполная цепочка доверия в системном хранилище или отсутствие прав у пользователя службы 1С на доступ к закрытому ключу. Перед изменением кода обязательно проверьте:
USR1CV8 на файлы сертификатов и ветки реестра (если используется Windows Store).Использование ЗащищенноеСоединениеOpenSSL с параметрами СертификатКлиентаWindows и СертификатыУдостоверяющихЦентровWindows является наиболее современным и правильным подходом для платформы 8.3, при условии корректной настройки окружения операционной системы.