Ошибка при верификации цифровой подписи файла sap ноты

Часовой пояс: UTC + 3 часа

Правила форума

ВНИМАНИЕ! Прежде чем задавать вопрос, ознакомьтесь со ссылками ниже:

Вы новичок и хотите узнать, что такое SAP и как он устроен в целом — вам сюда
Вопросы по файлам .kep, воспроизведению курсов SAP — сюда
Вопросы по базису (установке и администрированию SAP, ролям и полномочиям) — сюда
Вопросы по SAP Front End (SAPlogon, SAPgui, guiXT и т.д.) — сюда
Вопросы по LSMW — сюда
Вопросы по SAP Business Workplace (почте SAP) и SAP Office — сюда
Вопросы по miniSAP (SAP mini basis) — сюда
Вопросы по лицензированию продуктов SAP — сюда
Вопросы, связанные со студенческими работами по тематике SAP — сюда

Подписание документов средствами ЭЦП по сертификату с более, чем с 1 областью действия/использования

Страница 1 из 1

[ Сообщений: 3 ]

Для печати

Пред. тема | След. тема ->

Автор

Сообщение

AlexanderOmsk

Начинающий

Зарегистрирован:
Пн, сен 02 2013, 06:01
Сообщения: 5

Коллеги, добрый день!
Система SAP, версия 7.40. Отправка внебиржевых сделок из SAP на Санкт-Петербургскую международную товарно-сырьевую биржу средствами ЭЦП.
В связи с окончанием срока действия сертификата был выпущен новый сертификат удостоверяющего центра (УЦ) РДК, который объединяет теперь две области действия (Клиент биржа и Клиент РДК).
Ранее было два сертификата с разграничением по соответствующим областям действия.
При использовании нового сертификата во внутренней системе Компании по регистрации внебиржевых сделок столкнулись с техническими ошибками, которые препятствуют подписывать и передавать сведения на биржу по внебиржевым сделкам.
При попытке подписания пользователем возникает следующая ошибка:

По коду ФМ SSF_SIGN её вызывает:

В FILL_SIGTAB_RFC мы посчитали кол-во строк таблицы SIGNER, далее если их > 1 => ошибка.
Таблицу SIGNER в ФМ SSF_SIGN передаем из ZCL_OTC->SSF_SIGN и тут, передается всегда только 1 строка.

Ошибка возникла после смены сертификата.
Особенность нового сертификата в том, что он имеет 2 области действия, в то время как предыдущие имели только одну (слева – старый, справа — новый).

Мы видим, что вызывается функция SSFSIGN. Это исполняемый файл из папки с SAP Logon: C:\Program Files (x86)\SAP\FrontEnd\SapGui

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

Подскажите, пожалуйста, может кто-то сталкивался с такой проблемой, что нужно сделать, чтобы функционал отрабатывал?
Может быть нужно обновить патч для SAP Logon? Поддерживает ли КриптоПро несколько областей действия сертификата?
Т.к. такой сертификат вышел совсем недавно, может-быть необходимо установить какие-то патчи или обновления на ПО КриптоПро?
Пока непонятно, в каком направлении двигаться для исправления ситуации.
Спасибо!

Вернуться к началу

Kengur

Почетный гуру

Зарегистрирован:
Чт, дек 20 2007, 18:21
Сообщения: 1529

_________________
я твой сап эфай внедрял
BAdI-позитив

Вернуться к началу

AlexanderOmsk

Начинающий

Зарегистрирован:
Пн, сен 02 2013, 06:01
Сообщения: 5

Спасибо Вам за помощь!
Вопрос решен. Разобрались благодаря трассировке.
Ошибка возникала из-за непечатаемого символа (байта) в начале отпечатка.
Убрали его в NotePad++, скопировали и вставили в таблицу базы данных.
При ручном вводе, этот непечатаемый символ (байт) так же сохранялся. Проблема исчезла только тогда, когда непечатаемый символ убрали в редакторе.

К сожалению, отладки у нас нет, и решение этого вопроса у нас заняло много времени.

Вернуться к началу

Страница 1 из 1

[ Сообщений: 3 ]

Часовой пояс: UTC + 3 часа

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Логотип © 2006 Андрей Горшков
Поддержка: Кирилл Андреев, 2011-…

Источник

Применение ЭЦП в web-шаблонах SAP NetWeaver

Статья посвящена выполненной мной достаточно нетривиальной задаче по интеграции электронной цифровой подписи в веб-шаблоны SAP (Business Explorer Web Application), работающие в SAP NetWeaver.
Заранее извиняюсь, если в статье будут допущены ошибки в терминологии или в логике.

Общие сведение об ЭЦП можно получить в википедии ЭЦП

В чем заключалась задача

Есть SAP NetWeaver в роли хранилища данных Business Warehouse.
Все данные хранятся в кубах. В кубах же хранятся документы. Документом, по сути, является набор строк куба, имеющих одинаковый признак – номер документа. Работа с данными построена на базе веб-шаблонов Business Explorer Web Application. Содержимое документов отображаются в компоненте analisys item.

Несколько слов для незнакомых с Bex Web. Технология веб-шаблонов (веб форм) по сути напоминает собой ASP.NET. В дизайнере создаешь макет формы, используя компоненты, схожие с ASP (dataGrid, button и прочее). Навешиваешь с помощью мастеров обработчики событий (это могут быть определенные команды или произвольный ABAP код). При запуске веб-формы – она обрабатывается на сервере и клиенты отдается HTML страничка с JS. Реакция на действия пользователя – производиться на стороне сервера при обновлении страницы. В коде веб-шаблона обычно нет необходимости генерировать HTML, как в PHP.

В некой web-форме пользователи вводят данные в таблицу, представленную analisys item. Введенные данные сохраняются в куб. После ввода данных пользователь должен поменять их статус (например, со статуса «Новый» на «Обработано»: перевод статуса происходит с помощью функции repost по значениям признака хранящего статусы данных; этот признак также находится в этом же кубе).
Так вот, необходимо подписывать введенные данные с помощью ЭЦП после ввода/сохранения данных и перед тем, как пользователь переведет эти данные со статуса «Новый» на «Обработано» (подписывать должен тот пользователь, который ввел данные).

Поиск в сети показал, что использовать ЭЦП не так то просто, как хотелось бы. В большинстве стран существуют собственные законодательные акты, регулирующие применение средств криптозащиты. Федеральный закон Российской Федерации от 10 января 2002 г. N 1-ФЗ «Об электронной цифровой подписи»
В частности устанавливаются алгоритмы, которые должны применяться при шифровании и генерации подписи. Например, алгоритм формирования и проверки электронной цифровой подписи ГОСТ Р 34.10-2001

Конечно же, не имеет смысла самим пытаться реализовать данные алгоритмы, поэтому смотрим, что предлагается на рынке.
Например, решения «ЛИССИ»
http://www.lissi.ru/solution/

Позиционируют себя спасителями на белом коне для SAP’овцев.Комплекс софта от них обойдется в сумму, превышающую 300 000 рублей. Программное обеспечение представляет собой API для продуктов SAP, обращаться к которому можно посредством ABAP.
Проблема в том, что данные продукты подразумевают подписание данных посредством кода ABAP. На клиенте же мы имеем только веб-страницу c JS. Исполнить код ABAP можно только на сервере, например с помощью AJAX запроса. Но возникает проблема – закрытый ключ пользователя доступен только на клиенте. Его пересылка на сервер не должна осуществляться. Решение «ЛИССИ» подразумевает работу на клиентской машине полновесного, не тонкого, клиента SAP, в котором возможно выполнение ABAP.
Поэтому я отказался от готовых решений и реализовал ЭЦП через CAPICOM CAPICOM

Реализация ЭЦП

Здесь описание того, как реализовал ЭЦП

1 Порядок применения ЭЦП

1) Администратор безопасности регистрирует сертификат в базе сертификатов. Сертификат необходимо получить от подлинного удостоверяющего центра.

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

3) При последующих просмотрах документа, подпись проверяется при открытии документа. Подпись извлекается из БД. Над подписью и содержимым документа проводятся криптографические операции верификации подписи.

4) Администратор безопасности может добавлять сертификаты пользователей в базу сертификатов, приостанавливать временно или постоянно их действие.

2 Реализация хранения данных

Подписи хранятся в плоской таблице «Подписи».

База сертификатов – набор из двух плоских таблиц:

Ключи – собственно сертификаты. В таблице храниться привязанный к ключу пользователь, дата начала и конца действия ключа, сам ключ, статус (блокирован или нет), описание.

Приостановки – набор возможных приостановок действия ключа. Хранит дату начало, конца и описание приостановки. Также хранит ID приостановленного ключа.

3 Архитектура системы цифровой подписи

Механизм цифровой подписи построен на основе следующих компонентов.
1) ActiveX компонент для доступа к криптографическому API. (CAPICOM)
2) С помощью JS получаем содержимое документа
3) Вызовом метода ActiveX компонента подписать данные.
4) Отправить подпись на сервер (классу ABAP) с целью разместить в базе подписей.

CAPICOM – библиотека от MS, предоставляющая интерфейс к крипто провайдерам.
1 – посредством JS кода, происходят обращения к библиотеке CAPICOM
2 – Веб шаблон формирует данные для подписи (XML, описывающий DataProvider).
3 – Полученная подпись, посредством AJAX передается ABAP классу, осуществляющему сохранение подписи в плоскую таблицу.
4 – взаимодействие крипто провайдера с eToken происходит автоматически.

4 Реализация API

Класс Signer – реализует пользовательские методы –
Подписать, проверить подпись, получить последнюю подпись
Класс CryptoProvider – враппер для Capicom.
ZCL_AJAX_DIG_SIGN – реализация интерфейсных методов через Ajax.
Z_DIGITAL_SIGNER – реализация методов сохранения и поиска подписи, методов проверки действительности публичного ключа по базе ключей.

5 Дополнительно словесное описание

Рассмотрим порядок подписания\проверки документа.

Пользователь жмет на форме кнопку «Утвердить(сохранить) документ». JS собирает с с html кода шаблона контент документа, предварительно выгруженный туда. Обращается к CAPICOM, который просит у человека выбрать нужный сертификат. При выборе сертификата сделанного под криптоПро специально для работы в системе – CAPICOM обратиться к провайдеру КриптоПРО, тот же попросит токен с закрытым ключом. Когда токен вставят – контент документа будет подписан. Подпись по AJAX кидается в BSP приложение, оно передает подпись в интерфейсный класс Z_DIGITAL_SIGNER. Класс проверит сертификат из подписи, факт того, что именно такой сертификат привязан к данному залогинившемуся пользователю. В случае успеха проверки – запишет подпись в базу подписей. На форме произойдут изменения – появиться отметка о успешной подписи.

При открытии документа другим пользователем –появиться статус подписания. Это произойдет следующим образом. JS по AJAX запросит подписи для документа, получит подпись (априорно – она сделана нужным человеком и подпись сделана сертификатом из базы разрешенных сертификатов). Затем js дергает CAPICOM — метод «верификация подписи» с параметрами «подпись» и «контент документа». Если с документом и подписью все в порядке – метод вернет true, следовательно, документ подписан и корректен.
Также есть GUI для администратора безопасности – ведение базы активных сертификатов.

Подключение ЭЦП к веб-шаблону

1) подключить в XHTML веб шаблона ActiveX компонент CAPICOM, например

2) Создать новый провайдер данных с тем же запросом, что и основной. То есть, сделать копию провайдера. Таким образом получим выгруженный документ в HTML, который будем подписывать. Нельзя подписывать провайдер, который выводит документ в таблицу пользователя, потому что, при сортировки или фильтрации таблицы — данные в провайдеры будут меняться, а нам нужен документ в начальном виде.

3) Разместить на форме компонент «провайдер данных-информация».
Назовем его DATA_PROVIDER_TO_SIGN.

Синим- компонент «провайдер данных-информация», красным — он же в палитре компонентов, желтым — провайдер данных, поставляющий контент документа

4) Укажем в настройках DATA_PROVIDER_TO_SIGN:
Провайдер данных: Укажем созданную в шаге 2 копию провайдера.
Статус навигации — вывод: Off
Данные отчета: вывод: On

5) Размещаем на форме код
Здесь уже все зависит от вашей фантазии. Не буду постить ВЕСЬ свой код, включающий AJAX, ABAP, JavaScript, оставлю только простенький врапер для CAPICOM, который я сделал на основе примеров с сайта Microsoft.

И пример его использования
Подписание

Источник

Ошибка при верификации цифровой подписи файла sap ноты

Квалифицированная электронная подпись по ГОСТ