Сказ о том, почему важно актуализировать документацию

Сказ о том, почему важно актуализировать документацию.

В пятницу вечером прилетает мне сообщение о том, что надо бы помочь хорошим людям справиться с небольшой задачей. Задача состоит в подключении новых ключей для авторизации мэрии одного уездного города N в ЕСИА (госуслуги). При этом в обращении сказано, что партнер с обновлением ключей не справился. Очень странная ситуация.

Как же работает авторизация для ЕСИА? В целом как-то так: получаем ключ и сертификат в авторизированном центре, загружаем публичный ключ в настройках ЕСИА, затем в коде согласно описанию формируем подписанное сообщение для API запроса. Для этого нам нужен сертификат, приватный ключ и установленный openssl, далее вызываем в php метод openssl_pkcs7_sign, скармливаем ему сертификат, ключ, сообщение, на выходе получаем строку, которую передаем в API. Подпись делается по стандарту PKCS7, который указан в официальной документации ЕСИА.

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

Начинаем изучать, что это за сертификат. Оказывается, это сертификат, подписанный ГОСТ2012 по PKCS12. Читаем правки в законодательстве, выясняем, что с 2020 года все обязаны перейти с ГОСТ2001 на ГОСТ2012. Действующие сертификаты ГОСТ2001 еще работают, но когда они закончатся, выдадут уже новые ГОСТ2012, а это более 3500 гос.органов, подключенных к ЕСИА и данная задача лишь первый закончившийся сертификат из списка.

Копаем информацию о том, что такое ГОСТ2012, находим информацию, что можно скомпилировать openssl с его поддержкой. Компилируем, поднимаем сервер, пробуем подписать. Без результатов. Выясняем далее, что КриптоПро умеет работать с ГОСТ2012 для ЕСИА и вроде как есть сборка для debian. Поднимаем тестовый сервер, устанавливаем КриптоПро, импортируем новый сертификат. Смотрим список, радуемся! Новый сертификат определился и показывается вместе с корневыми, причем у нужного нам есть право подписи. Изучаем документацию КриптоПро, пробуем подписать сообщение. Подписалось успешно. Верификация прошла. Уже что-то.

На данном этапе у нас есть тестовый сервер с решением для госорганов с модулем для авторизации через ЕСИА, на сайте введены те же настройки, что и на боевом. Есть отдельный сервер с установленным и настроенным КриптоПро. Остается выяснить, что и как надо подписывать, затем передать подпись в модуль и попробовать отправить запрос. Конечно же документация молчит про это все. Окей. Для MVP план такой – пишем микросервис для выполнения консольной команды подписи на сервере с криптопро, на сервере сайта дорабатываем модуль, проверяем. В модуле пишем обращение к микросервису, получаем подписанную строку, отправялем ее в ЕСИА, радуемся.

Источник новости https://t.me/digitalklondike/3...