Подлинность ЭЦП: 4 проверки, CRL, OCSP и штамп TSP

Мария Ж. 17 мин чтения

Подлинность ЭЦП подтверждают четыре независимые проверки: хэш документа совпадает со значением внутри контейнера подписи, значение подписи разбирается открытым ключом из сертификата подписанта, цепочка сертификации выстраивается до корневого сертификата аккредитованного удостоверяющего центра, статус сертификата на момент подписания подтверждается списком отзыва CRL или ответом службы OCSP. Пятый элемент, штамп времени TSP, нужен, когда документ переживёт срок действия сертификата. Главное различие для проверяющего: присоединённая подпись лежит одним файлом вместе с документом, откреплённая требует пары файлов, и исходный документ должен совпадать байт в байт, иначе проверка упадёт на первом же шаге.

Разберём, что лежит в контейнере CMS/PKCS#7 и почему расширение p7s, sig или sgn ничего не говорит о содержимом. Покажем, где ломается проверка на практике: отсутствующий корневой сертификат, недоступные адреса CRL и OCSP, сертификат тестового удостоверяющего центра, правка XML после подписания. Отдельно разберём проверку полномочий по МЧД и разницу между извлекаемыми и неизвлекаемыми ключами на токенах Рутокен, JaCarta и ЕСМАРТ. Пошаговая диагностика невалидной подписи, сценарная таблица по носителям, тарифы на 2026 год и ответы на частые вопросы — во второй половине статьи.

Проверьте свой файл в форме ниже: она показывает подписанта, серийный номер сертификата, издателя и алгоритмы, работает и с присоединённой, и с откреплённой подписью.

svg%3e Проверка электронной подписи

Покажем, кто и когда подписал документ и действует ли сертификат. Без регистрации.

1 Выберите вид подписи:

2 Загрузите документ и файл подписи:

Документ

Файл подписи (.sig)

Нужно подписать документ?

Подпишите прямо в браузере через КриптоПро. На PDF можно поставить штамп в нужном месте.

Подписать документ

Содержание

Четыре проверки, из которых складывается подлинность ЭЦП

Штамп подписи на первой странице PDF и надпись «Документ подписан электронной подписью» не проверяются ничем: это изображение, которое рисует средство подписи или сама информационная система. Криптографическая проверка идёт по другому маршруту и состоит из независимых шагов, каждый из которых может пройти или упасть отдельно от остальных. Подпись бывает математически верной при полностью недействительном сертификате, и наоборот.

Пожалуйста, подпишитесь на нас в мессенджерах

Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.

Канал в MAX Канал в Telegram

Корги указывает на кнопки подписки на каналы Добыто

Ниже — разбор по слоям: что именно сверяется, чем это ломается и каким инструментом смотреть результат.

Что проверяется Механизм Что ломает проверку
Целостность документа Хэш документа по ГОСТ сверяется со значением, зафиксированным в блоке SignerInfo контейнера Любая правка файла после подписания, пересохранение PDF, изменение XML на один символ
Авторство Значение подписи разбирается открытым ключом из сертификата, вложенного в контейнер Подмена сертификата в контейнере, несоответствие ключевой пары
Доверие к сертификату Цепочка сертификации выстраивается от сертификата владельца до корневого сертификата удостоверяющего центра Корневой сертификат не установлен в хранилище, сертификат выпущен тестовым удостоверяющим центром
Актуальность сертификата Статус запрашивается по адресам списков отзыва CRL и службы OCSP, указанным в самом сертификате Сертификат отозван, адреса CRL и OCSP недоступны из закрытого контура
Время подписания Штамп времени TSP от службы штампов времени, вложенный в подпись В подписи только заявленное время, которое задаёт клиент, а сертификат уже истёк
Полномочия подписанта Машиночитаемая доверенность в формате XML, подписанная УКЭП руководителя МЧД отозвана, полномочия расширены без выпуска новой доверенности

Из таблицы следует практический порядок разбора: сначала смотрят, совпал ли хэш, и только потом идут в карточку сертификата. Если хэш не сошёлся, разбираться с цепочкой доверия бессмысленно — проверять нечего.

Что лежит внутри файла подписи: CMS, PKCS#7 и расширения p7s, sig, sgn

Контейнер откреплённой подписи — это структура CMS (PKCS#7), в которой лежат версия контейнера, идентификатор алгоритма хэширования по ГОСТ, инкапсулированный контент, список отозванных сертификатов, блок сертификатов подписанта X.509 с цепочкой доверия и блок SignerInfo. В SignerInfo хранятся само значение подписи, заявленное время подписания, штамп времени TSP и профиль усовершенствования. Расширение файла в эту структуру не входит.

Схема устройства контейнера подписи CMS PKCS#7 с блоком SignerInfo и штампом времени
Состав контейнера: всё, что проверяющая программа разбирает, лежит внутри одного файла подписи.

Присоединённая подпись хранит подписанные данные внутри контейнера, поэтому проверяющему нужен один файл. Откреплённая подпись хранит только хэш и служебные блоки, поэтому передавать нужно пару: документ и файл подписи рядом. Пара работает только при полном совпадении исходного файла: пересохранение PDF в другой программе, конвертация кодировки XML или добавление пробела в конец текстового файла меняют хэш и обнуляют подпись.

Важный нюанс из практики: расширение файла подписи задаётся настройкой средства подписи, а не стандартом. В параметрах Инструментов КриптоПро расширение выбирается из списка p7s, sig и sgn, в КриптоАРМ ГОСТ доступны пять вариантов: sig, p7s, sgn, sign и bin. Внутри всех этих файлов один и тот же CMS-контейнер, поэтому файл .sgn от контрагента открывается штатными средствами после переименования в .sig. Скриптом PowerShell партия в 1500 файлов переименовывается за один проход.

Мария Ж, специалист по цифровой подписи и КЭДО: «Когда получатель пишет, что подпись не открывается, в половине случаев проблема в имени файла, а не в криптографии. Сначала посмотрите, что за файл вам пришёл: присоединённая подпись, откреплённая или архив с парой. Открепленную подпись без исходного документа проверить нельзя в принципе, поэтому просить у контрагента «нормальный файл» бесполезно — просите второй файл из пары».

Сертификат: цепочка доверия, CRL и OCSP

Сертификат X.509 связывает открытый ключ с владельцем и содержит служебные адреса, по которым проверяющая программа сама ходит за статусом. В карточке сертификата видны алгоритм открытого ключа и хэш-алгоритм по ГОСТ, отпечаток, идентификаторы ключей, адреса списков отзыва и службы OCSP, а ниже — блок цепочки сертификации со статусами каждого звена.

Карточка сертификата с адресами CRL и OCSP и блоком цепочки сертификации
Адреса CRL и OCSP зашиты в сам сертификат: по ним проверяющая сторона запрашивает статус отзыва.

Разница между CRL и OCSP влияет на инфраструктуру. Список отзыва — файл, который скачивается целиком и обновляется с периодичностью удостоверяющего центра, поэтому свежеотозванный сертификат какое-то время выглядит действующим. OCSP отвечает по конкретному серийному номеру в момент запроса. В закрытом контуре без доступа к этим адресам проверка встанет на статусе, а программа покажет, что построить цепочку не удалось: это ошибка сети, а не подделка подписи.

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

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

Факт: сертификат отозванного ключа в карточке помечается прямо: «Сертификат недействителен. Сертификат отозван», рядом остаются серийный номер, данные издателя и сроки действия сертификата и закрытого ключа. Эти реквизиты и нужно фиксировать в протоколе проверки.

Сверить результат своей программы с независимым источником можно на портале Госуслуг: там работает сервис проверки электронной подписи и сертификатов, который принимает и присоединённую подпись, и пару из документа с файлом .sig. В Добыто.Подпись проверка идёт в браузере и заканчивается протоколом, где перечислены подписант, серийный номер, издатель и алгоритмы по ГОСТ.

Корги указывает на кнопки подписки на каналы Добыто

Пожалуйста, подпишитесь на нас в мессенджерах

Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.

Канал в MAX Канал в Telegram

Время подписания: заявленное значение против штампа TSP

Заявленное время в SignerInfo формируется на стороне подписанта и меняется вместе с системными часами. Доказательную силу даёт штамп времени TSP: его выдаёт независимая служба штампов времени и подписывает своим сертификатом. Второй элемент доказательства — вложенные OCSP-ответы, подтверждающие статус сертификата именно на момент подписания.

Профили усовершенствования наращиваются последовательно: CAdES-BES содержит подпись владельца и хэш, CAdES-T добавляет штамп времени TSA, CAdES-A — архивную метку с периодическим переподписанием, которая позволяет хранить документ десятилетиями, вплоть до пятидесяти лет для отдельных категорий.

Наращивание форматов подписи CAdES-BES, CAdES-T и CAdES-A со штампом времени и архивной меткой
Каждый следующий уровень добавляет доказательства, которые переживают срок действия сертификата подписанта.

Мария Ж, соучредитель сервиса КЭДО Добыто: «Кадровый документ живёт дольше сертификата, которым он подписан. Если подпись осталась на уровне CAdES-BES, через несколько лет проверяющий увидит истёкший сертификат и не сможет доказать, что на момент подписания он действовал. Мы закладываем усовершенствование подписи до формата со штампом времени сразу, на этапе настройки маршрутов, а не когда документ уже уехал в архив».

Усовершенствование делается и постфактум: подпись формата CMS или CAdES-BES дотягивается до CAdES-T и дальше средствами, которые умеют обращаться к службе TSP. Разворачивают такой сервис и внутри контура организации — в виде докер-образа, который проверяет входящие подписи фоном, складывает результаты в базу и формирует протоколы в PDF. По опыту вендоров, около 80% запросов на автоматизацию криптографии касаются именно проверки и усовершенствования подписи, оставшиеся 20% — шифрования и расшифрования.

Где хранится закрытый ключ: КриптоПро CSP, токены и режимы работы

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

Носители ключа электронной подписи Рутокен, JaCarta и ЕСМАРТ с назначением каждой модели
Рутокен S, Рутокен Лайт, Рутокен ЭЦП 3.0, JaCarta-2 SE и ГОСТ, ЕСМАРТ: выбор носителя определяется режимом работы ключа, а не брендом.

Режим выбирается в момент создания контейнера, в выпадающем списке считывателя. Дальше он определяет совместимость: пассивный контейнер прочитает любой криптопровайдер линейки, ключ с защитой канала — только версия, где эта поддержка появилась.

Сценарий Что критично Что вторично
Ключ используется на разных рабочих станциях, часть из них со старым провайдером Пассивный извлекаемый контейнер: он читается КриптоПро CSP версии 4.0 и выше Модель токена: подойдёт любой носитель, совместимый с криптопровайдером
Требуется максимальная защита ключа от копирования Формат ФКН с защитой канала по протоколу SESPAKE, КриптоПро CSP 5.0 R2 и выше, актуальная модель Рутокен ЭЦП 3.0 Обратная совместимость со старыми версиями провайдера
Работа в ЕГАИС для производителей и поставщиков алкоголя Только формат PKCS#11: другие форматы для этой системы не подойдут Выбор между защитой канала и производительностью
Подпись должна считаться квалифицированной, ключ генерируется на борту токена Сертификация носителя во ФСБ России Объём памяти носителя
Токен применяется только как хранилище извлекаемых ключей Достаточно сертификации во ФСТЭК Наличие криптоядра в микроконтроллере

Отдельная деталь, которая регулярно всплывает при разборе: криптография на борту токена не заменяет установленный на компьютере КриптоПро CSP. Если информационная система требует этот криптопровайдер, его ставят на рабочее место и вводят лицензию. В сертификатах, выпущенных в рамках пилотного проекта удостоверяющего центра ФНС России, лицензия вшивается внутрь сертификата и действует столько же, сколько сам сертификат.

Полезно знать: в удостоверяющем центре ФНС России извлекаемый ключ выдают только в неэкспортируемом контейнере, скопировать его регламент не позволяет. Первичная выдача идёт лично, ключ пишется на токен без права копирования.

Учёт ключей ведётся отдельно от техники. Журнал ЭЦП в виде реестра выданных токенов и реестра сертификатов сотрудников показывает, у кого какой носитель, когда истекает сертификат и в каком режиме создан контейнер. В практике Добыто этот реестр закрывает основную часть вопросов при увольнении сотрудника и плановом перевыпуске: без него сроки истекают неожиданно, а носитель остаётся на руках у бывшего работника.

Образцы документов для проверки подписи и учёта сертификатов

Комплект закрывает разбор невалидной подписи и учёт ключей: начните с чек-листа диагностики, протокол пригодится, когда результат проверки нужно приложить к делу.

Документ Скачать
Чек-лист диагностики «Подпись не валидна» Скачать
Протокол проверки электронной подписи (образец) Скачать
Машиночитаемая доверенность: образец и структура XML Скачать
Адреса служб штампов времени TSP Скачать
Реестр сертификатов сотрудников Скачать

Полномочия подписанта: что технически проверяется в МЧД

Сертификат физического лица не содержит сведений о принадлежности к организации, поэтому полномочия подтверждаются отдельным документом — машиночитаемой доверенностью. МЧД — это XML-файл, подписанный электронной подписью руководителя организации; состав сведений задан приказом 857, формат XML — приказом 858, порядок формирования классификатора полномочий — приказом 856. Переходный период по 63-ФЗ закончился 1 сентября 2023 года; сертификаты, выданные до 31 августа 2023 года, действовали до конца своего срока, но не позднее 31 августа 2024 года.

С точки зрения проверки МЧД устроена как ещё один слой доказательств. Проверяющая система сверяет, что персональные данные представителя в доверенности совпадают с данными в сертификате, которым подписан документ, и запрашивает статус доверенности в распределённом реестре ФНС. Прямой связки между сертификатом и МЧД нет: доверенность выдаётся на свой срок, и за пять лет её действия представитель может сменить несколько сертификатов, это ничему не противоречит.

Внимание: любое изменение XML-файла доверенности ломает подпись под ним. Если сотруднику в течение года добавили полномочия, это не правка старой МЧД, а выпуск новой.

Полномочия внутри доверенности указываются кодом из классификатора либо текстом. Текстовые формулировки автоматически не проверяются: ни одна информационная система не возьмётся за лингвистический разбор фразы вроде «подписание договоров аренды на сумму до определённого предела». Из неформализованного PDF-договора вытащить эти данные тоже нельзя, поэтому проверка полномочий машиной пока работает на формализованных документах и кодах классификатора.

Мария Ж, юрист со стажем более 20 лет: «Полные сведения о доверенности на сервисе ФНС отдаются только тому, кто знает три параметра: 36-символьный номер МЧД, ИНН доверителя и СНИЛС представителя. Это и есть штатный способ проверки, когда контрагент прислал документ со штампом доверенности, а полномочия в штампе не раскрыты. Запросите у него эти три значения сразу, вместе с документом».

Отдельный случай — передоверие. Нотариальное удостоверение не требуется, когда доверенность выдаётся от юрлица юрлицу и когда цепочка идёт через руководителя обособленного филиала. Во всех остальных вариантах, включая передачу полномочий внутри одной организации, доверенность заверяется нотариально, и МЧД здесь не исключение.

Что делать, если подпись не проходит проверку

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

Как разобрать невалидную подпись: пошаговая инструкция

  1. Шаг 1. Определите тип файла. Присоединённая подпись проверяется одна, для откреплённой нужен исходный документ. Если пришёл архив, распакуйте и посмотрите, что внутри.
  2. Шаг 2. Проверьте расширение. Файл .sgn или .bin переименуйте в .sig и повторите проверку: содержимое контейнера от имени файла не зависит.
  3. Шаг 3. Сверьте исходный документ. Запросите у отправителя тот самый файл, который подписывали, без пересохранения и конвертации.
  4. Шаг 4. Откройте карточку сертификата. Посмотрите статус, сроки действия, издателя и цепочку сертификации: разрыв в цепочке лечится установкой корневого сертификата удостоверяющего центра.
  5. Шаг 5. Проверьте доступность CRL и OCSP с той машины, где идёт проверка. Из закрытого контура эти адреса часто недоступны, и статус не строится по сетевой причине.
  6. Шаг 6. Проверьте тот же файл вторым независимым средством. Расхождение результатов указывает на локальную настройку, совпадение — на реальную проблему с подписью.
  7. Шаг 7. Зафиксируйте результат протоколом проверки с серийным номером сертификата, издателем и датой, и переходите к переподписанию документа.

Кейс из практики: бухгалтерия получала от контрагента файлы с расширением .sgn и не могла проверить подпись штатными средствами, документы копились неделями. Массовое переименование в .sig скриптом PowerShell на партии в 1500 файлов сняло проблему за один проход, содержимое контейнеров при этом не менялось. Отдельной памяткой закрыли повторные обращения: получатель теперь понимает, почему приходит два файла и что с ними делать.

Лайфхак: при откреплённой подписи держите документ и файл .sig в одной папке и передавайте их одним архивом. Пара «договор.pdf» и «договор.pdf.sig» читается любым средством проверки без вопросов, кто к кому относится.

Во что обходится непроверенная подпись

Ошибка обходится дороже, чем повторное подписание документа. Оператор ЭДО не доставляет документ, если подпись не прошла проверку по формальным критериям: сертификат выдан аккредитованным удостоверяющим центром, срок действия не истёк, подпись соответствует подписываемому документу, структура сертификата отвечает требованиям приказа ФСБ. Дальше начинается гражданско-правовая часть: проверка полномочий контрагента — обязанность принимающей стороны, и подписание неуполномоченным лицом становится риском при оспаривании сделки. Документ, подписанный сертификатом сотрудника с привязкой к юрлицу после окончания переходного периода, юридически ничтожен, даже если технически подпись валидна.

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

Когда технической проверки подписи недостаточно

Валидная подпись подтверждает три вещи: документ не менялся после подписания, он подписан владельцем конкретного сертификата, сертификат был действующим. За пределами этого списка криптография не отвечает ни за что.

  • Полномочия. Валидная подпись физического лица без МЧД не подтверждает право подписывать документ от имени организации.
  • Содержание документа. Подпись фиксирует байты, а не смысл: ошибка в реквизитах или сумме останется в подписанном документе.
  • Время, если нет штампа TSP. Заявленное время подписания формируется на стороне клиента и доказательством не является.
  • Долговременное хранение. Подпись уровня CAdES-BES перестаёт проверяться после истечения сертификата: нужны штамп времени, OCSP-ответы и архивная метка.
  • Вид подписи под кадровым документом. Проверка покажет, что подпись верна, но не скажет, допускался ли этот вид подписи для этого документа по статьям 22.1-22.3 ТК РФ.

Мария Ж, судебный эксперт в сфере корпоративного и трудового права: «Спор почти никогда не идёт о математике подписи. Спорят о том, кто и на каком основании подписывал, и был ли сертификат действующим в тот день. Поэтому в комплект доказательств кладут не только сам файл подписи, но и протокол проверки с серийным номером сертификата и данными издателя, а по представителю — ещё и сведения о доверенности».

Стоимость подключения КЭДО и работы с электронной подписью

Стоимость зависит от численности сотрудников, набора видов подписи и потребности в интеграции с учётной системой.

Услуга Стоимость Сроки
Тариф «Старт»: до 25 сотрудников, ПЭП и УНЭП, базовые шаблоны от 30 ₽ за сотрудника / мес подключение за 5 минут
Тариф «Бизнес»: без ограничения по численности, ПЭП, УНЭП и УКЭП, электронный архив от 50 ₽ за сотрудника / мес подключение за 5 минут
Минимальная оплата по тарифу «Бизнес» (50 сотрудников) 30 000 ₽ в год
Тариф «Корпорация»: выделенный сервер, SLA 99.9%, API и кастомные интеграции по запросу по запросу
Выпуск подписей ПЭП и УНЭП для сотрудников входит в тариф
УКЭП через партнёров-удостоверяющих центров рассчитывается индивидуально
Модуль интеграции с 1С:ЗУП входит в тариф «Бизнес» установка и настройка за 1 день
Онлайн-проверка электронной подписи бесплатно, без регистрации

Итоговый счёт складывается из численности и выбранного набора функций: интеграция с 1С, электронный архив и приоритетная поддержка входят в тариф «Бизнес», выделенный сервер и SLA считаются отдельно. Действующие условия и состав каждого пакета собраны на странице тарифов ДОБЫТО КЭДО, там же указано, что подписи для сотрудников выпускаются в рамках тарифа.

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

Выводы

Техническая подлинность ЭЦП складывается из совпавшего хэша, корректной ключевой пары, выстроенной цепочки доверия и подтверждённого статуса сертификата на момент подписания. Штамп времени TSP и архивная метка переводят подпись в разряд документов, которые переживут срок действия сертификата, а МЧД добавляет проверку полномочий, которой в самой криптографии нет. Расширение файла, штамп на странице PDF и надпись о подписании доказательствами не являются.

В Добыто мы закрываем эту цепочку на стороне процесса: вид подписи закрепляется за типом кадрового документа, маршруты согласования настраиваются под оргструктуру, а по каждому подписанию остаётся протокол проверки, который можно выгрузить и приложить к делу.

Частые вопросы

Чем отличаются файлы p7s, sig и sgn

Содержимым — ничем: во всех трёх случаях это контейнер CMS/PKCS#7. Расширение задаётся настройкой средства подписи: в Инструментах КриптоПро выбор идёт из списка p7s, sig и sgn, в КриптоАРМ ГОСТ доступны пять вариантов, включая sign и bin. Проблемы возникают только на приёмной стороне, когда программа привязана к конкретному расширению; переименование файла содержимое не меняет и подпись не портит.

Можно ли проверить подпись, если сертификат уже истёк

Да, если в подпись вложены доказательства момента подписания: штамп времени TSP и OCSP-ответ о статусе сертификата на тот момент. Это форматы CAdES-T и выше. Подпись уровня CAdES-BES после истечения сертификата проверить корректно не получится, поэтому для архивного хранения подписи усовершенствуют до формата с архивной меткой и периодическим переподписанием.

Почему подпись валидна в одной программе и невалидна в другой

Различаются локальные условия проверки: набор корневых сертификатов в хранилище, доступ к адресам CRL и OCSP из сети, поддержка конкретного профиля усовершенствования. Отдельный случай — сертификат тестового удостоверяющего центра: подпись при этом математически верна, но статус будет «недействительна», потому что корень цепочки не аккредитован. Расхождение результатов двух средств проверки указывает на настройку рабочего места.

Как подписать электронной подписью письмо, а не файл

Для этого нужен почтовый клиент с поддержкой S/MIME по ГОСТ. Такой встроенный клиент есть, например, в КриптоАРМ ГОСТ 3: письмо и вложения подписываются и шифруются вместе. Если у получателя нет ГОСТ-поддержки, он увидит вложенный контейнер и не сможет его открыть без установки соответствующего программного обеспечения.

Что делать, если пин-код от токена забыт или токен потерян

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

Нужна ли токену сертификация ФСБ России

Зависит от режима. Если носитель работает как защищённое пин-кодом хранилище извлекаемых ключей, достаточно сертификации во ФСТЭК. Если ключ генерируется внутри токена его собственным криптоядром, для признания подписи квалифицированной нужна сертификация во ФСБ России.

Как быстро проверить сразу большой пакет подписанных документов

Ручная проверка на потоке не работает, поэтому проверку выносят в сервис: он принимает файлы фоном, разбирает присоединённые и откреплённые подписи, складывает результаты в базу и формирует протоколы в PDF. Такое решение разворачивают в собственном контуре организации из докер-образа, интерфейсом может быть веб-форма, REST-запросы или бот. Для разовых задач достаточно онлайн-проверки по одному файлу.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 5 / 5. Количество оценок: 1

Оценок пока нет. Поставьте оценку первым.

Сожалеем, что вы поставили низкую оценку!

Позвольте нам стать лучше!

Расскажите, как нам стать лучше?

Поделиться:

Попробуйте ДОБЫТО КЭДО

Подписывайте кадровые документы электронно. Оставьте заявку и начните работу.