Ошибка верификации крипто-подписи КМ: причины и решение
Автор: Михаил С., Архитектор 1С · Опубликовано: 29.09.2026

📅 Опубликовано 29 сентября 2026 г.
Коротко: ошибка верификации крипто-подписи КМ означает, что ГИС МТ получила код маркировки, но не подтвердила его криптографическую часть – группы 91 и 92. Причина обычно не в самом коде, а в канале передачи: сканер обрезал криптохвост или потерял разделитель GS (символ с кодом 29). Полный код занимает около 85 символов, «голый» – 31. Диагностика по длине строки выполняется быстро.
- Криптохвост – это группы
(91)– ключ проверки, 4 символа, и(92)– значение подписи, 44 символа в Base64. - Арифметика полного КМ: 16 + 15 (база, 31 символ) + 6 + 46 + 2 разделителя GS ≈ 85 символов. Если в поле кода ровно 31 символ – криптохвоста нет физически.
- В ответе True API за подпись отвечает отдельное поле
verified. Сочетаниеfound: trueиverified: false– это и есть «подпись не сошлась». - Сканер обязан работать в режиме GS1 DataMatrix и передавать
<GS>как ASCII 29; в режиме «эмуляция клавиатуры» с русской раскладкой криптохвост искажается почти всегда. - Санкция за недостоверные сведения в ГИС МТ – ст. 15.12.1 КоАП: предупреждение или 1 000–10 000 ₽ на должностное лицо и 50 000–100 000 ₽ на юрлицо.
Что означает ошибка верификации крипто-подписи КМ в ГИС МТ?
В момент эмиссии кода оператор системы маркировки формирует для него криптографическую подпись и записывает её прямо внутрь DataMatrix. Дальше этот же оператор проверяет подпись каждый раз, когда код возвращается в систему: при выводе из оборота через кассу, при отгрузке, при приёмке, при обычной проверке через сервис. Сообщение об ошибке верификации появляется тогда, когда присланная строка опознана как код маркировки, но подпись пересчитать не удалось.
Из чего состоит код маркировки
| Группа (AI) | Что содержит | Длина значения | Обязательность |
|---|---|---|---|
| 01 | GTIN – глобальный номер товара | 14 цифр | Всегда |
| 21 | Серийный номер экземпляра | 13 символов (табак – 7) | Всегда |
| 91 | Ключ проверки (указывает, каким ключом подписан код) | 4 символа | Криптохвост |
| 92 | Значение крипто-подписи в Base64 | 44 символа | Криптохвост |
| 8005 / 93 | МРЦ и код проверки для табачной продукции | 6 цифр + 4 символа | Только табак |
Группы 01 и 21 вместе дают 31 символ – ту самую «базу», которую видно на большинстве скриншотов из учётных систем. Группы 91 и 92 – криптохвост. Между группами переменной длины стоит служебный разделитель GS (Group Separator, ASCII 29). На экране он невидим, в отчётах 1С иногда отображается пустым квадратом, а в JSON-запросе кодируется как \u001d.
Что именно проверяет оператор ГИС МТ
Подпись из группы 92 вычисляется от строки, куда входят GTIN, серийный номер и служебные данные. Изменение хотя бы одного символа в базовой части, потеря разделителя или усечение самой подписи приводят к тому, что пересчитанное значение расходится с переданным. Система в этом случае не может отличить повреждённый при передаче код от подделки и возвращает отрицательный результат верификации – поведение по умолчанию консервативное.
Где в 1С появляется это сообщение
- На кассе в «1С:Рознице» и «Управлении торговлей» при сканировании товара в чек – продажа блокируется разрешительным режимом.
- В документе «Вывод из оборота» и «Списание товаров» при попытке отправить коды.
- В «Отгрузке товаров» / «Приёмке» при формировании УПД с кодами маркировки.
- В обработке «Проверка кодов маркировки» (раздел «Маркировка» → сервисные команды) – здесь ошибка видна изолированно, без привязки к документу.
- В журнале обмена с ГИС МТ, если документ ушёл, а квитанция вернулась с отказом.
Важно отделить эту ошибку от проблем со связью. Когда обмен вообще не устанавливается, формулировки другие – например, 1С сообщает, что не удалось запросить данные ГИС МТ. Ошибка верификации, наоборот, подтверждает, что канал работает и ответ от оператора получен.
Почему код маркировки не проходит проверку подписи: сводная таблица
Ниже – причины, с которыми реально сталкиваются торговые точки и склады, с признаками и порядком устранения. Таблицу удобно использовать как маршрутизатор: сначала определяем признак, потом идём в нужный раздел.
| Причина | Как проявляется | Как проверить | Что делать |
|---|---|---|---|
| Криптохвост обрезан сканером | Ошибка на всех кодах подряд, на любом товаре | Длина строки в поле кода – 31 символ | Перенастроить сканер, включить полную передачу буфера |
| Потерян разделитель GS | Код «склеился», группы 91/92 не распознаются | В строке нет пустого служебного символа между блоками | Включить режим GS1 DataMatrix и передачу ASCII 29 |
| Эмуляция клавиатуры с русской раскладкой | Ошибка плавающая, зависит от рабочего места | Скан в «Блокнот» даёт кириллицу вместо латиницы | Перевести сканер в режим COM-порта или зафиксировать раскладку |
| Код введён вручную или скопирован из Excel | Единичные коды, чаще при пересорте | В строке нет спецсимволов, часть Base64 потеряна | Пересканировать этикетку физически |
| Символы Base64 искажены при передаче | Ошибка только у части кодов партии | В хвосте пропали символы +, /, = | Проверить кодировку выгрузки, перейти на UTF-8 |
| Этикетка повреждена или перепечатана | Ошибка по конкретным экземплярам | Тот же код не читается мобильным приложением | Перемаркировать товар, заказать новый КМ |
| Код из демо-контура попал в продуктив | Массовая ошибка после тестов интеграции | Настройки обмена указывают на тестовый стенд | Переключить учётную систему на боевой контур |
| Смешаны группы 91/92 от разных кодов | Ошибка после ручной сборки кодов из выгрузки | Один и тот же хвост у нескольких серийников | Отказаться от ручной склейки, работать с целым КМ |
| Устаревший релиз конфигурации или библиотеки маркировки | Ошибка появилась после изменений на стороне оператора | Релиз конфигурации старше полугода | Обновить конфигурацию и библиотеку интеграции |
Первые три строки таблицы закрывают основную массу обращений. Они объединены общим свойством: сам код маркировки корректен, а до оператора доезжает его искалеченная копия.
Как настроить сканер, чтобы криптохвост доходил до 1С?
Сканер штрихкода в связке с маркировкой работает иначе, чем при обычной торговле. Ему нужно прочитать двумерный символ, сохранить служебные разделители и отдать строку целиком, не отрезая «лишнее». Многие модели из коробки настроены на компактный вывод и молча усекают данные после определённой длины.
Порядок действий
- Откройте паспорт или карту настроек конкретной модели – параметры задаются сканированием служебных штрихкодов из инструкции производителя.
- Включите поддержку символики DataMatrix и режим GS1. Без второго пункта сканер читает картинку, но не понимает структуру групп.
- Задайте передачу разделителя GS как символа с кодом 29. В разных прошивках параметр называется «GS character», «Function code 1» или «AIM identifier».
- Снимите ограничение на длину передаваемой строки. Если стоит лимит в 32 или 64 символа, криптохвост обрежется гарантированно.
- Переведите сканер в режим виртуального COM-порта, если конфигурация это поддерживает. Режим «эмуляция клавиатуры» зависит от активной раскладки и фокуса окна.
- В 1С откройте «Администрирование» → «Подключаемое оборудование», выберите рабочее место, откройте карточку сканера и нажмите «Тест устройства». В окне теста видно полную строку с разделителями.
- Отсканируйте один код в поле проверки и сравните длину: около 85 символов – норма, 31 символ – криптохвост потерян.
Отдельно стоит проверить промежуточное ПО. Терминалы сбора данных, кассовые оболочки и RDP-сессии иногда фильтруют управляющие символы на своём уровне. Если тест устройства в 1С показывает полный код, а в документ попадает усечённый, разбираться нужно с транспортом между ними.
Как проверить код маркировки вручную?
Ручная проверка нужна, чтобы отделить проблему сканера от проблемы самого кода. Три независимых способа дают разную глубину диагностики.
Мобильное приложение «Честный знак»
Самый быстрый тест. Приложение сканирует этикетку камерой смартфона и показывает результат проверки подписи вместе с карточкой товара. Если приложение показывает код как корректный, а учётная система ругается на верификацию – этикетка в порядке, дефект в канале передачи. Если приложение тоже сообщает об ошибке – код повреждён физически либо эмитирован некорректно.
Личный кабинет ГИС МТ
В личном кабинете есть поиск по коду идентификации и раздел проверки кодов. Строку сюда лучше вставлять из журнала обмена учётной системы – так проверяется ровно то, что уходило оператору. Результат по конкретному экземпляру содержит статус, владельца, дату эмиссии и признак блокировки.
Сервис проверки в самой 1С
В типовых конфигурациях раздел «Маркировка» содержит команду проверки кодов. Обработка отправляет строку в сервис оператора и возвращает расшифровку по каждому реквизиту: найден ли код, в обороте ли он, принадлежит ли организации, прошла ли крипто-подпись. Этот инструмент удобен тем, что показывает исходную строку в том виде, в каком её хранит база.
Если при проверке 1С сообщает о проблемах авторизации вместо ошибки с подписью – это другой сценарий. Диагностика по нему разобрана в материалах о ситуации, когда 1С перестаёт видеть токен, и о случаях, когда не удаётся подключиться к сервису.
Что происходит под капотом: эндпоинты, запрос и ответ
Этот раздел пригодится, когда разговор переходит к подрядчику или в техподдержку. Понимание структуры обмена сокращает переписку в разы.
Эндпоинты
| Назначение | Контур | Адрес |
|---|---|---|
| Основной узел ГИС МТ | Продуктив | https://markirovka.crpt.ru |
| Станция управления заказами | Продуктив | https://suz.crpt.ru |
| Демонстрационный стенд | Тест | https://markirovka.demo.crpt.tech |
| Получение данных для подписи | Оба | GET /api/v3/auth/cert/key |
| Обмен подписи на токен | Оба | POST /api/v3/auth/cert/ |
| Проверка кодов маркировки | Оба | POST /api/v3/true-api/codes/check |
Пример запроса
curl -X POST "https://markirovka.crpt.ru/api/v3/true-api/codes/check" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"codes":["0104607412345678215Yl!qMkBw0Phs\u001d91EE10\u001d92dGVzdFNpZ25hdHVyZUJhc2U2NFBhZGRpbmdYWVo="]}'
Обратите внимание на \u001d – это тот самый разделитель GS. Когда интеграция передаёт код без него, строка формально уходит, но группы 91 и 92 оператор прочитать не может. Сегмент пути true-api всегда пишется латиницей – любая замена символов даёт 404.
Пример ответа
{
"codes": [
{
"cis": "0104607412345678215Yl!qMkBw0Phs",
"found": true,
"valid": false,
"verified": false,
"utilised": false,
"isBlocked": false,
"gtin": "04607412345678",
"printView": "0104607412345678215Yl!qMkBw0Phs",
"errorCode": 0
}
],
"reqId": "f3c1a0e2-77b4-4d1a-9a0f-2b7e6c0d1a55",
"reqTimestamp": 1758000000000
}
Модели данных: что означают поля
| Поле | Смысл | Что означает «плохое» значение |
|---|---|---|
cis | Код идентификации в том виде, как его понял оператор | Короче ожидаемого – строка усечена |
found | Код найден в базе ГИС МТ | false – код не эмитирован или из другого контура |
verified | Результат проверки крипто-подписи | false – та самая ошибка верификации |
valid | Итоговая пригодность кода к операции | false – операция будет отклонена |
utilised | Код уже выведен из оборота | true при продаже – повторное выбытие |
isBlocked | Код заблокирован оператором | true – разбирательство через личный кабинет |
printView | Человекочитаемое представление | Отсутствие групп 91/92 – криптохвост не дошёл |
errorCode | Технический код обработки запроса | Ненулевое значение – сбой на стороне сервиса |
Тестовые коды и демо-контур
Коды, выпущенные на демонстрационном стенде, подписаны ключами тестового контура. В продуктиве они дают ровно ту же ошибку верификации, и наоборот. Типовая история: интегратор настраивал обмен на демо-стенде, отладил документы, а адрес сервиса в настройках обмена остался тестовым – после чего вся смена уходит в отказы. Проверяется это за минуту: в настройках интеграции с ГИС МТ смотрим адрес сервиса и убеждаемся, что домен боевой. Для тестирования сценариев берите коды, эмитированные в том же контуре, где ведётся проверка, и не переносите их между стендами.
Найдите специалиста для решения этой задачи на koderion.ru