Комментарии 11
Добрый день.
Инфа не для холивара.
Не только через NCALayer, можно взаимодействовать и подписывать.
Я под 1С написал, всё работает.
Автор молодец, я допустим не пишу статьи.
Добрый день,
Да, согласен, в SDK НУЦ присутствует несколько сертифицированных библиотек, можно пользоваться ими. Но статья сфокусирована на ИС на базе веб технологий, для этого сценария НУЦ предоставляет NCALayer.
Смею предположить что вы используете Java библиотеку — на сколько мне известно, поддержка токенов и карт реализована только в ней.
Правда, как установить, что конкретная электронная подпись была создана с помощью конкретного ПО — задача не всегда решаемая. Т.е. все на усмотрение судьи и судебного эксперта.
У меня руководство было против внедрения ЭСФ в 1С, так как ключи хранятся, по сути, в открытом виде. Пришлось вместе с бухгалтером уговаривать, так как через веб интерфейс работать с большим объемом первички просто не реально.
Подскажите, пожалуйста, почему ключи должны храниться в открытом виде? В частности по какой причине не получается использовать токены или карты?
Весьма странно, что NCALayer не умеет добавлять OCSP проверки в подписи.
Кстати можно писать собственные модули и регистрировать их. Уже кто только не добавился.
Не хотите написать свой модуль, который будет на стороне клиента подписывать документы и сразу регистрировать в SIGEX?
По поводу модуля для NCALayer — это интересная идея.
Для подписания файлов на данный момент существует SIGEX Desktop for Windows и ему для работы нужен NCALayer. Если же писать свой модуль, то можно будет расширить функционал — к примеру реализовать подписание нескольких файлов одним махом.
Подпихните в нужную сторону, пожалуйста.
И вот еще вопрос, сможет ли обычный разработчик-любитель, работающий для себя и в своё удовольствие, получить комплект разработчика?
Добрый день,
Для подписания достаточно NCALayer, комплект разработчика НУЦ не обязателен. Как я писал в статье, подписать можно командой createCAdESFromBase64
. Имейте в виду что после того, как NCALayer получит сообщение, он отобразит несколько окон для: выбора файлового хранилища (в том случае, если указан тип хранилища 'PKCS12'
), ввода пароля/ПИН, выбора сертификата в хранилище.
Вы можете все это испробовать в живую на странице https://kaztoken.kz/mobile-docs/ — достаточно выбрать в меню слева createCAdESFromBase64
и нажать на кнопку отправки запроса внизу справа (NCALayer должен быть локально запущен).
Но важный момент заключается в том, что подписывать автоматически не правильно — это противоречит законодательству: Закрытые ключи электронной цифровой подписи не могут быть переданы другим лицам.
(http://adilet.zan.kz/rus/docs/Z030000370_).
Автоматически подписывать документы сертификатами НУЦ не хорошо по следующим причинам:
- речь идет о юридически значимой подписи, но подписывающий (сам человек) не имеет представления о том, что именно он подписывает — все равно что заставить человека не глядя подписывать документы, причем не просто не глядя, а принудительно запретить ему просматривать что именно он подписывает;
- стандартные сертификаты юридических и физических лиц не ограничены в применении какими-то информационными системами, то есть если каким-то образом ваша система вместо документа для университета сформирует договор дарения квартиры (в ИТ всякое бывает), то он так же будет автоматически подписан и будет иметь юридическую значимость — квартира перейдет другому собственнику;
- в том случае, если кто-то имеет доступ к серверу вашей системы, то он сможет получить доступ и к закрытому ключу — то есть как минимум сможет воспользоваться им (а то и скопировать себе в том случае, если ключ в файловом хранилище, а не на токене или карте).
Очень много рисков для того, кто передаст свой ключ ЭЦП для автоматизации подписания.
По хорошему Вам стоит поступить так:
- реализовать интерфейс автоматизирующий формирование документов и отображение их пользователям;
- в этом интерфейсе реализовать интеграцию с NCALayer — то есть дать пользователям возможность просматривать и подписывать сформированные документы;
- сформированную подпись проверять на стороне вашего сервера (в соответствии с законодательством РК не проверенная подпись юридической значимости не имеет).
Вы можете взять все эти задачи на себя, либо ограничиться первой а для всего остального использовать готовое решение, к примеру https://sigex.kz (он бесплатный, не требует регистрации). В этом случае будет примерно следующая схема:
- Ваша система формирует документ в каком-то формате (к примеру PDF или DOC или XLSX — как Вам удобнее);
- пользователь получает этот документ (скачивает с вашего веб интерфейса, либо получает готовый по почте, либо получает сразу на файловой системе в том случае, если ваша система — это десктопное приложение);
- пользователь подписывает документ через веб интерфейс https://sigex.kz, либо с помощью приложения SIGEX Desktop for Windows (https://sigex.kz/support/sigex-desktop-for-windows/);
- в процессе подписания пользователь указывает электронный адрес университета для отправки уведомления (вероятно еще какой-то адрес для хранения отчетности на вашей стороне);
- сервис проверяет подпись в соответствии с законодательством и отправляет уведомления о подписании в университет и остальным указанным получателям.
И вот еще вопрос, сможет ли обычный разработчик-любитель, работающий для себя и в своё удовольствие, получить комплект разработчика?
На это я Вам ответить не смогу — я не знаю какие у НИТ критерии. Попробуйте отправить им запрос (https://pki.gov.kz/developers/), думаю они Вас проконсультируют.
Интеграция ЭЦП НУЦ РК в информационные системы на базе веб технологий