Как исправить ошибку «Удаленный узел не прошел проверку» при подключении к веб-сервису в 1С?

← На главную

При интеграции 1С с внешними системами по протоколу HTTPS разработчики и системные администраторы часто сталкиваются с ошибкой «Ошибка работы с Интернет: Удаленный узел не прошел проверку». Эта ошибка возникает на этапе установления защищенного соединения (SSL/TLS handshake), когда платформа 1С пытается проверить подлинность и надежность SSL-сертификата удаленного сервера, но по какой-то причине не может этого сделать.

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

Выясняем причины ошибки проверки сертификата

Для того чтобы эффективно устранить проблему, нам необходимо понять механизм валидации SSL в платформе 1С. Когда 1С отправляет запрос к веб-сервису по протоколу HTTPS, происходят следующие процессы:

Проверка цепочки доверия (Certificate Chain). Платформа проверяет, кем выдан сертификат удаленного узла. Она пытается построить цепочку от конечного сертификата сервера через промежуточные до доверенного корневого сертификата (Root CA).
Проверка списков отзыва (CRL/OCSP). Платформа пытается связаться с серверами удостоверяющего центра, чтобы убедиться, что сертификат не был отозван владельцем до истечения срока его действия.

Исходя из этого, выделим четыре основные причины возникновения ошибки:

Использование самоподписанного сертификата. Если удаленный сервер использует тестовый или самоподписанный сертификат, платформа 1С по умолчанию отклонит такое соединение, так как этого сертификата нет в ее списке доверенных.
Отсутствие доступа к спискам отзыва (CRL). Если сервер 1С (а именно процесс rphost) работает под системным пользователем, у которого ограничен доступ в интернет или не настроен прокси-сервер, 1С не сможет проверить статус сертификата и заблокирует соединение.
Устаревший локальный файл сертификатов 1С. В ряде случаев (особенно в режиме совместимости с устаревшими версиями платформы) 1С использует собственное встроенное хранилище сертификатов — файл cacert.pem. Если этот файл устарел, 1С просто «не знает» о новых корневых сертификатах современных центров авторизации (например, Let's Encrypt).
Отсутствие корневых сертификатов в операционной системе. Если 1С использует системное хранилище ОС, на самом сервере Windows или Linux могут отсутствовать актуальные корневые сертификаты из-за отключенных обновлений системы.

Перейдем к практическим методам решения этой проблемы.

Решение 1. Отключение проверки сертификата в коде (для разработчиков)

Проанализируем ситуацию: если подключение выполняется к известному нам доверенному сервису внутри локальной сети или на этапе разработки и тестирования, мы можем временно или на постоянной основе отключить валидацию SSL-сертификата непосредственно в коде 1С. При этом для быстрой отправки запросов и проверки веб-сервисов непосредственно из среды системы отлично подойдёт инструмент для тестирования REST API на платформе 1С.

Для этого при инициализации защищенного соединения мы должны использовать объект ЗащищенноеСоединениеOpenSSL. Если передать в его конструктор параметры Неопределено, платформа перестанет проверять цепочку сертификатов и пропустит любое HTTPS-соединение.

Рассмотрим пример создания WS-прокси с отключенной проверкой сертификата:


// Создаем объект защищенного соединения с отключенной валидацией сертификатов
ПараметрыКлиента = Неопределено;
ПараметрыСервера = Неопределено;
ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL(ПараметрыКлиента, ПараметрыСервера);

// Обязательно передаем объект защищенного соединения в WSОпределения
Попытка
    Определения = Новый WSОпределения(
        ПутьWSDL, 
        ИмяПользователя, 
        ПарольПользователя, 
        , 
        ТаймаутСоединения, 
        ЗащищенноеСоединение
    );
Исключение
    ЗаписьЖурналаРегистрации("Интеграция.Ошибка", УровеньЖурналаРегистрации.Ошибка, , , ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
    ВызватьИсключение "Не удалось получить определения веб-сервиса: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке());
КонецПопытки;

// Создаем прокси на основе полученных определений
Попытка
    Прокси = Новый WSProxy(
        Определения, 
        ПространствоИменСервиса, 
        ИмяСервиса, 
        ИмяТочкиПодключения, 
        , 
        ТаймаутСоединения, 
        ЗащищенноеСоединение
    );
Исключение
    ЗаписьЖурналаРегистрации("Интеграция.Ошибка", УровеньЖурналаРегистрации.Ошибка, , , ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
    ВызватьИсключение "Ошибка создания WS-прокси: " + КраткоеПредставлениеОшибки(ИнформацияОбОшибке());
КонецПопытки;

// Теперь мы можем безопасно вызывать методы веб-сервиса
Результат = Прокси.Ping();

Важное примечание: Если в вашей конфигурации используется статическая WS-ссылка, добавленная непосредственно в дерево метаданных в Конфигураторе, управлять защищенным соединением программно может быть затруднительно. В таких случаях настоятельно рекомендуется перейти на динамическое создание WS-прокси через код, как показано в примере выше.

Решение 2. Обновление встроенного файла сертификатов cacert.pem (для администраторов)

Если код конфигурации изменять нельзя, или если политика безопасности компании требует обязательной проверки SSL, нам нужно обновить встроенное хранилище сертификатов платформы 1С.

Выполним следующие шаги для обновления файла cacert.pem:

Перейдем на официальный сайт curl или на портал 1С:ИТС и скачаем актуальный файл корневых сертификатов (обычно он называется cacert.pem).
Определим, где установлена платформа 1С на сервере. Обычно это каталог вида:
C:\Program Files\1cv8\[Номер_Версии_Платформы]\bin\ (для 64-разрядных систем) или C:\Program Files (x86)\1cv8\[Номер_Версии_Платформы]\bin\ (для 32-разрядных систем).
Найдем в этой папке существующий файл cacert.pem и сделаем его резервную копию, переименовав, например, в cacert_backup.pem.
Скопируем новый скачанный файл cacert.pem в эту папку.
Если сервер 1С работает в кластере, обязательно перезапустим службу сервера 1С (1C:Enterprise 8.3 Server Agent), чтобы изменения вступили в силу.

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

Решение 3. Установка сертификатов в операционную систему

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

Рассмотрим по шагам, как это сделать в ОС Windows:

Откроем браузер на сервере 1С и перейдем по адресу веб-сервиса (например, https://remote-host.ru/service?wsdl).
Нажмем на значок замочка в адресной строке браузера, перейдем в просмотр сертификата и на вкладке «Путь сертификации» изучим всю цепочку.
Экспортируем корневой сертификат (самый верхний в цепочке) и промежуточные сертификаты в файлы с расширением .cer (в кодировке DER или Base-64).
Откроем оснастку управления сертификатами локального компьютера. Для этого нажмем Win + R, введем mmc, выберем «Файл» -> «Добавить или удалить оснастку» -> «Сертификаты» -> «Учетная запись компьютера» -> «Локальный компьютер».
Перейдем в раздел «Доверенные корневые центры сертификации» (Trusted Root Certification Authorities) -> «Реестр» -> «Сертификаты».
Нажмем правой кнопкой мыши, выберем «Все задачи» -> «Импорт» и импортируем ранее сохраненный файл корневого сертификата.
Если в цепочке были промежуточные сертификаты, аналогичным образом импортируем их в раздел «Промежуточные центры сертификации» (Intermediate Certification Authorities).
Перезапустим службу сервера 1С.

Для операционных систем семейства Linux (например, Ubuntu/Debian) процедура будет выглядеть иначе. Нам потребуется поместить файлы сертификатов в каталог /usr/local/share/ca-certificates/ с расширением .crt и выполнить команду обновления конфигурации сертификатов:


sudo cp my_root_ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

После этого служба сервера 1С (процесс rphost) сможет успешно проверять удаленный узел без возникновения ошибок.

Решение 4. Настройка прав доступа и прокси-сервера для службы 1С

Иногда сертификаты установлены корректно, но ошибка все равно возникает из-за того, что у учетной записи, под которой запущена служба сервера 1С, нет прав на выход в интернет для проверки отзывов сертификатов (CRL).

Проанализируем эту ситуацию и настроим систему:

Узнаем имя пользователя, от имени которого работает служба 1C:Enterprise 8.3 Server Agent. Обычно это локальный системный пользователь USR1CV8.
Если доступ в интернет на предприятии осуществляется через прокси-сервер, необходимо настроить параметры прокси именно для этого пользователя.
Для этого откроем файл inetcfg.xml, который находится в каталоге конфигурации платформы (обычно C:\Program Files\1cv8\conf\inetcfg.xml). Если файла нет, создадим его.
Пропишем в нем настройки прокси-сервера следующим образом:


<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/8.1/data/internet-access">
    <proxy performAlternativeUrlResolution="false">
        <server>proxy.yourcompany.ru:8080</server>
        <bypassOnLocal>true</bypassOnLocal>
        <user>ProxyUser</user>
        <password>ProxyPassword</password>
    </proxy>
</config>

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

Таким образом, мы детально разобрали все возможные технические аспекты проблемы. Выбор конкретного решения зависит от требований безопасности вашей информационной системы: для быстрых тестов идеально подойдет программное отключение проверки в коде (Решение 1), а для надежной промышленной эксплуатации лучше использовать системные методы настройки доверия (Решения 3 и 4).