Как исправить ошибку «Удаленный узел не прошел проверку» при работе с dadata.ru в 1С 8.3

← На главную

При переходе с платформы 1С:Предприятие 8.2 на 8.3 разработчики часто сталкиваются с тем, что отлаженные механизмы интеграции с внешними сервисами перестают работать. Одной из самых распространенных проблем является ошибка «Удаленный узел не прошел проверку» при попытке обращения к API через протокол HTTPS. Особенно часто это проявляется при работе с популярным сервисом dadata.ru.

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

Выясняем причину: почему 8.2 работала, а 8.3 — нет?

Для начала проанализируем ситуацию. В платформе 8.2 и ранних версиях 8.3 (до 8.3.7) механизмы проверки SSL-сертификатов опирались на внутренние файлы платформы. Начиная с версии 8.3.8, 1С изменила стратегию безопасности. Теперь платформа по умолчанию пытается использовать системное хранилище сертификатов операционной системы. Если в системе отсутствует цепочка доверия к сертификату сайта (в нашем случае dadata.ru), возникает ошибка проверки узла.

Сервис dadata.ru использует сертификаты от Let's Encrypt. Это современные и надежные сертификаты, однако их корневые центры периодически обновляются. Если ваша операционная система устарела или не имеет актуальных корневых сертификатов, 1С не сможет подтвердить подлинность соединения.

Решение №1: Правильная инициализация HTTPСоединение

Как показывает практика, самой частой причиной ошибки в коде является отсутствие явного указания на использование защищенного соединения. В платформе 8.3 для работы по HTTPS недостаточно просто указать порт 443. Необходимо передать объект ЗащищенноеСоединениеOpenSSL в конструктор соединения.

Рассмотрим правильный пример инициализации соединения:


ИмяСервера = "suggestions.dadata.ru";
Порт = 443;

// Создаем объект защищенного соединения
// Без параметров он будет использовать настройки по умолчанию и системное хранилище
ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL();

// Инициализируем соединение с передачей объекта защиты
Соединение = Новый HTTPСоединение(
    ИмяСервера, 
    Порт, 
    , // Логин
    , // Пароль
    , // Прокси
    , // Таймаут
    ЗащищенноеСоединение
);

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

Решение №2: Работа с файлом cacert.pem

Если ваша конфигурация работает в режиме совместимости с версией 8.3.7 или ниже, или если вы используете Linux-сервер, платформа может игнорировать системное хранилище и обращаться к своему внутреннему файлу cacert.pem.

Разберем по шагам, как обновить сертификаты в этом файле:

Перейдем в каталог установленной платформы, например: C:\Program Files\1cv8\8.3.X.XXX\bin\.
Найдем файл cacert.pem. Это текстовый файл, содержащий список доверенных сертификатов в формате Base64.
Если сертификат Let's Encrypt (ISRG Root X1) в нем отсутствует, его необходимо добавить вручную.
Скачаем актуальный корневой сертификат с сайта удостоверяющего центра, откроем его в текстовом редакторе и скопируем содержимое (вместе с тегами BEGIN и END) в конец файла cacert.pem.

Помните, что после обновления платформы на новый релиз этот файл будет заменен на стандартный, и процедуру придется повторить. Поэтому использование Новый ЗащищенноеСоединениеOpenSSL() является более предпочтительным методом.

Решение №3: Обновление корневых сертификатов ОС

Проанализируем ситуацию, когда код написан верно, но ошибка сохраняется. Это часто случается на серверах под управлением Windows Server 2008 R2 или 2012, где отключены автоматические обновления.

Проверим цепочку сертификации:

Откроем браузер на сервере (желательно Internet Explorer или Edge, так как они используют системное хранилище).
Перейдем на https://dadata.ru.
Нажмем на значок замка и просмотрим путь сертификации.
Если на одном из узлов (обычно на корневом ISRG Root X1) стоит красный крестик — значит, ОС не доверяет этому центру.

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

Дополнительные факторы: IPv6 и Прокси-серверы

Иногда корень проблемы кроется в сетевых настройках. Рассмотрим два важных аспекта:

1. Влияние IPv6. На некоторых серверах некорректно настроен протокол IPv6. Платформа 1С может пытаться сначала разрешить имя dadata.ru в адрес IPv6. Если соединение по этому протоколу блокируется или работает нестабильно, проверка SSL может прерваться с ошибкой. Попробуйте отключить IPv6 в свойствах сетевого адаптера, если он не используется в вашей инфраструктуре.

2. SSL-инспекция антивирусом. Если на сервере установлен корпоративный антивирус или используется прокси-сервер с функцией проверки HTTPS-трафика, они могут подменять сертификат dadata.ru своим собственным «на лету». 1С закономерно отказывается доверять такому сертификату. В этом случае необходимо добавить домен *.dadata.ru в исключения проверки трафика.

Резюме

Для стабильной работы с DaData под платформой 8.3 выполните следующие действия:

Всегда используйте Новый ЗащищенноеСоединениеOpenSSL() в конструкторе соединения.
Убедитесь, что в системе (в хранилище компьютера) установлены актуальные корневые сертификаты Let's Encrypt.
При использовании клиент-серверного варианта проверяйте сертификаты под учетной записью, от которой запущен сервер 1С.

Эти действия в 99% случаев решают проблему «Удаленный узел не прошел проверку» и обеспечивают надежную интеграцию вашей системы с внешними сервисами.