ГОСТ Р 34.10-2012: переводим клиента на новые алгоритмы ЭЦП

В начале года клиент - производственная компания, сдающая отчётность через несколько операторов ЭДО и работающая с порталами госзакупок - спросил: «Нас просят обновить сертификаты. Это обязательно или можно подождать?» Мы тогда ответили честно: закон требует, срок обозначен, лучше не тянуть. Сейчас у нас уже есть практика по этому переходу, и она оказалась интереснее, чем просто «установить новое и выкинуть старое».

Речь про переход с ГОСТ Р 34.10-2001 на ГОСТ Р 34.10-2012. Алгоритм формирования электронной подписи, длина ключа, хеш-функция - всё меняется. КриптоПро как основной СКЗИ на рынке поддержку нового ГОСТа добавил, удостоверяющие центры уже выдают сертификаты по новому алгоритму. Осталось это всё совместить в рабочей конфигурации.

Что конкретно делали

Среда у клиента: несколько рабочих мест с Windows 7, КриптоПро CSP 3.6, токены Рутокен, сертификаты от аккредитованного УЦ. Плюс отдельный сервер для подписи документов перед отправкой в ЭДО.

Первое - обновление КриптоПро. Версия 3.6 поддерживает ГОСТ-2012 начиная с определённых билдов, но у клиента стояла ранняя ревизия. Обновились до актуального КриптоПро CSP 3.9. Это само по себе не поставило систему на паузу - старые сертификаты продолжали работать, подпись ходила. Тут всё прошло чисто.

Второе - получение новых сертификатов. Обратились в тот же УЦ, который обслуживал клиента раньше. Выпуск сертификатов по ГОСТ-2012 они уже освоили. Процедура стандартная: заявление, комплект документов, запрос на сертификат генерируется через КриптоПро, выдаётся сертификат с новым алгоритмом. Сертификатов несколько - у директора, у бухгалтера и отдельный для сервера ЭДО. Каждый прошёл отдельно, ничего экзотического.

Третье - тестирование совместимости, и вот где интересно. Не все площадки и порталы одинаково восприняли новые сертификаты. Отчётность через одного из операторов ЭДО прошла без вопросов - их система приняла подпись по ГОСТ-2012, квитанция вернулась, всё ок. Второй оператор - другая история: при отправке через их веб-интерфейс подпись не проходила валидацию. Выяснили, что у них плагин для браузера работает со старой версией КриптоПро и с новым ГОСТом не дружит. Пришлось отдельно переустановить их плагин в обновлённой версии и прогнать тесты заново. Прошло.

С порталом госзакупок (тогда это ещё ЗАО «ММВБ-ИТ» с классическим интерфейсом) ситуация была аналогичная: новый сертификат принимался, но только с обновлённым плагином КриптоПро для браузера. Без него - ошибка при подписании заявки. Поставили плагин, проверили на тестовой процедуре - заработало.

Портал ФНС в части личного кабинета юрлица в нашем случае вообще не трогали - клиент сдавал отчётность только через ЭДО, напрямую на портал не ходил. Но по опыту коллег там своя история с совместимостью, и лучше это проверять отдельно.

Что стоит иметь в виду

Сама интеграция криптопровайдера с прикладным ПО - это не разовая установка. Каждый раз, когда обновляется СКЗИ или меняется алгоритм, нужно пройтись по всем точкам: браузерные плагины, настольные клиенты ЭДО, серверные службы, если подпись ставится на стороне сервера. У клиента таких точек набралось пять, и только три из них обновились без лишних движений.

Ещё один момент: период параллельного действия. Пока не истёк старый сертификат, рекомендуем держать обе конфигурации рабочими. Новый ГОСТ принимают не везде одновременно - и если приходит запрос на подпись от контрагента или площадки, которая ещё живёт на ГОСТ-2001, нужно чем-то отвечать. Это создаёт небольшую путаницу с «какой сертификат куда», но управляемую.

Токены Рутокен без проблем записали новые ключи рядом со старыми - это удобно. Рутокен S поддерживает несколько контейнеров, так что физически на одном токене могут сосуществовать оба сертификата до конца переходного периода.

На выходе клиент работает на новом ГОСТе, все площадки протестированы, старые сертификаты ещё живы до истечения срока действия. Следующий шаг - дождаться, пока все операторы и порталы подтянут свои плагины, и тогда уже окончательно убрать старые ключи. Пока торопить не будем.