Статус: Новичок
Группы: Участники
Зарегистрирован: 13.03.2023(UTC) Сообщений: 5 
|
Здравствуйте. Мы пытаемся интегрировать серсисы ЕСИА в наше приложение. Первым шагом необходимо получить авторизационный код с помощью вот этого endpoint https://esia-portal1.tes...ugi.ru/aas/oauth2/v2/ac. Для этого необходимо сформировать и подписать client secret. Вопрос - как правильно подписать его в Linux? Мы развернули КриптоПро 5 в Linux, добавили в него ключи, необходимые для подписи ЕСИА и сохранили client secret в файл secret.txt для подписания. Подпись генерит вот такая команда: Код:/opt/cprocsp/bin/amd64/cryptcp -signf -nocert -strict -detached -pin {EsiaPrivateKeysContainerPassword} -thumbprint {EsiaPublicCertificateThumbprint} -hashalg 1.2.643.7.1.1.2.2 secret.txt
Подписанный таким образом и преобразованный в Base64Url secret ЕСИА не принимает, говорит ошибка "ESIA-007053: AuthErrorEnum.clientSecretWrong". Кто-нибудь сталкивался с такими проблемами? Кто-нибудь может подтвердить, что команда правильная? Может опций каких-то не хватает? Может подписывать надо в два этапа - отдельной командой посчитать hash и потом отдельно его подписать? Буду рад любой информации.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,664  Сказал «Спасибо»: 571 раз
Поблагодарили: 2297 раз в 1798 постах
|
Здравствуйте.
Приложите требования к ЭП.
Сам txt верно сформирован? |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 13.03.2023(UTC) Сообщений: 5
|
Client secret сформирован на основании документации от ЕСИА. У нас получается вот такой - "TESTopenid2023.03.13 14:12:43 +0300b962359f-e5c4-a5f7-d2c4-7cc0d3a8c2d2 https://www.test.ru" (реальные client id и site я заменил на test). Требования к ЭП - это что такое?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,664 Сказал «Спасибо»: 571 раз
Поблагодарили: 2297 раз в 1798 постах
|
Автор: Ega78  Client secret сформирован на основании документации от ЕСИА. У нас получается вот такой - "TESTopenid2023.03.13 14:12:43 +0300b962359f-e5c4-a5f7-d2c4-7cc0d3a8c2d2 https://www.test.ru" (реальные client id и site я заменил на test). Требования к ЭП - это что такое? это то, что ожидается после подписания через API\утилиту. Цитата:
-signf = подписать
-nocert = без включения сертификата подписанта
-strict = однозначное der кодирование, вместо ber
-detached = отсоединенная ЭП
-hashalg 1.2.643.7.1.1.2.2 = Функция хэширования ГОСТ Р 34.11-2012, длина выхода 256 бит
эти параметры правильные? Соответствуют требованиям ЕСИА? |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 13.03.2023(UTC) Сообщений: 5
|
Так это как раз то, что я пытаюсь выяснить. Есть вот этот https://digital.gov.ru/u...niyuesiav313_VaCOzE9.pdf талмуд. В пункте В.2.3 говорится следующее: Цитата:Порядок формирования <client_secret>: 1) конкретизировать вышеуказанные параметры (порядок важен!). Пример строки: TESTAPPLICATIONopenidorg_inf2021.11.10 12:28:46 +0300bbf0aef5–5237–41bc–8cba– 291e29a3ade8 https://test.application.../auth/api/v1/esia/return2) подписать полученную строку с использованием алгоритма подписания data hash; 3) с использованием механизмов сертифицированных Российских криптографических средств защиты информации и сертификата информационной системы67; 4) закодировать полученное значение в base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к УЗ системы-клиента в ЕСИА. ЕСИА использует сертификаты в формате X.509 и взаимодействует с алгоритмами формирования 66 Адрес в тестовой среде: https://esia-portal1.tes...ugi.ru/aas/oauth2/v2/ac.67 Некоторые алгоритмы требуют развернуть зеркально, побайтово, полученную подпись. 440 электронной подписи ГОСТ Р 34.10-2012 и криптографического хэширования ГОСТ Р 34.11-2012; В следующем пункте ещё чуть-чуть: Цитата: <client_secret> – подпись запроса в формате PKCS#7 detached signature
в кодировке UTF-8 от значений семи параметров HTTP-запроса: scope,
scope_org, timestamp, clientId, state (без разделителей), redirect_uri, code.
<client_secret> должен быть закодирован в формате base64 url safe.
Используемый
для проверки подписи сертификат должен быть предварительно
зарегистрирован в ЕСИА и привязан к УЗ системы-клиента в ЕСИА. ЕСИА
использует сертификаты в формате X.509 и взаимодействует с алгоритмами
формирования электронной подписи ГОСТ Р 34.10-2012
и криптографического хэширования ГОСТ Р 34.11-2012; И всё, 500 с лишком страниц, а читать нечего. Люди, которые сталкивалиись с этой темой, помогите. Может быть кто-то где-то находил эти требования? Очевидно, что это должна быть detached подпись, а дальше? Формат - DER или BER? Сертификат надо включать или нет? Надо явно указывать алгоритм хеширования или никакого хеширования вообще не надо?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,664 Сказал «Спасибо»: 571 раз
Поблагодарили: 2297 раз в 1798 постах
|
Автор: Ega78 Так это как раз то, что я пытаюсь выяснить. Есть вот этот https://digital.gov.ru/u...niyuesiav313_VaCOzE9.pdf талмуд. В пункте В.2.3 говорится следующее: Цитата:Порядок формирования <client_secret>: 1) конкретизировать вышеуказанные параметры (порядок важен!). Пример строки: TESTAPPLICATIONopenidorg_inf2021.11.10 12:28:46 +0300bbf0aef5–5237–41bc–8cba– 291e29a3ade8 https://test.application.../auth/api/v1/esia/return2) подписать полученную строку с использованием алгоритма подписания data hash; 3) с использованием механизмов сертифицированных Российских криптографических средств защиты информации и сертификата информационной системы67; 4) закодировать полученное значение в base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к УЗ системы-клиента в ЕСИА. ЕСИА использует сертификаты в формате X.509 и взаимодействует с алгоритмами формирования 66 Адрес в тестовой среде: https://esia-portal1.tes...ugi.ru/aas/oauth2/v2/ac.67 Некоторые алгоритмы требуют развернуть зеркально, побайтово, полученную подпись. 440 электронной подписи ГОСТ Р 34.10-2012 и криптографического хэширования ГОСТ Р 34.11-2012; В следующем пункте ещё чуть-чуть: Цитата: <client_secret> – подпись запроса в формате PKCS#7 detached signature
в кодировке UTF-8 от значений семи параметров HTTP-запроса: scope,
scope_org, timestamp, clientId, state (без разделителей), redirect_uri, code.
<client_secret> должен быть закодирован в формате base64 url safe.
Используемый
для проверки подписи сертификат должен быть предварительно
зарегистрирован в ЕСИА и привязан к УЗ системы-клиента в ЕСИА. ЕСИА
использует сертификаты в формате X.509 и взаимодействует с алгоритмами
формирования электронной подписи ГОСТ Р 34.10-2012
и криптографического хэширования ГОСТ Р 34.11-2012; И всё, 500 с лишком страниц, а читать нечего. Люди, которые сталкивалиись с этой темой, помогите. Может быть кто-то где-то находил эти требования? Очевидно, что это должна быть detached подпись, а дальше? Формат - DER или BER? Сертификат надо включать или нет? Надо явно указывать алгоритм хеширования или никакого хеширования вообще не надо? начать с удаления -detached = отсоединенная ЭП и -nocert |
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,664 Сказал «Спасибо»: 571 раз
Поблагодарили: 2297 раз в 1798 постах
|
Автор: Ega78
Подписанный таким образом и преобразованный в Base64Url secret ЕСИА не принимает, говорит ошибка "ESIA-007053: AuthErrorEnum.clientSecretWrong". т.е. дважды кодирование произошло? от утилиты получили уже в base64, а потом еще раз в Base64Url? |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 13.03.2023(UTC) Сообщений: 5
|
Автор: Андрей * Автор: Ega78
Подписанный таким образом и преобразованный в Base64Url secret ЕСИА не принимает, говорит ошибка "ESIA-007053: AuthErrorEnum.clientSecretWrong". т.е. дважды кодирование произошло? от утилиты получили уже в base64, а потом еще раз в Base64Url? Нет, тут всё нормально. Base64 кодировка была корректно конвертирована в Base64Url.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,664 Сказал «Спасибо»: 571 раз
Поблагодарили: 2297 раз в 1798 постах
|
Автор: Ega78 Автор: Андрей * Автор: Ega78
Подписанный таким образом и преобразованный в Base64Url secret ЕСИА не принимает, говорит ошибка "ESIA-007053: AuthErrorEnum.clientSecretWrong". т.е. дважды кодирование произошло? от утилиты получили уже в base64, а потом еще раз в Base64Url? Нет, тут всё нормально. Base64 кодировка была корректно конвертирована в Base64Url. а где написано, что сервис ждёт после Base64Url опять в base64? Хотя ошибка, вероятно, другая бы была... |
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 13.03.2023(UTC) Сообщений: 5
|
Автор: Андрей * Автор: Ega78 Автор: Андрей * Автор: Ega78
Подписанный таким образом и преобразованный в Base64Url secret ЕСИА не принимает, говорит ошибка "ESIA-007053: AuthErrorEnum.clientSecretWrong". т.е. дважды кодирование произошло? от утилиты получили уже в base64, а потом еще раз в Base64Url? Нет, тут всё нормально. Base64 кодировка была корректно конвертирована в Base64Url. а где написано, что сервис ждёт после Base64Url опять в base64? Хотя ошибка, вероятно, другая бы была... Base64 и Base64Url - это одна и та же кодировка, только в Base64Url символы типа '/', ':' заменены на допустимые в url '_', '-' и т.д. То, что client secret должен передаваться в Base64Url кодировке написано в документации ЕСИА.
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
