Встроить электронную подпись через API: схемы и форматы

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

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

Разберём, какой контейнер отдавать наружу (p7s, sig, CAdES-T, PAdES), что писать в журнал подписания, чтобы подпись пережила срок действия сертификата, и в каких случаях встраивание требует оценки влияния среды функционирования на СКЗИ. Покажем, какие данные проверяет алгоритм в МЧД и что меняется для филиала. Тарифы и сроки подключения на 2026 год, чек-листы диагностики и ответы на частые вопросы — во второй половине статьи.

Содержание

Три способа встроить подпись: клиент, сервер, облако

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

Клиентская схема означает, что ключ остаётся у пользователя на токене или в реестре, а браузер обращается к криптопровайдеру через плагин. Серверная схема переносит операцию в ваш контур: токен с обезличенным сертификатом подключён к серверу, сервис принимает документ по REST и возвращает подпись. Облачная схема отдаёт хранение ключа внешней системе электронной подписи, а ваш сервис общается с ней по SOAP, REST или HTTP API, подключая свои механизмы аутентификации через OAuth 2.0, WS-Federation и SAML 1.1/2.0.

Схема встраивания Где закрытый ключ Что интегрируете Ограничение
Браузерный плагин Токен или контейнер на машине пользователя Плагин, встроенный в КриптоПро CSP 5.0 R3, вызовы из JavaScript Нужны установленный криптопровайдер и совместимый браузер на каждом рабочем месте
Облегчённый криптопровайдер в браузере Токен или смарт-карта пользователя КриптоПро CSP Lite: библиотеки, реализующие функции CSP и браузерного плагина Набор поддерживаемых токенов настраивается под конкретный веб-ресурс
Серверная подпись в своём контуре Токен на сервере организации REST-сервис подписи и проверки, разворачивается из docker-образов Обезличенным сертификатом можно подписывать не все документы, сотрудники им пользоваться не могут
Облачная система электронной подписи Сервер удостоверяющего центра или оператора SOAP, REST или HTTP API, аутентификация через OAuth 2.0, WS-Federation, SAML 1.1/2.0 Облачную подпись используют только там, где интегрировано ПО удостоверяющего центра
Мобильное приложение подписания Смартфон пользователя, ключ создаётся в приложении API-ключ вендора по агентскому договору либо собственный API-ключ организации Свой API-ключ требует обезличенного сертификата, который руководитель выпускает лично и на год

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

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

Факт: в КриптоПро CSP 5.0 R3 добавлен КриптоПро SDK для встраивания подписи, включая усовершенствованную, и обращения к службам штампа времени и проверки статусов сертификатов. Браузерный плагин входит в состав этой версии, поддержка TLS 1.3 с российской криптографией заявлена по классу КС1.

Какой вид подписи вы имеете право использовать в своём сервисе

Виды ЭЦП разграничены 63-ФЗ, и подменять их друг другом нельзя: ПЭП подтверждает факт формирования подписи конкретным лицом, УНЭП дополнительно фиксирует неизменность документа после подписания, УКЭП работает на сертификате аккредитованного удостоверяющего центра и приравнена к собственноручной подписи по умолчанию. Для ПЭП и УНЭП юридическая сила появляется не из кода, а из соглашения сторон: пока соглашение об использовании простой и неквалифицированной подписи не подписано, ваш сервис формирует технически корректный, но юридически пустой контейнер.

В кадровом контуре у этого правила есть исключение, которое сильно упрощает интеграцию. По части 2 статьи 22.3 ТК РФ работник может использовать УНЭП, полученную через единую систему идентификации и аутентификации, и отдельное соглашение об использовании УНЭП с ним подписывать не требуется. Правила создания и использования такого сертификата установлены постановлением Правительства РФ от 1 декабря 2021 года № 2152. Для удалённого приёма это единственный способ получить подпись работника, который никогда не появится в офисе.

Мария Ж, соучредитель сервиса КЭДО Добыто: «Когда мы выбираем подпись для интеграции, первым делом смотрим не на API, а на то, придётся ли собирать бумажное соглашение с каждым работником. УНЭП через единую систему идентификации снимает этот шаг: по части 2 статьи 22.3 ТК РФ соглашение об использовании подписи с работником не подписывается. Проверьте по своему процессу, сколько людей вы физически не увидите в офисе, и считайте это нижней границей доли мобильного подписания.»

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

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

Схема взаимодействия вендора и потребителя с инфраструктурой электронного правительства при подписании
Обмен между вашим сервисом и инфраструктурой электронного правительства идёт по каналу с ГОСТ TLS, а полномочия и передача персональных данных оформляются до первого вызова API.

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

Токены, ключи и криптопровайдер: что на самом деле держит вашу подпись

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

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

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

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

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

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

Отдельная развилка — режим работы с носителем. Формат PKCS#11 удобен тем, что он открытый: любой софт, который встраивает библиотеку PKCS#11, перечислит ключи на гостовом токене и получит информацию о сертификате, независимо от того, какой криптопровайдер стоит на машине. Режим с невыводимым ключом и защитой канала между провайдером и токеном даёт более высокий уровень защиты, но замыкает вас на КриптоПро CSP версии 5.0 и выше. Режим обратной совместимости, наоборот, позволяет использовать один и тот же ключ на машинах со старым провайдером, что критично, если пользователи носят токен между рабочими местами.

Лайфхак: на токене со 128 КБ защищённой памяти помещается до 31 контейнера в формате извлекаемых программных ключей, а один контейнер с большими сертификатами и цепочками занимает до 12 КБ. Считайте ёмкость носителя до массовой выдачи ключей, а не после.

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

Форматы контейнера: p7s, sig, CAdES и PAdES

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

Разбор внутренней структуры контейнера подписи CMS PKCS#7 по блокам для разработчика
Что реально лежит внутри файла подписи: цепочка сертификатов, список отзыва и блок SignerInfo со штампом времени.

Расширение файла к формату отношения не имеет. В параметрах подписания обычно доступны пять вариантов расширения: sig, p7s, sgn, sign и bin, и это один и тот же контейнер под разными именами. Проблема возникает на стыке систем: принимающая сторона нередко валидирует не содержимое, а расширение, и отвергает корректный файл. Если ваш API отдаёт подпись наружу, зафиксируйте расширение в спецификации и не меняйте его от версии к версии.

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

Проверьте, что ваш сервис отдаёт валидный контейнер

Добыто · Проверка подписи

Что за файл пришёл с документом

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

Файл остаётся на вашем устройстве — мы его не получаем и не храним

Нет файла под рукой? Выберите расширение вручную:

Проверить подпись онлайн в Добыто

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

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

Серверная подпись обезличенным сертификатом: что нужно собрать

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

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

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

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

  1. Шаг 1. Определите вид подписи под каждый тип документа. Разнесите документы по видам подписи и зафиксируйте, где достаточно ПЭП по соглашению, где нужна УНЭП, а где только УКЭП. Документы, которые по закону нельзя перевести в электронный вид, выносятся из контура сразу.
  2. Шаг 2. Выберите место хранения ключа. Клиентский токен, серверный обезличенный сертификат или облачная система подписи. От этого зависит, будете вы встраивать плагин, разворачивать сервис в контуре или интегрироваться по внешнему API.
  3. Шаг 3. Оформите правовую часть до кода. Соглашение об использовании ПЭП и НЭП, согласия на обработку персональных данных, регламент обмена документами, а для представителей юрлица — машиночитаемая доверенность с нужными кодами полномочий.
  4. Шаг 4. Соберите тестовый контур. Разверните сервис подписи, подключите токен, прогоните подписание и проверку на всех форматах, которые вы обещаете в API: откреплённая, присоединённая, PDF со встроенной подписью, пакетная подпись.
  5. Шаг 5. Настройте усовершенствование подписи и журналирование. Добавьте штамп времени и ответ о статусе сертификата на момент подписания, включите сохранение результатов проверки в базу и выгрузку протокола в PDF.
  6. Шаг 6. Проверьте требования к встраиванию СКЗИ. Уточните, попадает ли ваш сценарий под оценку влияния среды функционирования, и заложите эту процедуру в план проекта до релиза, а не после первой проверки.

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

Кейс из практики: в проекте на 1100 сотрудников после перевода кадровых процессов на электронную подпись цикл по одному процессу занял 15-30 минут против нескольких недель на бумаге, а экономия на выпуске подписей составила около 0,5 млн рублей в год. Основной эффект дал не сам факт подписания, а то, что маршрут документа собран в одном окне и не требует ручной пересылки файлов.

МЧД в интеграции: какие данные проверяет алгоритм

Машиночитаемая доверенность — это XML-файл, подписанный квалифицированной подписью доверителя. Скачать её можно и в виде PDF, но работает она только как электронный документ: без программы, которая разберёт структуру, доверенность бесполезна. Логика простая: документ подписывает сотрудник своей подписью физического лица, а к подписи прикладывается МЧД, подтверждающая полномочия.

Схема передачи полномочий через машиночитаемую доверенность от руководителя сотруднику
Цепочка из трёх звеньев: подпись руководителя на доверенности, сама МЧД с перечнем полномочий и подпись сотрудника на документе.

Главные данные МЧД для вашего парсера — это сведения о доверителе, о представителе, срок действия и коды полномочий. Полномочия берутся из классификатора, где у каждого пункта есть код, дата и уникальный идентификационный номер; именно код включается в доверенность. Классификатор размещён в Единой системе нормативной справочной информации. Смысл кодов в том, что доверенность читает не человек, а алгоритм: система автоматически сверяет, покрывают ли полномочия конкретный документ и вправе ли это лицо его подписывать.

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

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

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

Шаблоны и формы для интеграции подписи в сервис

Комплект закрывает правовую и эксплуатационную часть проекта; начинать удобнее с соглашения об использовании ПЭП и НЭП, без него подпись в вашем сервисе остаётся технической.

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

Журнал подписания и хранение: подпись должна пережить сертификат

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

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

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

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

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

Ошибки интеграции и их цена

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

Вторая по частоте — расхождение форматов между отправителем и получателем. Ваш сервис отдаёт корректный CMS-контейнер с расширением sgn, принимающая система ждёт p7s и отклоняет файл. Переименование пачки файлов скриптом решает вопрос за минуты, но обнаруживается это обычно на боевом потоке.

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

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

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

Когда встраивать подпись через API не нужно

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

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

Наконец, электронная почта с шифрованием по S/MIME закрывает узкую задачу конфиденциального обмена файлами и письмами, но не заменяет документооборот: маршрутов согласования, статусов и архива там нет.

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

Стоимость зависит от численности сотрудников, набора видов подписи и того, нужны ли интеграция с 1С, выделенный сервер и собственные API-сценарии.

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

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

Платформа соответствует требованиям 377-ФЗ, статей 22.1-22.3 Трудового кодекса РФ и 152-ФЗ о персональных данных, а подписи ПЭП и УНЭП для сотрудников выпускаются без отдельной оплаты на любом тарифе.

Выводы

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

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

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

Сотрудник потерял токен и не помнит пин-код. Можно ли восстановить его подпись?

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

Чем расширения p7s, sig и sgn отличаются друг от друга при выгрузке из API?

Содержимым — ничем, это один и тот же контейнер CMS. В параметрах подписания доступно пять вариантов расширения: sig, p7s, sgn, sign и bin. Различие проявляется на приёмной стороне: многие системы валидируют файл по расширению и отклоняют корректную подпись с непривычным именем. Зафиксируйте расширение в спецификации API и не меняйте его между версиями, а для массового переименования держите скрипт наготове.

Как отправлять подписанные документы письмом и защищать вложения?

Для писем используется стандарт S/MIME: подпись по ГОСТ 2012, шифрование по ГОСТ 2015 с алгоритмами «Магма» и «Кузнечик». Почтовый клиент подключается по IMAP, SMTP и POP3, а соединение с сервером требуется защищённое по ГОСТ. Важное ограничение: если у получателя нет средства обработки таких сообщений или почтовый клиент не поддерживает гостовый S/MIME, он увидит только зашифрованное вложение и прочитать письмо не сможет.

Может ли доверенность выдать филиал и допустимо ли передоверие?

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

Что обязательно писать в журнал подписания?

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

Сколько сертификатов помещается на один токен?

На носителе со 128 КБ защищённой памяти помещается до 31 контейнера в формате извлекаемых программных ключей. Точное число зависит от того, что удостоверяющий центр записал в расширения сертификата: один объёмный контейнер с установленными цепочками занимает до 12 КБ, минимальный — порядка 200 байт. Если планируете выдавать сотрудникам по несколько сертификатов на носитель, считайте ёмкость по фактическому размеру ваших контейнеров.

Нужна ли отдельная лицензия на криптопровайдер для веб-сервера с ГОСТ?

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

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

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

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

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

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

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

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

Поделиться:

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

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