Как решить ошибку инициализации SSL-соединения при отправке HTTP-запросов в 1С?

При интеграции 1С с внешними или внутренними веб-сервисами разработчики часто сталкиваются с ошибкой: «Ошибка работы с Интернет: Ошибка инициализации SSL-соединения». При этом сторонние утилиты (например, Advanced REST Client, Postman или обычный браузер) могут успешно выполнять запросы к этому же адресу.

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

Анализ исходного кода и сути проблемы

Рассмотрим типовой пример кода, который часто приводит к возникновению ошибки инициализации соединения:

Функция ВыполнитьPOSTЗапрос(ИмяСервера, Порт, СтрокаОтправки, СсылкаНаРесурс) Экспорт
    
    // Инициализация защищенного соединения с использованием системных сертификатов Windows
    ssl = Новый ЗащищенноеСоединениеOpenSSL(Новый СертификатКлиентаWindows(), Новый СертификатыУдостоверяющихЦентровWindows()); 
    HTTP = Новый HTTPСоединение(ИмяСервера, Порт, , , , 60, ssl);
        
    ЗаголовокЗапросаHTTP = Новый Соответствие();
    ЗаголовокЗапросаHTTP.Вставить("Content-Length", СтрДлина(СтрокаОтправки)); 
    ЗаголовокЗапросаHTTP.Вставить("Content-Type", "application/x-www-form-urlencoded"); 
    
    Запрос = Новый HTTPЗапрос(СсылкаНаРесурс, ЗаголовокЗапросаHTTP); 
    Запрос.УстановитьТелоИзСтроки(СтрокаОтправки); 
    
    Возврат HTTP.ОтправитьДляОбработки(Запрос); 
    
КонецФункции

При вызове этой функции с параметрами ВыполнитьPOSTЗапрос("192.168.20.12", 7000, ТекстXML, "/cwms/ws/NOM") платформа возвращает ошибку инициализации SSL. Выясним основные причины такого поведения.

---

Причина 1. Использование IP-адреса вместо доменного имени (Hostname Mismatch)

Это наиболее частая причина сбоя при работе в локальных сетях (интранете). SSL/TLS-сертификаты практически никогда не выписываются на IP-адрес — они привязываются к конкретному доменному имени (например, cwms.company.local).

Компонент OpenSSL, встроенный в платформу 1С, выполняет строгую валидацию соответствия узла. Если в коде указан IP-адрес 192.168.20.12, а в сертификате сервера прописано доменное имя, библиотека шифрования прервет процесс рукопожатия (Handshake) из-за несоответствия имен (Hostname Mismatch).

Почему работают REST-клиенты: Специализированные программы по умолчанию игнорируют ошибки валидации имен хостов и самоподписанных сертификатов. 1С требует явного доверия к узлу.

Решение:

1. Выясните, на какое доменное имя выпущен SSL-сертификат целевого сервера.
2. В коде 1С передавайте именно это доменное имя вместо IP-адреса.
3. Если на предприятии не настроен DNS-сервер для сопоставления этого имени с локальным IP, добавьте соответствующую запись в файл hosts на компьютере (или сервере), где выполняется код 1С:

192.168.20.12 cwms.company.local ---

Причина 2. Контекст выполнения кода и права учетной записи службы 1С

Проанализируем, под кем выполняется код. Если вызов происходит на стороне сервера (например, в регламентном задании или серверном модуле), то инициатором запроса выступает системная учетная запись, под которой запущена служба «1С:Предприятия» (обычно это USR1CV8).

Даже если вы установили все необходимые сертификаты в хранилище «Текущий пользователь» под своей учетной записью администратора Windows, служба сервера 1С ничего о них не знает.

Решение:

1. Экспортируйте корневой сертификат вашего локального центра сертификации (CA) или самоподписанный сертификат веб-сервиса.
2. Установите его на сервере 1С в хранилище «Локальный компьютер» (Local Computer), а не в «Текущий пользователь».
3. Поместите сертификат в ветку «Доверенные корневые центры сертификации» (Trusted Root Certification Authorities).

---

Причина 3. Особенности встроенного хранилища сертификатов 1С (cacert.pem)

В зависимости от версии платформы 1С и режима совместимости конфигурации, поведение системы при проверке сертификатов различается:

• Старые версии платформы (и конфигурации в режиме совместимости) игнорируют системные сертификаты Windows и проверяют доверие только по собственному файлу-контейнеру cacert.pem, расположенному по пути C:\Program Files\1cv8\8.3.X.XXXX\bin\cacert.pem.
• Современные версии платформы умеют корректно взаимодействовать с сертификатами операционной системы.

Решение для современных платформ: Измените инициализацию защищенного соединения, явно указав использование удостоверяющих центров операционной системы:

ssl = Новый ЗащищенноеСоединениеOpenSSL(Неопределено, Новый СертификатыУдостоверяющихЦентровОС());

Использование Неопределено в первом параметре отключает отправку клиентского сертификата (если сервер его не требует принудительно), что решает проблемы, когда сервер ошибочно отвергает пустой контейнер клиентских сертификатов Windows.

Решение для старых платформ (или при строгих политиках совместимости):

1. Откройте ваш корневой сертификат в текстовом редакторе (он должен быть экспортирован в формате Base64 / PEM).
2. Скопируйте его текстовое содержимое (включая строки ---BEGIN CERTIFICATE--- и ---END CERTIFICATE---).
3. Откройте файл cacert.pem в папке bin текущей платформы 1С на сервере.
4. Вставьте скопированный текст в самый конец файла и сохраните изменения. Обратите внимание: при обновлении платформы данный файл перезаписывается, и процедуру придется повторить.

---

Причина 4. Несовместимость версий протоколов шифрования (TLS 1.2 / TLS 1.3)

Современные веб-серверы из соображений безопасности отключают поддержку устаревших протоколов SSL 3.0, TLS 1.0 и TLS 1.1, оставляя активными только TLS 1.2 и TLS 1.3.

Если сервер настроен на жесткие правила шифрования (Cipher Suites), а платформа 1С или операционная система, на которой она установлена, устарели, они не смогут договориться о поддерживаемых методах шифрования во время рукопожатия.

Решение:

1. Убедитесь, что операционная система сервера 1С обновлена и на ней включена поддержка TLS 1.2 на уровне реестра.
2. Обновите технологическую платформу 1С до актуального релиза. В последних версиях платформы встроенная библиотека OpenSSL регулярно обновляется и поддерживает самые современные стандарты безопасности.

---

Причина 5. Использование WinHttpRequest как универсальный обходной путь

Если у вас нет возможности изменять настройки сертификатов на сервере 1С, редактировать файлы платформы или обновлять конфигурацию, можно использовать альтернативный вариант отправки запросов через COM-объект Windows.

Объект WinHttp.WinHttpRequest.5.1 позволяет гибко управлять параметрами безопасности и принудительно игнорировать любые ошибки SSL-сертификатов (включая самоподписанные сертификаты и несоответствие имени хоста).

Рассмотрим пример реализации функции отправки POST-запроса через этот механизм:

Функция ВыполнитьPOSTЗапросЧерезWinHttp(ИмяСервера, Порт, СтрокаОтправки, СсылкаНаРесурс) Экспорт
    
    Попытка
        WinHttp = Новый COMОбъект("WinHttp.WinHttpRequest.5.1");
        
        // Формируем полный URL-адрес
        АдресРесурса = "https://" + ИмяСервера + ":" + Формат(Порт, "ЧГ=0") + СсылкаНаРесурс;
        
        WinHttp.Open("POST", АдресРесурса, Ложь);
        
        // Опция 4 отвечает за обработку ошибок сертификатов.
        // Значение 13056 (0x3300) предписывает игнорировать:
        // - Несоответствие имени хоста (Unknown CN)
        // - Недоверенного издателя (Untrusted CA)
        // - Истекший срок действия сертификата
        WinHttp.Option(4, 13056);
        
        WinHttp.SetRequestHeader("Content-Type", "application/x-www-form-urlencoded");
        WinHttp.SetRequestHeader("Content-Length", СтрДлина(СтрокаОтправки));
        
        WinHttp.Send(СтрокаОтправки);
        
        КодСостояния = WinHttp.Status;
        Если КодСостояния = 200 Тогда
            Возврат WinHttp.ResponseText;
        Иначе
            ВызватьИсключение "Сервер вернул код ошибки: " + КодСостояния;
        КонецЕсли;
        
    Исключение
        ЗаписьЖурналаРегистрации("Интеграция.ОшибкаSSL", УровеньЖурналаРегистрации.Ошибка, , , ОписаниеОшибки());
        ВызватьИсключение "Не удалось выполнить запрос: " + КраткоеПредставлениеОшибки(ОписаниеОшибки());
    КонецПопытки;
    
КонецФункции

Преимущества данного метода:

• Полное игнорирование проблем с сертификатами без изменения системных настроек ОС.
• Простота реализации интеграции во внутренних тестовых контурах.

Важное ограничение: Данное решение будет работать исключительно на серверах под управлением ОС Windows. Если ваш сервер приложений 1С работает под управлением Linux, COM-объекты использовать не получится — в этом случае необходимо настраивать валидацию сертификатов через ЗащищенноеСоединениеOpenSSL, как описано в первых трех пунктах.