Как исправить ошибку «Алгоритм подписи сертификата криптографии отличается от алгоритма GOST R 34.10-2001» в ГИСМ 1С:Розница

При работе с государственными информационными системами маркировки (ГИСМ, Честный Знак, МДЛП и др.) пользователи часто сталкиваются с аппаратными и программными сбоями в процессе подписания документов. Один из наиболее распространенных сбоев при плановой смене электронной цифровой подписи (ЭЦП) — ошибка: «Алгоритм подписи сертификата криптографии отличается от алгоритма GOST R 34.10-2001». В этой статье мы подробно разберем, почему возникает эта проблема, как устроена криптография на уровне платформы 1С и какие существуют способы её окончательного решения.

Выясняем техническую причину ошибки

Для начала проанализируем ситуацию на стыке законодательства и технологий. С 2019 года удостоверяющие центры перешли на выдачу сертификатов по обновленному стандарту ГОСТ Р 34.10-2012. Старый стандарт ГОСТ Р 34.10-2001 признан устаревшим и больше не используется для выпуска новых подписей.

В экосистеме 1С для подписания XML-документов и SOAP-пакетов при обмене с ГИСМ используется специализированная внешняя компонента под названием КомпонентаXMLDSIG (входит в состав Библиотеки стандартных подсистем — БСП). Процесс генерации ошибки выглядит следующим образом:

1. При вызове процедуры подписания система обращается к установленному в операционной системе криптопровайдеру (например, КриптоПро CSP) и считывает параметры сертификата.
2. Для этого вызывается метод компоненты GetSignOIDFromCert, который извлекает фактический объектный идентификатор (OID) алгоритма подписи из нового сертификата ГОСТ-2012. Для ключа длиной 256 бит этот OID равен 1.2.643.7.1.1.3.2, а для ключа 512 бит — 1.2.643.7.1.1.3.3.
3. В устаревших релизах конфигураций (таких как 1С:Розница ниже версии 2.2.13, старых версиях УТ 11 или отраслевых решениях вроде «Медицина. Больничные») параметры криптографии для ГИСМ были жестко прописаны в программном коде (так называемый «хардкод»). Система принудительно ожидала старый OID ГОСТ-2001 (1.2.643.2.2.3).
4. Программа сравнивает считанный из сертификата актуальный OID с жестко заданным в коде значением. Обнаружив несовпадение, БСП прерывает выполнение операции и выводит пользователю ошибку о несоответствии алгоритмов.

Ниже рассмотрим два основных пути решения этой проблемы: штатный (через обновление ПО) и альтернативный (для кастомизированных баз, где быстрое обновление невозможно).

Решение 1. Полное обновление программного комплекса (Рекомендуемый способ)

Самый надежный и правильный способ избавиться от ошибки раз и навсегда — обновить конфигурацию 1С и средства криптографической защиты информации (СКЗИ) до актуальных версий. Разработчики 1С полностью переработали архитектуру определения алгоритмов, внедрив динамическое сопоставление стандартов ГОСТ.

Выполним следующие шаги по обновлению системы:

1. Обновление конфигурации 1С: Перейдем на актуальный релиз программного продукта. Для конфигурации «1С:Розница» корректная поддержка динамического выбора алгоритмов без жесткой привязки к ГОСТ-2001 появилась начиная с версии 2.2.13.12. В этой версии параметры заполняются на основе анализа самого сертификата через вызовы функций БСП. Для массового выполнения этой операции в нескольких базах удобно использовать инструмент для автоматического обновления и обслуживания 1С.
2. Обновление КриптоПро CSP: Убедимся, что на рабочем компьютере или сервере установлена поддерживаемая версия криптопровайдера. Полноценная и стабильная работа с ГОСТ Р 34.10-2012 в связке с компонентами 1С гарантируется в КриптоПро CSP версий 4.0.9963 и выше, а также во всей линейке КриптоПро CSP 5.0. Устаревшие сборки (например, 4.0.9944) необходимо обновить, предварительно удалив старую версию через утилиту очистки следов КриптоПро (cspclean).
3. Настройка криптопровайдера в интерфейсе 1С: Нам необходимо проверить, как зарегистрирована программа шифрования в самой системе. Перейдем в раздел Администрирование -> Обмен электронными документами -> Настройки электронной подписи и шифрования. На вкладке «Программы» проверим запись для используемого криптопровайдера. Для работы с новыми ключами должен быть выбран стандарт «КриптоПро CSP (ГОСТ 2012)».

Решение 2. Обходной путь с использованием расширения конфигурации

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

Нам потребуется переопределить заполнение параметров структуры ПараметрыXMLDSig. Для этого проанализируем, какие параметры передаются компоненте подписи. Создадим новое расширение конфигурации и перехватим процедуру настройки XML-подписи (в зависимости от релиза это может быть модуль интеграции с ГИСМ или общий модуль криптографии БСП).

Нам необходимо принудительно указать новые OID и имена алгоритмов хеширования и подписи для ГОСТ-2012. Напишем следующий код в расширении:

ПараметрыXMLDSig.ИмяАлгоритмаПодписи = "GR 34.10-2012 256";
ПараметрыXMLDSig.OIDАлгоритмаПодписи = "1.2.643.7.1.1.3.2";
ПараметрыXMLDSig.ИмяАлгоритмаХеширования = "GR 34.11-2012 256";
ПараметрыXMLDSig.OIDАлгоритмаХеширования = "1.2.643.7.1.1.2.2";

Для обеспечения универсальности (если на рабочих местах могут одновременно использоваться как новые ключи ГОСТ-2012, так и старые ГОСТ-2001) в современных версиях БСП применяется динамическая инициализация через перечисление алгоритмов в строку с разделителем. Посмотрим на пример реализации такого универсального заполнения параметров:

ПараметрыXMLDSig.ИмяАлгоритмаПодписи = "GOST R 34.10-2001" + Символы.ПС + "GOST R 34.10-2012";
ПараметрыXMLDSig.OIDАлгоритмаПодписи = "1.2.643.2.2.3" + Символы.ПС + "1.2.643.7.1.1.3.2";
ПараметрыXMLDSig.ИмяАлгоритмаХеширования = "GOST R 34.11-94" + Символы.ПС + "GOST R 34.11-2012";
ПараметрыXMLDSig.OIDАлгоритмаХеширования = "1.2.643.2.2.9" + Символы.ПС + "1.2.643.7.1.1.2.2";

Этот подход позволяет внешней компоненте XMLDSig автоматически перебирать поддерживаемые алгоритмы и успешно подписывать документы как старыми, так и новыми ключами.

Решение 3. Временная ручная отправка документов через ЛК Честного Знака

Если программные ошибки в коде 1С не позволяют отправить документ напрямую через API-интерфейс ГИСМ даже после корректировки параметров (например, когда сервер ГИСМ возвращает ошибку «подпись не верна» из-за рассинхронизации версий схем данных), мы можем воспользоваться механизмом ручной загрузки файлов XML. В такой ситуации, когда обычная интеграция не срабатывает, действия пользователя на сайте можно автоматизировать с помощью программного робота с визуальным конструктором сценариев.

Выполним следующие шаги для ручной отправки документов:

1. В интерфейсе интеграции с маркировкой 1С:Розница подготовим документ к отправке и нажмем кнопку «Передать данные».
2. При возникновении ошибки обмена обратим внимание на форму отправки: там присутствует системная ссылка на сформированный XML-файл, подготовленный к отправке на сервер маркировки.
3. Откроем этот файл (или скопируем его содержимое в буфер обмена). Создадим на локальном компьютере пустой текстовый документ с расширением .xml, вставим туда скопированные данные и сохраним файл.
4. Откроем браузер, перейдем в личный кабинет системы маркировки («Честный Знак» или соответствующий раздел ГИСМ) и авторизуемся под своей учетной записью с использованием нового ключа ЭЦП ГОСТ-2012.
5. Перейдем в раздел загрузки документов, выберем наш сохраненный XML-файл, подпишем его непосредственно в браузере средствами плагина КриптоПро ЭЦП Browser plug-in и отправим. Данный метод позволяет обойти любые внутренние ошибки платформы 1С и успешно зарегистрировать движение маркированных товаров в системе государственной маркировки.

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