Статус: Активный участник
Группы: Участники
Зарегистрирован: 18.08.2014(UTC) Сообщений: 90   Сказал «Спасибо»: 21 раз
Поблагодарили: 9 раз в 9 постах
|
Решил не создавать отдельную тему, т.к. вопрос о возможном влиянии КриптоПро ЭЦП Browser plug-in актуальной версии 2.0.13064 при генерации запроса на сертификат в одной из программ казначейства - СУФД. Если у кого-то из уважаемых сотрудников КриптоПро этого форума есть доступ к форуму ФК, то не сочтите за труд - почитайте, пожалуйста, сообщения на том форуме в разделе "Информационные технологии - Удостоверяющий центр Федерального казначейства" тему "Средство создания запроса (СУФД)", начиная с поста по ссылке: http://forum.roskazna.ru...25&start=180#p306887В последних сообщениях коллеги стали почти с уверенностью обвинять в ошибке именно КриптоПро ЭЦП Browser plug-in версии 2.0.13064. Если у Вас есть какая-то практика по данной проблеме - поделитесь здесь хотя-бы мыслями (возможно и фактами) по выяснению причины. Будем очень благодарны всем откликнувшимся! Отредактировано пользователем 4 декабря 2017 г. 18:44:54(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 09.11.2017(UTC) Сообщений: 5 Сказал(а) «Спасибо»: 3 раз
|
Здравствуйте, такой вопрос. Работаем со СМЭВ3, создаем attachment (файл) к SOAP запросу для отправки посредством MTOM+XOP с которого надо снять pkcs7 detached подпись. Им требуется снимать хеш с файла (узнать о чем было отдельным приключением) в формате HEX Гостом 34_11-94 - это мы делаем на сервере с помощью CSP и передаем на сторону клиента (подписывать надо клиентским сертификатом). Здесь мы пытаемся подписать detached pkcs7 подписью полученный хеш. Примерный вызов такой (в переменной dataToSign лежит хеш, для взятия сертификата есть отдельная функция, просто мы подписываем не только файл, в СМЭВ3 чет вообще дофига подписей поэтому цапаем его не 1 раз): Код:oCertificate = yield getCertificate_Async();
var oSigner = yield cadesplugin.CreateObjectAsync("CAdESCOM.CPSigner");
yield oSigner.propset_Certificate(oCertificate);
var oSignedData = yield cadesplugin.CreateObjectAsync("CAdESCOM.CadesSignedData");
yield oSignedData.propset_Content(dataToSign);
var sSignedMessage = yield oSignedData.SignCades(oSigner, CADESCOM_CADES_BES, true);
Результат в смеве возвращает ошибку 60: свяжитесь с ослужбой тенической поддержки. Однако зная скорость их ответа ищем решение сами. Так вот на портале https://www.gosuslugi.ru/pgu/eds/ сделанная подпись проверку не проходит. Пробовали так же снимать не с хеша, а с содержимого файла (получаем функцией file_get_contents на сервере, потом base64_encode чтобы переслать клиенту, потом на клиенте декодим и в качестве даты суем в плагин), проверку так же не проходит. Если подписывать файл с помощью cryptopro ARM от цифровых технологий - проверка проходится нормально (вариант подписи любой - без коневого, с корневым или только текущим). Можете подсказать в чем может быть проблема? Сертификат один и тот же, Другие части сообщения (наложение ЭП СП) нареканий со стороын СМЭВ не вызывают, ошибок не валится, но там подпись RawSignature. Отредактировано пользователем 5 декабря 2017 г. 14:05:08(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
|
Автор: Mikhail123  Здравствуйте, такой вопрос. Работаем со СМЭВ3, создаем attachment (файл) к SOAP запросу для отправки посредством MTOM+XOP с которого надо снять pkcs7 detached подпись. Им требуется снимать хеш с файла (узнать о чем было отдельным приключением) в формате HEX Гостом 34_11-94 - это мы делаем на сервере с помощью CSP и передаем на сторону клиента (подписывать надо клиентским сертификатом). Здесь мы пытаемся подписать detached pkcs7 подписью полученный хеш. Примерный вызов такой (в переменной dataToSign лежит хеш, для взятия сертификата есть отдельная функция, просто мы подписываем не только файл, в СМЭВ3 чет вообще дофига подписей поэтому цапаем его не 1 раз): Код:oCertificate = yield getCertificate_Async();
var oSigner = yield cadesplugin.CreateObjectAsync("CAdESCOM.CPSigner");
yield oSigner.propset_Certificate(oCertificate);
var oSignedData = yield cadesplugin.CreateObjectAsync("CAdESCOM.CadesSignedData");
yield oSignedData.propset_Content(dataToSign);
var sSignedMessage = yield oSignedData.SignCades(oSigner, CADESCOM_CADES_BES, true);
Результат в смеве возвращает ошибку 60: свяжитесь с ослужбой тенической поддержки. Однако зная скорость их ответа ищем решение сами. Так вот на портале https://www.gosuslugi.ru/pgu/eds/ сделанная подпись проверку не проходит. Пробовали так же снимать не с хеша, а с содержимого файла (получаем функцией file_get_contents на сервере, потом base64_encode чтобы переслать клиенту, потом на клиенте декодим и в качестве даты суем в плагин), проверку так же не проходит. Если подписывать файл с помощью cryptopro ARM от цифровых технологий - проверка проходится нормально (вариант подписи любой - без коневого, с корневым или только текущим). Можете подсказать в чем может быть проблема? Сертификат один и тот же, Другие части сообщения (наложение ЭП СП) нареканий со стороын СМЭВ не вызывают, ошибок не валится, но там подпись RawSignature. Для получения подписи по хэш значению вам нужна другая функция подписи (у обьекта CadesSignedData метод SignHash() http://cpdn.cryptopro.ru...03ca56afabeb9c82387.html ). Хеш передается так же как в примере http://cpdn.cryptopro.ru...mples-raw-signature.htmlОтредактировано пользователем 5 декабря 2017 г. 17:52:37(UTC)
| Причина: Не указана |
|
 1 пользователь поблагодарил Анатолий Беляев за этот пост.
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
|
Автор: Alex_04 Решил не создавать отдельную тему, т.к. вопрос о возможном влиянии КриптоПро ЭЦП Browser plug-in актуальной версии 2.0.13064 при генерации запроса на сертификат в одной из программ казначейства - СУФД. Если у кого-то из уважаемых сотрудников КриптоПро этого форума есть доступ к форуму ФК, то не сочтите за труд - почитайте, пожалуйста, сообщения на том форуме в разделе "Информационные технологии - Удостоверяющий центр Федерального казначейства" тему "Средство создания запроса (СУФД)", начиная с поста по ссылке: http://forum.roskazna.ru...25&start=180#p306887В последних сообщениях коллеги стали почти с уверенностью обвинять в ошибке именно КриптоПро ЭЦП Browser plug-in версии 2.0.13064. Если у Вас есть какая-то практика по данной проблеме - поделитесь здесь хотя-бы мыслями (возможно и фактами) по выяснению причины. Будем очень благодарны всем откликнувшимся! К сожалению у нас нет доступа на указанный форум. |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 18.08.2014(UTC) Сообщений: 90 Сказал «Спасибо»: 21 раз
Поблагодарили: 9 раз в 9 постах
|
Автор: cross Автор: Alex_04 Если у кого-то из уважаемых сотрудников КриптоПро этого форума есть доступ к форуму ФК... К сожалению у нас нет доступа на указанный форум. Тогда постараюсь здесь коротко суть проблемы. В казначейском ППО "СУФД" можно сгенерировать запрос на сертификат ЭП (ФИО.req). Но при его создании выходит ошибка внутри файла: в спец. ПО УЦ ФК для получения сертификата видно, что в строке со значениями СНИЛС и ИНН заявителя они разделены символом " ," (запятая) вместо " ;" (точка с запятой). ПО УЦ ФК не пропускает такой файл, считая что в данной строке не 2 параметра (СНИЛС;ИНН), а один (СНИЛС) с неверными атрибутами. Самое непонятное - ошибка выходит не у всех, а как будто "выборочно". Стали искать причину путем пробных генераций в "СУФД" на разных версиях ОС и КриптоПро. Вначале было подозрение, что виной КриптоПро версии 4.0.9842, но по дальнейшим отзывам это не подтвердилось. А затем стали писать, что: Цитата:чудит КриптоПро ЭЦП Browser plug-in. Подтвердилось экспериментально на АРМ казначейства после установки плагина и удаления Java. Цитата:сформировал запрос в СУФД под КриптоПро-4 без плагина, через java. Запрос нормальный, с разделителем ';' Цитата:конкретно на моей машине стоял КриптоПро ЭЦП Browser plug-in 2.0.13064. А если версия 2.0.12888 или нет его вообще, то генерация происходит через java плагин без ошибки в файле Вот, собственно, и весь расклад по проблеме. Если информации недостаточно - пишите, постараюсь дополнить по мере возможности. Проблема очень волнует в силу того, что КриптоПро ЭЦП Browser plug-in сейчас чуть-ли не обязателен для установки при работе во многих (если не во всех) ИС ФК. И если без него дальше действительно будет невозможно работать, то очень хотелось-бы знать: может-ли криптоплагин актуальной на данный момент версии 2.0.13064 действительно приводить к некорректной работе "генератора" запроса на сертификат ЭП, или это в принципе невозможно?P.S: обещал коротко, но уж как получилось, сори.
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 09.11.2017(UTC) Сообщений: 5 Сказал(а) «Спасибо»: 3 раз
|
Автор: cross По поводу подписания вроде понял (кроме того где в методе указывать что подпись должна быть detached), спасибо, сегодня попробую. По поводу хеша уточните вот какой момент: 1. То что я получаю с помощью csp в php на сервере совпадает с хешем полученным с помощью cpverify (выложена на сайте госуслуг). 2. То что я получаю посредством асинхроной версии указанного вами примера с тем что отдает прога с госуслуг - не совпадает. Функция: Код:function createHash_Async(data) {
return new Promise(function (resolve, reject) {
cadesplugin.async_spawn(function* (args) {
try {
let oHashData = yield cadesplugin.CreateObjectAsync('CAdESCOM.HashedData');
yield oHashData.DataEncoding = cadesplugin.CADESCOM_BASE64_TO_BINARY;
yield oHashData.Algorithm = cadesplugin.CADESCOM_HASH_ALGORITHM_CP_GOST_3411;
yield oHashData.Hash(data);
args[0](oHashData);
}
catch (err) {
D3Api.notify('Ошибка', 'Не удалось создать хэш: ' + Form.GetErrorMessage(err), {'expires': false});
args[1]();
}
}, resolve, reject);
});
}
Вызываю ее примерно так: Код:
let oHashData = yield createHash_Async(fileData);
let hashValue = yield oHashData.Value;
В итоге в hashValue оказывается вроде хеш в формате как надо но он не совпадает. В fileData лежит base64 с file_get_contents (содержимое файла в binary, полученое на сервере с которого на сервере же хеш снимается правильно). Я правильно понял что в oHashData.Hash(data); при таком вызове надо класть именно base64 с подписываемого? Отредактировано пользователем 6 декабря 2017 г. 9:41:16(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
|
Автор: Alex_04 Автор: cross Автор: Alex_04 Если у кого-то из уважаемых сотрудников КриптоПро этого форума есть доступ к форуму ФК... К сожалению у нас нет доступа на указанный форум. Тогда постараюсь здесь коротко суть проблемы. В казначейском ППО "СУФД" можно сгенерировать запрос на сертификат ЭП (ФИО.req). Но при его создании выходит ошибка внутри файла: в спец. ПО УЦ ФК для получения сертификата видно, что в строке со значениями СНИЛС и ИНН заявителя они разделены символом " ," (запятая) вместо " ;" (точка с запятой). ПО УЦ ФК не пропускает такой файл, считая что в данной строке не 2 параметра (СНИЛС;ИНН), а один (СНИЛС) с неверными атрибутами. Самое непонятное - ошибка выходит не у всех, а как будто "выборочно". Стали искать причину путем пробных генераций в "СУФД" на разных версиях ОС и КриптоПро. Вначале было подозрение, что виной КриптоПро версии 4.0.9842, но по дальнейшим отзывам это не подтвердилось. А затем стали писать, что: Цитата:чудит КриптоПро ЭЦП Browser plug-in. Подтвердилось экспериментально на АРМ казначейства после установки плагина и удаления Java. Цитата:сформировал запрос в СУФД под КриптоПро-4 без плагина, через java. Запрос нормальный, с разделителем ';' Цитата:конкретно на моей машине стоял КриптоПро ЭЦП Browser plug-in 2.0.13064. А если версия 2.0.12888 или нет его вообще, то генерация происходит через java плагин без ошибки в файле Вот, собственно, и весь расклад по проблеме. Если информации недостаточно - пишите, постараюсь дополнить по мере возможности. Проблема очень волнует в силу того, что КриптоПро ЭЦП Browser plug-in сейчас чуть-ли не обязателен для установки при работе во многих (если не во всех) ИС ФК. И если без него дальше действительно будет невозможно работать, то очень хотелось-бы знать: может-ли криптоплагин актуальной на данный момент версии 2.0.13064 действительно приводить к некорректной работе "генератора" запроса на сертификат ЭП, или это в принципе невозможно?P.S: обещал коротко, но уж как получилось, сори. Обвинять другой софт это уже традиция :). К сожалению без возможности глянуть как они создают(код страницы) запрос мы врядли сможем чем то помочь. Через наш плагин запросы на сертификат создают несколько площадок, в данный момент ни одного обращения к нам по поводу ошибок при генерации запроса нет. |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
|
Автор: Mikhail123 Автор: cross По поводу подписания вроде понял (кроме того где в методе указывать что подпись должна быть detached), спасибо, сегодня попробую. По поводу хеша уточните вот какой момент: 1. То что я получаю с помощью csp в php на сервере совпадает с хешем полученным с помощью cpverify (выложена на сайте госуслуг). 2. То что я получаю посредством асинхроной версии указанного вами примера с тем что отдает прога с госуслуг - не совпадает. Функция: Код:function createHash_Async(data) {
return new Promise(function (resolve, reject) {
cadesplugin.async_spawn(function* (args) {
try {
let oHashData = yield cadesplugin.CreateObjectAsync('CAdESCOM.HashedData');
yield oHashData.DataEncoding = cadesplugin.CADESCOM_BASE64_TO_BINARY;
yield oHashData.Algorithm = cadesplugin.CADESCOM_HASH_ALGORITHM_CP_GOST_3411;
yield oHashData.Hash(data);
args[0](oHashData);
}
catch (err) {
D3Api.notify('Ошибка', 'Не удалось создать хэш: ' + Form.GetErrorMessage(err), {'expires': false});
args[1]();
}
}, resolve, reject);
});
}
Вызываю ее примерно так: Код:
let oHashData = yield createHash_Async(fileData);
let hashValue = yield oHashData.Value;
В итоге в hashValue оказывается вроде хеш в формате как надо но он не совпадает. В fileData лежит base64 с file_get_contents (содержимое файла в binary, полученое на сервере с которого на сервере же хеш снимается правильно). Я правильно понял что в oHashData.Hash(data); при таком вызове надо класть именно base64 с подписываемого? При подписи через метод SignHash всегда будет отделенная подпись, дополнительно указывать какие то параметры для этого не нужно. В вашем примере в oHashedData.Hash() нужно подавать base64(бинарных данных файла). Внутри функция декодирует из base64 обратно в binary и уже от этих данных посчитает hash. PHP расширение и плагин внутри себя используют единный код, если вы подаете одинаковые данные то и хеш будет одинаковый. В PHP вы тоже данные через base64 передаете для хеширования? |
|
1 пользователь поблагодарил Анатолий Беляев за этот пост.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 18.08.2014(UTC) Сообщений: 90 Сказал «Спасибо»: 21 раз
Поблагодарили: 9 раз в 9 постах
|
Автор: cross Обвинять другой софт это уже традиция :). Да ни в одном глазу даже мысли такой не было. :) Цитата:К сожалению без возможности глянуть как они создают (код страницы) запрос мы врядли сможем чем то помочь. Я не программист и не работник УФК, на чьих серверах и работает ППО "СУФД" - это не портальное решение для единого доступа через интернет. Жаль конечно, так и предполагал, что без живого доступа к СУФД ничего определенного сказать будет невозможно. Цитата:Через наш плагин запросы на сертификат создают несколько площадок, в данный момент ни одного обращения к нам по поводу ошибок при генерации запроса нет. На основании даже этого уже можно предположить, что "косяк" все-же в СУФД - некорректно взаимодействует с крипто-плагином версии именно 2.0.13064. По мере возможности и времени постараюсь проверить на плагине версии 2.0.12888: если ошибка не повторится, значит буду обращаться к разработчикам СУФД. Спасибо большое за отклик. Отредактировано пользователем 6 декабря 2017 г. 15:51:52(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
|
Цитата:На основании даже этого уже можно предположить, что "косяк" все-же в СУФД - некорректно взаимодействует с крипто-плагином версии именно 2.0.13064. По мере возможности и времени постараюсь проверить на плагине версии 2.0.12888: если ошибка не повторится, значит буду обращаться к разработчикам СУФД. Спасибо большое за отклик. Было бы хорошо, если они при обнаружении ошибки, даже если она у нас, что вообщем то не исключено, обратились бы к нам. Мы стараемся оперативно исправлять ошибки :). Рассуждения на закрытом форуме дают мало информации. Отредактировано пользователем 6 декабря 2017 г. 15:55:21(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
