Генерация ключа

Beast2040 пишет: Для ЕСИА в СУФД еще не делал, но разницы м/у АРМ и СУФД нет, кроме дублирующих OIDов в заявке.
Всегда писал ФИО в поле ФИО, а название организации в поле Организация, а также заполнял КПП и ОГРН и СНИЛС.

В таком случае получается не правильный сертификат, в поле CN будет ФИО, а должно быть наименование ЮЛ. Все эти траблы с сертификатами, потому что нет нормального софта для генерации, где четко требовало что заполнять

shaburoff пишет: В СУФД генерили заявки? Если да, то в поле ФИО пишем наименование ЮЛ? Меня просто смутила распечатка заявки там нет упоминания о руководителе, не фио, не должности. В АРМ ГК есть, толи в нём делать?

Тоже пока не приходилось генерить в СУФД. Если очень жмет - попробуй сгенерить "экспериментальный" на ЮЛ (без регистрации запроса в WebHandler) и посмотри в req-файле поля CN и SN. Методом научного тыка и поймешь что где вписывать надо при генерации в СУФД. Ну и может поделишься полученным знанием, полезным для всех заинтересованных. Я бы сам так и сделал, будь на работе, а не в отпуске (типа)...

Вот для сравнения запрос из СУФД и АРМ ГК:

shaburoff пишет: В таком случае получается не правильный сертификат

Если бы он был неправильный, то работать под ним не получалось. А так все очень даже неплохо работатет

Alex_04 пишет: В связи с этим пришлось повозиться с картинками скринов из СУФД, связав их текстом с пояснениями в "Порядок генерации КСКП ФЛ для СУФД и ЕИС в ППО "СУФД-online".

В вашей инструкции написано что не нужно ставить КПП / ОГРН для ЭП физ лица
А где это написано? В приказе 27н я что то не увидел

Наверно в законе Об электронной подписи № 63-ФЗ ст.17. Там не сказано, что не надо заполнять, но там сказано, что нужно заполнять
Верней, что должен содержать сертификат ЭП.

Оживлю тему, продублировав своё сообщение с форума ФК (forum.roskazna.ru/viewtopic.php?f=45&p=306884#p306884) - м.б. здесь быстрей откликнутся коллеги?

СУФД версии 7.69.15 - 7.270.91 (027.032.700T05).
В req-файле запроса на сертификат ЭП роли полномочий АСФК сохраняются - исправили, эт хорошо. НО вылезло другое - поле со значениями СНИЛС и ИНН формируется некорректно:

1.2.372.980001.8.4.1: СНИЛС=04113841106,ИНН=450400455703

Правильно оно д.б. таким:

1.2.372.980001.8.4.1: СНИЛС=04113841106;ИНН=450400455703

Не сразу заметил разницу - разделитель значений СНИЛС и ИНН "," вместо ";" как в req-файле из АРМ ГК !
В новый WebHandler такой файл запроса принимается без проблем, как ни странно, но при загрузке его в ВРС выходит ошибка:

"Формат запроса на сертификат некорректен".

В Протоколе расхождений следующие причины:

1. Не заполнен обязательный атрибут "ИНН"
2. Атрибут "СНИЛС" должен быть длиной 11
3. Атрибут "СНИЛС" должен состоять только из цифр

Народ, это только нам так "повезло" или у всех такое же счастье?
По данной ошибке собираюсь создавать обращение в СУЭ для эскалации его в ЦАФК и передачи разработчикам ППО СУФД. Поэтому важно знать (как можно оперативней) ваши отзывы, чтобы не поднимать лишнюю волну в случае "локальной" причины.

Alex_04 пишет: важно знать (как можно оперативней) ваши отзывы,

Достаточно одной таблэтки одного средства создания запроса.
АРМ ГК - наше всё и наше навсегда!

Alex67 пишет: Достаточно одной таблэтки одного средства создания запроса.

Идём к этому 7-мильными шагами, а пока...
Клиенты генерят запроса в СУФД версии 7.283.47+fix1 (028.321.700t02). Видимо в выходные её поставили, ибо на прошлой неделе былов сё ОК, а с понедельника такое.
1. В генераторе запроса на серт ЭП на третьей строчке появилось следующее:
Запрос на сертификат Индивидуального предпринимателя
Если не ошибаюсь, этого пока нет ни в ВРС, ни в ФЗС - СУФД впереди их всех?
2. При генерации запроса из IE и FF любой версии, без или с КриптоПро ЭЦП Browser plug-in тоже любой версии если отмечены роли ЕИС (любые) при переходе на следующий этап для заполнения полей о владельце выходит ошибка:
No enum constant
com.otr.sufd.webapp.admin.crypto.request.AbstractCryptoRequestController.FIELD_PROP_NAME.SPZ_CODE
Дальше продолжать генерить после такого приветствия не рискнули. Сгенерили в старом добром АРМ ГК-44n.

P.S:

АРМ ГК - наше всё и наше навсегда!

Да, так и есть до сих пор, пока ещё!

Alex_04 пишет: если отмечены роли ЕИС (любые) при переходе на следующий этап для заполнения полей о владельце выходит ошибка:
No enum constant
com.otr.sufd.webapp.admin.crypto.request.AbstractCryptoRequestController.FIELD_PROP_NAME.SPZ_CODE

Вы всё ещё кипятите? (с)
Полномочия ЕИС уже выпилены из ВРС и ФЗС чуть менее чем полностью, да и таблицу PROP_NAME.SPZ_CODE видно в СУФД просто очистили, (на что намекает текст ошибки), забыв подлатать интерфейс.
Конечно, заявители желающие иметь пяток халявных сертификатов на одно лицо заказчик - контроль - монтроль - надзор и так далее могут упасть в обморок, ну так обмахивайте их распечаткой 27н для обеспечения притока свежего воздуха.
Единственный (пока) случай второго сертификата заявителя на тоже лицо это "ГМУ отдельно" - вспоминаем ВКС посвященную новой версии регламента уц

Alex67 пишет: Полномочия ЕИС уже выпилены из ВРС и ФЗС чуть менее чем полностью

Да, читал на форумах уже об этом. Но вот остались 2 последних клиента по обмену сертов до 28.06, которым надо чтоб были роли ЕИС, "как положено" по их приказам.
Тогда уж и в генераторе СУФД бы вырезали блок "ЕИС" ко всем чертям и всё - типа баста, забудьте все о них и точка.

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

Не, у нас райФО наоборот: всеми конечностями были против ведра ключей для ЕИС от разных кабинетов и только "за" один "универсальный" ко всем дверям.

"ГМУ отдельно" - вспоминаем ВКС

и поминаем добрым словом всех, от кого зависит скорейшее избавление и от этой "напасти".

Alex67 пишет: таблицу PROP_NAME.SPZ_CODE видно в СУФД просто очистили, (на что намекает текст ошибки), забыв подлатать интерфейс.

Да, но ради ясности enum это перечисление констант, а не таблица. Константу убрали/переименовали, а обращение к ней - нет. Теоретически может привести к неожиданным последствиям, если на это значение добавят новое имя константы.

Alex67 пишет: Конечно, заявители желающие иметь пяток халявных сертификатов на одно лицо

Халява конечно хорошо, но еще "не все УЦ одинаково полезны". Хоть и хотелось бы один сертификат, но некоторые оиды УЦ ФК просто не выдает (для СМЭВ), не выдаются сертификаты ЮЛ (с огрн) с указанным ФИО/снилс неруководителя (для ФИАС). Согласен, что это неправильно, но ФНС требуют. С "защитой электронной почты" и "аутентификации сервера" тоже все плохо (к слову, случайно попался только один отечественный УЦ с реально рабочей "защитой электронной почты", остальные тоже только ставят роль). "Связка ключей" у пользователя остается, даже если у человека от ФК будет только 1 сертификат.

Alex67 пишет: "ГМУ отдельно" - вспоминаем ВКС

Вау! Оказывается элементарно забыв при генерации о ГМУ, и сгенерив второй запрос только на ГМУ, я оказался идущим в ногу со временем.

two_oceans пишет: я оказался идущим

с не в ногу со временем мелко шагающими разрабами ПО ГМУ... Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.

Alex_04 пишет: Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.

Точно! А то замучаешься ждать, пока он в облаках летает... и кроме них ничего нарисовать не может)))

Beck пишет:

Alex_04 пишет: Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.

Точно! А то замучаешься ждать, пока он в облаках летает... и кроме них ничего нарисовать не может)))

Соглашусь, однако ничего не мешает убрать "веселые картинки" самим, ведь главная страница в обычном http, без шифрования. Например, по умолчанию отключить отображение картинок в браузере либо задать свой "стиль пользователя" и включить его по умолчанию. Также это можно сделать централизованно различными прокси и банерорезками.

У меня все еще стоит старинная программа Proxomitron, в ней можно самому задать регулярными выражениями правила по которым будут резаться (или наоборот вставляться) ответы от сайта браузеру. Указывается в браузере как прокси, можно указать несколько "родительских" прокси. По умолчанию разрешен только локальный доступ, но можно и на всю локалку раздавать. Можно вообще передать что-то браузеру в ответ, не запрашивая реально сайт. Единственный минус - программа не поддерживает новые версии библиотек Openssl (одну из функций переименовали с тех пор, в другой функции поменяли заглавную на строчную и теперь их не находит). Пробовал патчить DLL, но тогда вообще крашится, надо пересобирать нормально. Поэтому о вырезке из https можно либо забыть либо подключать через stunnel и обратный прокси.