Всем привет. В этом посте я хочу рассказать о подводных камнях выпуска квалифицированной электронной подписи (КЭП) для физического лица и о моем личном опыте взаимодействия с удостоверяющими центрами (УЦ). Не буду вдаваться в законодательство и прочие юридические подробности, специалистом в которых я не являюсь. Могу лишь сказать что существует ФЗ (номер сейчас не вспомню) согласно которому КЭП признается аналогом обычной подписи физического лица, что открывает для простого пользователя массу возможностей. Например, с помощью КЭП можно подписывать произвольные документы, например, всякие заявления в PDF в банки, сотовым операторам, коммунальщикам и т.п. и отправлять их по обычной электронной почте, без необходимости посещения этих учреждений лично. По закону документ подписанный КЭП и отправленный по электронной почте, если и не считается юридически значимым (здесь не могу сказать, т.к. не юрист), то подпись на нем по-крайней мере точно считается аналогом вашей обычной подписи, что, как минимум, удобно. Плюс, вы можете получать различные государственные сервисы, например, регистрацию ИП и т.п., как раз для всего этого вам и пригодится КЭП.
Если вы не специалист в криптографии и никогда не касались подобных моментов, то немного поясню. Физически КЭП представляет собой сертификат, выданный аккредитованным удостоверяющим центром, а также ключевую пару, состоящую из открытого/публичного и закрытого/приватного ключа. Приватный ключ должен храниться в защищенном контейнере на ПК или на специальном устройстве - токене. Например, Рутокен Lite, Рутокен ЭЦП 2.0, Jacarta, eSmart и т.п. Также при создании ключевой пары могут использоваться различные алгоритмы, самые распространенные и наиболее используемые из них - зарубежные, например, RSA и др., у нас же в стране официально стандартом для КЭП признан алгоритм ГОСТ Р 34.10-2012.
Процесс выпуска КЭП в теории выглядит следующим образом. Пользователь формирует на своем ПК ключевую пару: закрытый ключ, и получающийся из него открытый. После чего генерируется запрос на сертификат, согласно определенному шаблону, например, для КЭП в него заполняются такие поля, как Фамилия Имя Отчество пользователя, ИНН, СНИЛС, e-mail и др. Все это происходит с использованием СКЗИ (средства криптографической защиты информации), наиболее распространенными из которых являются КриптоПро CSP и VipNet CSP. Если кому-то интересно более подробно - то данную информацию можно найти на сайте практически любого удостоверяющего центра.
Теперь самое главное. Носители ключевой пары (токены) бывают нескольких видов. Если немного углубиться в технические детали, то это - с поддержкой аппаратной криптографии и без. Что это значит? На носителе с поддержкой аппаратной криптографии можно создать неэкспортируемую ключевую пару, т.е. в этом случае приватный ключ создастся на самом носителе и не сможет быть извлечен оттуда. Другими словами, все операции с электронной подписью будут выполняться на самом носителе, приватный ключ никогда его не покинет, не окажется в памяти компьютера, не сможет быть скомпрометирован вирусами или другим вредоносным ПО. Т.е. пока сам носитель при вас - никто не сможет воспользоваться вашей электронной подписью и никто не сможет ее похитить. В то время как носители без поддержки аппаратной криптографии являются просто хранилищем ключа и не выполняют таких функций.
Естественно, что для меня, как для пользователя делающего ставку на безопасность важно хранить мою подпись и ключевую пару на носителе с поддержкой аппаратной криптографии, и, конечно, мне бы хотелось чтобы ключевая пара была неизвлекаемой / неэкспортируемой. Т.е. чтобы ни вирусы, ни кто-либо еще не могли получить доступ к приватному ключу, хранящемуся на носителе. Таким требованиям вполне отвечает Рутокен ЭЦП 2.0.
Приобрести его можно в любом удостоверяющем центре (УЦ), или, например, в сетевых магазинах, таких как Ситилинк и т.п. Что я и сделал, плюс использовал бонусы в Ситилинке, для покупки токена со скидкой. В итоге окончательная цена на него получилась около ~1000 руб. Для сравнения - ни один УЦ такую цену на токен конечно не даст. Кроме самого токена нам понадобится ПО КриптоПро CSP и КриптоАРМ ГОСТ для удобной подписи документов (напомню, что одним из условий для чего мы вообще планируем использовать КЭП - является подпись документов), это все также достаточно легко находится и приобретается.
Теперь, когда у нас есть все необходимое, носитель для подписи, необходимое ПО и т.п. Можно перейти к самому главному - поиску удостоверяющего центра (УЦ). КЭП для физического лица сроком на 1 год обойдется вам примерно в 900 руб. практически везде. Поэтому выбирать УЦ было решено по другому критерию. А именно оперативности и адекватности ответа. Запрос во все удостоверяющие центры был написан в выходной день, субботу. Также необходимым условием была поставлена возможность выпуска сертификата КЭП на основе запроса в формате PKCS#10 предоставленного клиентом.
Поясню почему это важно. Априори регламент выпуска электронной подписи удостоверяющим центром неизвестен для пользователя. Т.к. ответственность за безопасность приватного ключа подписи несет сам пользователь, логично что подпись должна генерироваться пользователем самостоятельно (!), на его собственном ПК или токене с поддержкой аппаратной криптографии. Вариант в котором вы обратились в УЦ с заявлением на предоставление электронной подписи, сотрудники УЦ как-то что-то там сгенерировали, отдали вам токен и бумаги на подпись не подходит по понятным причинам. Т.к. в этом случае приватный ключ сгенерирован не вами и у вас в теории не может быть уверенности в том, что недобросовестный сотрудник УЦ не скопировал ваш приватный ключ себе на флэшку. Такое наверное маловероятно, но все же. В ситуации когда приватный ключ генерируется вами, на носителе с поддержкой аппаратной криптографии и не может быть физически извлечен с этого носителя - вы чувствуете себя гораздо более спокойно, т.к. ваш закрытый ключ находится в безопасности.
Как же УЦ должен выдать сертификат КЭП в таком случае, спросите вы? Как раз для этого и нужен тот самый запрос в формате PKCS #10. В момент генерации запроса на носителе создается неизвлекаемая ключевая пара, т.е. запрос соответствует вашему приватному ключу. Задача УЦ обработать этот запрос и выдать вам сертификат. Так это должно работать в теории, и так это работает со всеми зарубежными УЦ, например, при выдаче TLS сертификатов для подтверждения доменного имени сайта и т.п. В "отечественном" же случае, для получения КЭП - нужен еще личный визит в офис для подтверждения вашей личности и проверки паспорта и СНИЛС. Но по факту смысл действий УЦ остается тем же, вы подаете запрос - они генерируют сертификат. Всё.
Но ... вернёмся в реальность. В субботу вечером был напрален запрос по e-mail в следующие удостоверяющие центры:
1. Тензор
2. Астрал
3. Контур
4. ITCom
5. КриптоПРО
6. Инфотекс Траст
С некоторыми из них переписка велась по e-mail, с некоторыми - в чате на сайте. Вопрос был задан всем один и тот же:
Подскажите пожалуйста, может ли ваш УЦ выпустить сертификат КЭП для физического лица на основании запроса в формате PKCS #10? Хочется использовать КЭП для подписи произвоильных документов. Имеется носитель РуТокен ЭЦП 2.0, создан запрос на сертификат и неэкспортируемая ключевая пара. Хотелось бы получить сертификат на основании данного запроса. Eсли это возможно, то каким образом я могу передать PKCS #10 запрос в УЦ и оплатить генерацию сертификата? Какова процедура?
Позже всех ответил Тензор, ответа пришлось ждать несколько суток, аж до понедельника:
Электронные подписи для физического лица изготавливаем только на защищеном носителе Рутокн lite (не на Рутокен ЭЦП 2,0).
Таким образом сотрудники Тензор считаю что физические лица не достойны использовать ключевые носители с аппаратной криптографией.
Крипто-Про ответили, что формирование сертификата по PKCS#10 запросу невозможно:
Нет, по PKCS#10 Вы у нас не получите сертификат. Можете получить только согласно порядка получения: http://q.cryptopro.ru/center.htm
Здесь нужно заметить, что техническая грамотность некоторых сотрудников поддержки отвечающих на вопросы в чате и по e-mail у большинства УЦ практически нулевая (это не относится к УЦ КриптоПро) и, как выяснилось, мало кто из них представляет что такое запрос в формате PKCS#10 , т.к. все привыкли что клиенты пользуются "стандартной процедурой" или регламентом самого УЦ для получения КЭП. Который как раз и заключается в том, что вы заполняете бумажное заявление, потом сотрудники УЦ генерируют приватный ключ и сертификат, в некоторых случаях вообще без вашего участия, и отдают все это вам, вы же просто оплачиваете и подписываете документы что со всем согласны (между тем гарантий что копий вашего приватного ключа не осталось в УЦ у вас нет).
Диалог со старшим специалистом Астрал в чате выглядел следующим образом (общение в чате происходило потому, что на почту они так и не удосужились ответить):
- Добрый день. Подскажите, каков механизм получения КЭП для физического лица в случае если у меня уже есть носитель (Рутокен ЭПЦ 2.0) и сформирован запрос на сертификат? Каким образом я могу передать запрос на сертификат сотрудникам УЦ? Лично при посещении офиса, либо с помощью какой-либо формы на сайте УЦ, по электронной почте или еще как-то?
- Здравствуйте. Вы обратились в техническую поддержку организации АО «Калуга Астрал». Уточните, пожалуйста, ИНН организации.
- Елена, в смысле ИНН организации? Вы читали вопрос? Речь идет о ФИЗИЧЕСКОМ ЛИЦЕ.
- Я читала Ваш вопрос, в данном случае имеется ввиду ИНН физ. лица.
- А какое это отношение имеет к заданному вопросу? Ответить на вопрос можно без запроса каких-либо перс. данных.
- Вы написали что сформировали запрос, мне необходимо понимать по какому продукту.
- Перечитайте вопрос. Речь идет о КЭП для физического лица. Об этом сказано в вопросе.
- Еще раз уточню, я читала Ваш вопрос, если Вы сформировали запрос у нас по какому-либо продукту, то потребуется ИНН для проверки. Если Вы еще не формировали, а только собираетесь сформировать, то в данном случае я могу оформить заявку в отдел продаж если Вы уже выбрали тариф. Могу только сказать что идентификация производится при личном присутствии в офисе.
- Подскажите, вы представляете себе принципы и алгоритмы выпуска КЭП удостоверяющим центром? В данном случае речь идет о том что у меня сформирован запрос на выпуск сертификата КЭП для УЦ. Вопрос о том, каким образом он передается в УЦ, при личном посещении или есть другие каналы передачи?
- Получить сертификат на физ. лицо можно либо напрямую в офисе, либо подав заявку из личного кабинета. Для подбора обслуживающей организации можем оформить заявку в отдел продаж.
- Видимо мы не понимаем друг-друга. Я задам интересующие вопросы при посещении офиса. Спасибо.
Здесь старший (!) специалист вообще не захотел вникать в суть вопроса или даже не понял смысла того, про что его спрашивают. По-крайней мере информации о том возможен ли выпуск сертификата по запросу PKCS#10 предварительно подготовленному клиентом и о возможных путях передачи этого запроса в УЦ предоставлено не было.
Диалог со "специалистами" Контур был куда более "увлекательным". Один из специалистов попытался вникнуть в смысл вопроса, но после нескольких безуспешных попыток:
Просто решил уйти. Другой сотрудник почему-то решил что речь идет про использование решения КриптоПро HSM (хотя в вопросе про это ничего не было сказано) и вообще никакой речи про HSM не поднималось:
И ответил отказом. После чего ему еще раз было объяснено, что никакого HSM и облачных технологий у меня нет и никогда не было, и что имеется только РуТокен ЭПЦ 2.0 на котором уже есть неэкспортируемая ключевая пара, а также мной уже был сгенерирован запрос на сертификат. Однако это пояснение также не помогло, после чего я попытался переформулировать вопрос:
Однако четкого ответа также не было получено и я просто решил не тратить больше время на подобное общение.
Специалисты Инфотекс Траст ответили что действуют согласно собственному регламенту и не могут сформировать КЭП на основании имеющегося запроса:
Наш УЦ выпускает КЭП только на основании запроса сформированного через личный кабинет на сайте iitrust.lk. Выпуск сертификата на основании запроса сформированного сторонним ПО не предусмотрен.
Выпуск сертификата к уже существующему приватному/закрытому ключу тоже не предусмотрен. Если у Вас утеряна открытая часть ключа (сертификат), то необходимо обратиться в УЦ, в котором выпускалась ключевая пара. В ином случае, Вы можете пройти весь этап генерации заново в нашем УЦ, но в этом случае будет сформирована новая ключевая пара.
Естественно, что генерация ключевой пары в УЦ меня по понятным причинам не устраивала и я решил задать уточняющий вопрос:
А какой смысл в генерации ключевой пары вне носителя пользователя? В этом случае она априори будет считаться скопрометированной, т.к. недобросовестный сотрудник УЦ сможет, например, скопировать контейнер с закрытым ключом себе. В случае же, если ключевая пара формируется непосредственно на носителе с неизвлекаемой ключевой парой - подобное исключено в принципе. Поэтому вопрос актуален, и наверное звучит - как при обращении в ваш УЦ использовать носитель с аппаратной криптографией и неизвлекаемой ключевой парой?
После чего сотрудник поддержки прислал следующее разъяснение:
В сценарии получения электронной подписи через личный кабинет iitrust.lk все действия, в том числе и генерация закрытого ключа, производятся на ПК пользователя - УЦ осуществляет только выпуск сертификата, который можно будет скачать в личном кабинете. На этапе формирования запроса на сертификат Вы сможете выбрать СКЗИ в зависимости от установленных в операционной системе. Аппаратная криптография Рутокен ЭЦП 2.0 поддерживается.
Получив его, я запросил инструкцию по выпуску сертификата, чтобы понять каким именно образом происходит генерация сертификата через их ЛК, т.е. чтобы понять суть самой процедуры. И инструкция была незамедлительно мне предоставлена, несмотря на позднее время - 4 утра (по этому критерию данному УЦ вообще можно ставить 5+, т.к. ответы на все вопросы удалось получить у сотрудника поддержки даже глубокой ночью).
Кстати, в УЦ Инфотекс Траст была возможной "удаленная идентификация" по биометрии загранпаспорта, т.е. получение КЭП вообще без посещения офиса. Как это - можно прочитать вот тут (не сочтите за рекламу). В результате в 4 утра (!) я заполнил все что необходимо и отправил запрос на получение КЭП, через некоторое время она уже была выпущена. Если коротко, то перед началом работы вы устанавливаете на телефон специальное приложение IDPoint, в котором с помощью NFC ридера в телефоне читаете данные с чипа в вашем загранпаспорте и приложение идентифицирует вас.
Единственный нюанс, который стал "сюрпризом" - в процессе оформления КЭП они выпускают на вас ДВА сертификата, вместо одного. Один, который вы собственно и заказывали, приватный ключ от которого защищенно хранится на вашем токене. А другой - неявно получается в приложении IDPoint во время идентификации. Неявно - потому что вас не предупреждают о том, что будет выпущено несколько сертификатов. Но т.к. информация о всех выпущенных на ваше имя КЭП попадает в ГосУслуги - вы узнаете об этом. Честно говоря я был слегка удивлен, что было выпущено именно два сертификата и задал соответствующий вопрос техподдержке, ответ был следующим:
При выпуске ЭП с дистанционной идентификацией через приложение IDPoint выпускается 2 сертификата ЭП:
Первый сертификат ЭП – технологический, издается через само приложение и хранится только на вашем телефоне, воспользоваться им можно только через приложение IDPoint, и только в рамках услуг, предоставляемых УЦ АО «ИнфоТеКС Интернет Траст». В случае удаления или переустановки приложения IDPoint ключ удаляется безвозвратно. Передать, перенести или выгрузить данную ЭП на другое устройства нельзя, ключ не экспортируемый.
Второй сертификат ЭП выпускается уже по запросу, формируемому с вашего компьютера, с этой ЭП можно работать через обычные СКЗИ.
Тем не менее я все равно отправил запрос на отзыв второго сертификата, т.к. использовать его не планировал.
Поэтому по факту оценка 5+, поставленная этому УЦ ранее, меняется на 5- (пять с минусом), т.к. ситуацию с двумя выпущенными сертификатами вместо одного является далеко не очевидной.
И наконец АйтиКом ответили что выпуск сертификата по запросу PKCS#10 возможен и прислали описание самой процедуры, поэтому они также получают оценку отлично.
Резюмируя, если подвести итог. Из 6-ти опрошенных УЦ смогли вообще понять что требуется клиенту и выразили готовность выпустить сертификат всего два. Один действительно его выпустил, правда с некоторыми оговорками (целых два сертификата вместо одного ;), второй, если бы я обратился к ним, думаю, выпустил бы его тоже. Остальные же, как видно, либо просто отказались (хотя выпуск сертификатов на основании запроса - прямая обязанность УЦ), либо продемонстрировали полную безграмотность сотрудников ТП, либо попытались навязать небезопасное решение. Выводы можете сделать самостоятельно.
К сожалению, привести здесь полные логи переписки с каждым из УЦ не представляется возможным, т.к цель была все-таки получить КЭП, а не написать "разгромную статью", поэтому все логи чатов я не сохранял, но просто делал скрины откровенно "диких" моментов, по совокупности которых я и решил написать эту заметку. Однако даже по тому немногому что сохранилось - уже можно сделать вывод о квалификации сотрудников. Когда ты рассказываешь что у тебя есть PKCS#10 запрос и ты хочешь получить сертификат, а тебя 3 раза подряд спрашивают про ИНН, отрабатывая скриптовые сценарии, или когда сотрудник просто "сбегает", не понимая чего от него хотят, или спрашивает тебя про HSM, хотя он, естественно, никаким боком не относится к заданному вопросу - становится жутковато. Это действительно "российская криптография - бессмысленная и беспощадная". По-моему мнению все сотрудники технической поддержки должны обладать хотя бы минимальными знаниями и представлением о том как работает УЦ, о том что в конечном итоге все сертификаты действительно выпускаются на основании запроса. И что запрос этот генерируется одновременно с закрытым ключом или на основании приватного ключа, который должен быть только у пользователя и никак иначе. Т.к. в любом другом случае, например, в случае генерации приватного ключа сотрудниками УЦ (без использования носителя с аппаратной криптографией и неэкспортируемыми ключами) такую КЭП априори можно считать скопрометированной. Также неплохо было бы проводить для сотрудников экскурс и рассказывать о том какие носители ключей (токены) существуют и в чем между ними разница.
Конечно же, все вышеописанное базируется на основании моего собственного опыта общения с УЦ и пропущено через призму моего мировосприятия и вообще является моим сугубо личным субъективным мнением ;) Поэтому, вполне возможно, что я где-то был откровенно не прав, а возможно, что доля истины в моих словах все-таки есть и руководители соответствующих подразделений в УЦ возьмут какие-то моменты на заметку и проведут соответствующий инструктаж с сотрудниками (не в смысле устроят "публичную порку", а именно приложат усилия для повышения технической грамотности). Буду рад вашим комментариям, ну а у меня на этом всё ...
Справедливости ради, добавлю еще несколько моментов:
1. Астрал все же ответил на email:
Подпись выдать можем, но вам все равно необходимо будет пройти идентификацию в точке идентификации КалугаАстрал.
Так что по крайней мере по email - они утверждают что смогут все сделать на основании PCKS#10. Действительно ли это так или нет - выяснится только при визите в точку идентификации, однако, т.к. цель достигнута и сертификат получен в другом УЦ - проверить это в ближайший год точно не получится.
2. Что касается Инфотекс, то "счастье" при общении с поддержкой по-видимому закончилось. После того как выяснилось что в процессе оформления КЭП было выдано два сертификата, как и говорил, я отправил заявление на отзыв второго. Однако, ответ по данному заявлению отсутствует уже длительное время. Хотя вопросы с отзывом как раз, должны решаться более оперативно, в идеале - незамедлительно.
Сертификат отозвали, в приложении IDPoint он отображается как недействительный. Естественно что захотелось проверить факт отзыва сертификата как-то еще. Проблема заключалась в том, что сам файл сертификата, который генерируется при использовании приложения IDPoint пользователю в явном виде не предоставляется. Поэтому пришлось скачать список отозванных сертификатов с сайта Инфотекс - CA-INFOTECS-1-2021.crl, взять OpenSSL с поддержкой ГОСТ для отображения crl в виде текста и найти там сертификат по номеру. Он действительно был отозван, причем судя по Revocation Date - в течении часа после обращения в УЦ по e-mail. Так что отозвали они вполне своевременно, однако меня об этом никак не уведомили в принципе.
(комментирую, чтобы история была до конца объективной)
Кстати, на ГосУслугах в web-интерфейсе баг. Отозванный вчера сертификат до сих пор отображается в списке действующих подписей, хотя по идее должен был попасть в недействующие.
certutil -verify mycertfile.crt
Это для случая когда у вас есть mycertfile.crt ... а если его нет, а есть только номер сертификата, то проверить отзыв можно только через CRL.
mycertfile.crt у вас в два клика экспортируется через штатные оснастки ОС.
п.с. сорри, протупил, мы же об idpoint говорим.
с инфотексом работаем достаточно давно и много, у них при отзыве письма вроде робот рассылает, от no-reply приходили насколько я помню, может антиспам съел? техподдержка у них действительно крутая. задумывались попробовать с другими поработать, но пожалуй останемся. контур свой hsm пытаются продать вообще всем, даже нам, но зато у них есть крутые сервисы. про тензор знаю по словам бывших их пользователей, что они очень активно пихают ненужные услуги
Вы слишком много хотите, чтобы за 900 рублей ради вас меняли регламенты выдачи ЭП, утвержденные на уровне руководства. Это не одобрение таких действий, понятно, это скорее объяснение. Если бы вы привели им допустим 200 человек за ЭП по запросу PKCS#10, скорее всего вами бы занялся тот уровень сотрудников, который может отходить от регламента. И да, заметка выглядит как реклама Инфотекс (несмотря на оговорку).
вообще-то клиенты платят бабки, а не руководство их на принтере печатает. когда будет 200 человек желающих получить указанную услугу, то они обратятся к тем компаниям которые уже умеют обрабатывать запросы PKCS#10 , а остальные просто пойдут сосать лапу.
вы же не думаете что 200 человек вдруг решат скооперироваться и просить руководство частного уц сжалиться над ними и начать работать нормально)
в чем опасность наличия второго сертификата выданного в приложении IDPoint?
Опасность в том, что я, как пользователь, должен располагать всеми ключевыми парами, от всех своих подписей, т.е. по-хорошему я должен иметь приватный ключ от этого сертификата в явном виде. И должен быть уверен, что помимо меня этого ключа нет ни у кого. В случае же с этим приложением - ключ был сгенерирован "как-то" внутри приложения, как именно и насколько надежно он там хранится - проверить не представляется возможным, также неизвестно какие операции приложение осуществляет(-ляло) с этим ключом. По-умолчанию, я предполагаю, что оно потенциально могло сделать с ним все что угодно, в том числе и передать куда-либо.
Простая аналогия - ключ от дверного замка. Вы захотели установить дверной замок и иметь один ключ от него для себя. Пришел мастер, поставил замок, отдал вам ключ, все хорошо. В процессе анализа того что получилось, внимательного чтения документов и т.п., вы узнаете, что в момент подписания договора на установку замка - оказывается был изготовлен еще один ключ. Вы не знаете мастером, фирмой, которая устанавливает замки, просто знаете что он есть. Естественно что вы захотите его уничтожить, чтобы в квартиру никто кроме вас не имел доступа. И даже если фирма, которая занимается установкой замков с государственной лицензией и т.д. и т.п., чувство беспокойства что у кого-то есть еще один ключ от вашей двери - не оставит вас, пока вы не убедитесь что дубликат ключа действительно был уничтожен.
а можете снять видео версию вашего поста? особенно что касается выпуска запроса PKCS#10
ибо эта тема какая-то новая и непонятная. или возможно есть уже готовые видео объясняющие весь механизм который вы задействовали?
Сформировать запрос на сертификат в формате PKCS#10 можно, например, с помощью оригинальной утилиты от RuToken - https://dev.rutoken.ru/pages/viewpage.action?pageId=72451710 . Возможно для каких-то типов сертификатов (например, не для физ. лиц) понадобятся доп. шаблоны и/или поля, вся информация есть по ссылке.
К тому же, никто не мешает УЦ сделать форму для загрузки запроса на сертификат с предварительной валидацией полей. Например, клиент из дома загружает свой запрос на сертификат, который проходит предварительную валидацию всех обязательных полей, в момент посещения офиса, предоставленные клиентом в запросе данные сравниваются сотрудником УЦ с документами. В результате экономится время. Плюс, можно сделать подачу запроса платной, например, 100-250 руб. Ошибся в букве, указал неверный ИНН - не вопрос, никто не ограничивает клиента от подачи какого угодно количества запросов. Как говорится, любой каприз за ваши деньги.
Добрый день!
Спасибо за предоставленную информацию.
Мы попробовали найти ваше обращение, но к сожалению не смогли.
Укажите пожалуйста ИНН вашей организации, мы проверим проблемные места и проведем работу по улучшению качества технической поддержки.
С уважением,
Кошелев Александр
Компания Тензор
Отписал в ЛС. Спасибо за обратную связь.
Опять ИНН организации, они не исправимы…
Спасибо, отличный материал!👍
Владислав, С какой-то точки зрения вы правы, но с другой стороны - я не говорил что готов был потратить на получение КЭП - 900 руб. и ни копейкой больше. Возможно я бы оплатил услугу "ускоренного получения КЭП" / услугу "персонального менеджера", назвать можно как угодно, смысл в том, чтобы адекватный сотрудник постарался вникнуть в суть проблемы, пусть даже и за дополнительную плату. Если бы подобная услуга вообще была бы предложена - однако, увы, ничего подобного никто даже и не попытался предложить.
К тому же, предполагая что подобные запросы в принципе могут быть, никто не мешал УЦ сделать доп. услугу - выпуск сертификата на основе PKCS#10 за X руб. или выпуск КЭП на носителе с поддержкой аппаратной криптографии за Y руб. Где X и Y существенно больше 900 руб., однако, таких услуг, увы, тоже не предоставляется.
Более того, Тензор ответил в стиле "А у нас только Рутокен Lite", не хотите, не берите, что тоже не представляется правильным.
На самом деле наиболее адекватным во всей этой истории выглядит ответ УЦ АйтиКом. Но т.к. подпись я уже успел получить в УЦ Инфотекс, то в статье преимущественно про него, поэтому и оговорка.
Комментарий недоступен
Александр, спасибо за информацию.
По-поводу токена, вы имеете ввиду Рутокен ЭЦП 3.0, который NFC в виде смарткарты? Я читал про него мельком, но так понял что для работы на ПК необходим отдельный ридер, что показалось не очень удобным.
Не вижу смысла формирования запроса в формате PKCS #10 на носитель Рутокен ЭЦП 2.0. Вы же сами писали, что криптопровайдер находится внутри данного носителя, и скопировать закрытый ключ невозможно. Многие УЦ после удостоверения личности предоставляют Вам личный кабинет для онлайн выпуска электронной подписи с Вашего рабочего места. А если Вы сами генерируете запрос, то в процессе заполнения формы запроса можно допустить как орфографические, так и юридические ошибки, например ошибка в ИНН, также просто написали фамилию через Ё - а в паспорте Е. Если запрос формирует УЦ, по всем документам проходит проверка в системе межведомственного электронного взаимодействия. Экономится Ваше время.
Не согласен с Вами, время как раз экономится, если я сам сформирую PKCS #10 запрос, корректно заполню сам все поля (у кого больше времени на более тщательную проверку полей, у меня, как человека которому нужно проверить всего один запрос, или у сотрудника УЦ, который оформляет в день сотни, а то и тысячи таких запросов?), отправлю его в УЦ до личного визита, а при личном визите пройду только идентификацию личности по паспорту и получу сертификат.
Вообщем с моей точки зрения, для того чтобы допустить ошибку в полях запроса в ИНН, или фамилии - это нужно сильно постараться. К тому же, даже если действительно выяснится что ошибка была допущена - сформировать новый запрос дело 1 минуты.
К тому же:
"Многие УЦ после удостоверения личности предоставляют Вам личный кабинет для онлайн выпуска электронной подписи с Вашего рабочего места."
Многие != все, т.е., а некоторые не предоставляют. Вариант в котором вы обращаетесь в УЦ, а в результате вам выдают носитель и бумажки на подпись - непреемлем по понятным причинам. Выяснять как именно происходит процесс генерации подписи в данном конкретном УЦ - на рабочем месте клиента или еще как-то - тоже потеря времени, поэтому четко обозначенная задача - получение подписи по запросу в PKCS#10, априори исключает все лишние вопросы и непреемлемые варианты.
p.s. "Не вижу смысла формирования запроса в формате PKCS #10 на носитель Рутокен ЭЦП 2.0."
Плюс, запрос формируется не на носитель (!). Запрос формируется в файл, который вы как раз и должны предоставить в УЦ, на носителе в момент генерации запроса формируется неэкспортируемая ключевая пара.
рабочий день 480 минут, о каких сотнях или тысячах запросов в день, проходящих через сотрудника УЦ идёт речь?
если сотрудник УЦ сгенерирует ключи самостоятельно, то как он сможет их извлечь и скомпрометировать на Рутокен 2.0, если ключи с него неэкспортируемые?
подход, чтобы генерировать ключ самостоятельно верный, я с этим не спорю
Вы же поняли смысл фразы, он был следующий: вероятность ошибиться у человека, который генерирует ОДИН запрос (свой собственный), гораздо меньше, чем у сотрудника, который обрабатывает МНОГО запросов.
По-поводу компрометации - это как раз легко. Представим себе что я недобросовестный сотрудник, целью которого является сбор ключей пользователей. Генерируем приватный ключ и запрос на сертификат вне ключевого носителя (т.е. вне Рутокена), затем выпускаем сертификат, объединяем ключ и сертификат и формируем .pfx (Personal Information Exchange). Импортируем ключи в Рутокен, копируем pfx к себе на носитель. Отдаем Рутокен клиенту, клиент видит надпись "Сертификат с неизвлекаемой и неэкспортируемой ключевой парой" и радуется, но у меня-то есть копия ) А клиент не подозревает что приватный ключ был сгенерирован вне защищенного носителя. Например так )
Сотрудник не заполняет напрямую запрос для генерации ключа. После проверки соответствия всех документов (ФИО, паспорт, СНИЛС, ИНН) это делает программа без участия сотрудника или через личный кабинет. Конечно можно предложить, что сервер делает себе дубликаты запросов, но сотрудники УЦ не имеют такого доступа.
Ну а походов в УЦ, в случае самостоятельного формирования запроса, скорее всего, будет не один и не два...
Намекаете на то что будут ошибки при заполнении полей? Я думаю что не будут, т.к. никто не мешает найти любой сертификат и посмотреть какие поля в нем есть и как именно они заполняются. Ну, например, что в поле S (регион) нужно написать не "Хабаровский край", например, а "27 Хабаровский край" нетрудно догадаться по образцу. Также легко гуглятся всякие "Правила заполнения заявлений на создание сертификатов ключей
проверки электронной подписи" ... АйтиКом, к примеру, запросили у меня пример запроса для проверки - оказалось что я с первого раза заполнил все без ошибок, хотя до этого сертификаты КЭП в глаза не видел.
Спасибо, интересная статья
Статья хорошая, но Инфотекс не позволяет выпустить ЭП на Mac. Их плагин работает только на Windows. И самое грустное, что узнал об этом только после создания заявки, ее проверки в течение пары часов и оплаты.
В связи с новым порядком выдачи ЭЦП для юрлиц, в статье очень не хватает еще одного УЦ – ФНС.