Многие разработчики и системные администраторы периодически сталкиваются с внезапной остановкой обмена данными с внешними сервисами (Сфера EDI, Честный знак, 1С-Отчетность, 1С-ЭДО, Dadata и другими). Проанализируем ситуацию: еще вчера интеграция через WebSocket работала стабильно, а сегодня при попытке соединения система выдает сообщение: «При вызове веб-сервиса произошла ошибка. URL сервиса: по причине: Ошибка работы с Интернет: Удаленный узел не прошел проверку». Разберем по шагам, почему возникает эта проблема, как на нее влияет версия платформы и режим совместимости, и как мы вместе можем восстановить работоспособность обмена.
Для начала рассмотрим, как платформа 1С работает с безопасными HTTPS-соединениями. При обращении к любому современному веб-сервису через объект WSОпределения или HTTPСоединение происходит проверка SSL-сертификата удаленного сервера. Чтобы доверять этому сертификату, система должна проверить его подлинность через цепочку корневых удостоверяющих центров (например, DigiCert, GlobalSign и т.д.).
Ключевая проблема кроется в архитектуре старых версий платформы и механизме режима совместимости. Если ваша конфигурация (например, УПП 1.3, БП 2.0 или ЗУП 2.5) работает в режиме совместимости 8.3.7 и ниже (включая популярный режим 8.2.13), платформа жестко игнорирует хранилище доверенных сертификатов самой операционной системы Windows или Linux. Вместо этого она обращается исключительно к собственному локальному файлу, который поставляется в дистрибутиве.
Этот файл называется cacert.pem. Поскольку старые релизы платформы выпускались давно, они комплектовались набором корневых сертификатов, актуальным на тот момент времени. Удостоверяющие центры регулярно перевыпускают свои ключи и отзывают старые. Когда внешний сервис (например, провайдер EDI) обновляет свой SSL-сертификат на новый, выпущенный современным центром, старая платформа 1С просто не находит подтверждающего корневого сертификата в своем устаревшем файле cacert.pem. Результат — соединение сбрасывается с ошибкой.
Важно отметить: начиная с версии 8.3.8 платформа 1С изменила логику и стала использовать системное хранилище ОС (которое обновляется автоматически через обновления Windows). Однако, если в свойствах конфигурации стоит режим совместимости со старыми версиями, платформа принудительно возвращается к использованию локального файла.
Чтобы решить проблему, нам необходимо актуализировать этот файл. Посмотрим, где он находится. Стандартный путь в операционных системах Windows зависит от разрядности установленной платформы:
Критически важный нюанс клиент-серверной архитектуры: если ваша база данных работает в клиент-серверном варианте, весь код по обращению к внешним веб-сервисам (особенно регламентные задания по обмену EDI) выполняется на стороне сервера 1С. Для этой задачи есть автоматизация интеграции с ГИС МТ Честный знак и системами ЭДО. Следовательно, искать и модифицировать файл cacert.pem нужно именно на сервере 1С, а не на рабочих местах пользователей. Радостная новость заключается в том, что перезапускать службу Агента сервера 1С после внесения изменений в файл не требуется — платформа считывает этот файл динамически при каждом новом обращении.
Многие специалисты пытаются просто скачать свежий файл cacert.pem из интернета или скопировать его из более свежей версии платформы и полностью заменить старый. Проанализируем, почему этот метод может быть опасен. Вдруг у конечного пользователя или в вашей корпоративной сети используются самоподписанные сертификаты для внутренних сервисов? Они уже добавлены в ваш текущий файл. Если вы его перезапишете, заработает EDI-обмен, но сломаются внутренние интеграции. Поэтому мы рассмотрим безопасный метод — ручное добавление недостающего корневого сертификата.
-----BEGIN CERTIFICATE----- и заканчивающийся -----END CERTIFICATE-----. Скопируйте весь этот текст.cacert.pem в папке bin вашей платформы 1С (откройте Блокнот от имени Администратора, иначе не сможете сохранить изменения).После выполнения этих простых шагов платформа 1С начнет доверять удаленному узлу, и обмен данными восстановится. Как правило, сертификаты выдаются на длительный срок (от 5 до 10 лет), поэтому повторять эту операцию придется нескоро.
Если вы уверены, что в вашем файле нет никаких специфичных внутренних сертификатов, можно применить более быстрые методы. Фирма «1С» регулярно публикует готовые сборки актуальных сертификатов на портале ИТС. Вы можете скачать свежий cacert.pem и просто заменить им старый файл в каталоге платформы. Этот способ полностью исключает ошибки форматирования, которые можно случайно допустить при ручном редактировании текста.
Кроме того, для пользователей файловых баз существуют специализированные внешние обработки (с расширением .epf). При запуске такой обработки она сама определяет путь к установленному релизу платформы, скачивает актуальный список удостоверяющих центров и программно дописывает нужные блоки в локальный файл. Однако помните, что обработки исполняются в контексте клиента, поэтому для серверных баз они не обновят файл на самом сервере 1С.
Если вы являетесь разработчиком интеграции и хотите раз и навсегда избавить администраторов от необходимости править файлы при каждой смене ключей у провайдера, мы можем пересмотреть архитектуру обмена. Если текущий обмен построен на использовании WSDL и протокола SOAP, объект WSОпределения не позволяет программно вмешаться в процесс валидации сертификата. В этом случае правка файла — единственный выход.
Но если у внешнего сервиса есть REST API, мы можем переписать логику, используя объект HTTPСоединение. Этот объект позволяет явно указать платформе игнорировать ошибки валидации сертификатов. Для этой задачи есть шаблон кода интеграции через HTTPСоединение. Такой подход снижает уровень безопасности, так как система перестает проверять подлинность сервера, но для многих технических обменов внутри закрытых контуров это допустимый компромисс.
Посмотрим на пример того, как это реализуется в коде 1С:
// Создаем объект для защищенного соединения
// Первым параметром передается клиентский сертификат (нам не нужен)
// Вторым параметром передаем признак отключения проверки сертификата сервера
ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL(Неопределено, Неопределено);
// Инициализируем HTTP-соединение с использованием нашего защищенного канала
Соединение = Новый HTTPСоединение(
"api.sfera-edi.ru", // Адрес сервера без протокола
443, // Порт для HTTPS
, // Пользователь
, // Пароль
, // Прокси
30, // Таймаут в секундах
ЗащищенноеСоединение // Наш настроенный объект OpenSSL
);
// Создаем HTTP-запрос
Запрос = Новый HTTPЗапрос("/v1/documents");
// Выполняем GET-запрос
Ответ = Соединение.Получить(Запрос);
Передавая значение Неопределено в качестве второго параметра в ЗащищенноеСоединениеOpenSSL, мы даем прямую команду платформе 1С: не проверять сертификат удаленного узла по цепочке доверия и игнорировать содержимое файла cacert.pem. Данный программный код будет безотказно работать в любых режимах совместимости, включая 8.2.13, и вам больше никогда не придется отслеживать моменты, когда провайдер перевыпускает свои SSL-сертификаты.
Мы подробно разобрали, почему возникает ошибка валидации удаленного узла. Подведем краткие итоги для закрепления материала:
HTTPСоединение с программным отключением валидации, что делает код независимым от обновления ключей удостоверяющих центров.Применяя эти знания на практике, вы сможете оперативно восстанавливать обмен данными с любыми внешними веб-сервисами и избегать простоев в бизнес-процессах вашего предприятия.