1. Перед созданием подготовьте носитель (USB Flash, Дискета, Рутокен и др.). Для создания ключа и запроса следует нажать в правом нижнем углу монитора правой кнопкой мыши по иконке
4. При заполнении формы обязательно укажите путь для электронной и бумажной формы, и самым важным является выбор криптопровайдера
. Заполните форму и нажмите кнопку «ОК»
– указывается ФИО сотрудника (владельца сертификата), наделенного полномочиями на эксплуатацию средства криптографической защиты информации «Континент-АП». Наделение данным полномочием может быть произведено отдельным приказом по организации (который нужно будет предоставить в УФК), так и в составе приказа о назначении ответственных лиц при осуществлении электронного документооборота.
– можно не заполнять.
– указывается краткое название Вашей организации.
– отдел организации, в котором числится владелец сертификата.
– указывается название субъекта федерации, в котором находится организация.
– указывается город, в котором находится организация.
– RU.
– можно не указывать.
В ПОЛЯХ «ЭЛЕКТРОННАЯ ФОРМА» И «БУМАЖНАЯ ФОРМА» НЕОБХОДИМО УКАЗАТЬ ПУТЬ НА СЪЕМНЫЙ НОСИТЕЛЬ (ФЛЕШЬ КАРТА, ДИСКЕТА), ПО ДАННОМУ ПУТИ И БУДЕТ СОХРАНЁН ЗАПРОС НА СЕРТИФИКАТ И ЗАЯВКА НА ПОЛУЧЕНИЕ СЕРТИФИКАТА КЛЮЧА АБОНЕНТСКОГО ПУНКТА.
5. Далее появится форма запроса пароля на сгенерированный ключ, где необходимо ввести пароль в поле «НОВЫЙ ПАРОЛЬ» и в поле «ПОДТВЕРЖДЕНИЕ» (вводимые символы пароля в этих полях будут отображаться звёздочками). Нажмите кнопку «ОК».
Пароль должен состоять минимум из 6 символов и представляет собой хаотичный набор цифр, спецсимволов, английских больших и маленьких букв (пример: F4*mX9).
6. Далее появится форма с выбором съемного носителя. Выберите носитель и нажмите «ОК».
7. По окончании будет выдано сообщение об успешном создании запроса
ЧТОБЫ УБЕДИТЬСЯ В ПРАВИЛЬНОСТИ СОВЕРШЁННЫХ ВАМИ ДЕЙСТВИЙ ПРИ ГЕНЕРАЦИИ КЛЮЧЕЙ ВЫ МОЖЕТЕ ОТКРЫТЬ НОСИТЕЛЬ, НА КОТОРЫЙ ВЫ СФОРМИРОВАЛИ ЗАПРОС, на нем должно быть всего три объекта:
НАСТОЯТЕЛЬНО РЕКОМЕНДУЕТСЯ:
С ЦЕЛЬЮ ОБЕСПЕЧЕНИЯ НАДЁЖНОСТИ ИСПОЛЬЗОВАНИЯ КЛЮЧЕЙ АБОНЕНТСКОГО ПУНКТА СДЕЛАТЬ И ЗАРЕГИСТРИРОВАТЬ ДУБЛИКАТ КЛЮЧА НА РЕЗЕРВНЫЙ НОСИТЕЛЬ ДАННОГО СЪЁМНОГО НОСИТЕЛЯ ПРИ ПОМОЩИ ЛЕГАЛЬНОЙ ПРОГРАММЫ ДЛЯ СОЗДАНИЯ ОБРАЗОВ СЪЁМНЫХ НОСИТЕЛЕЙ!!!!!!!
Сохранность Ваших ключей на ВАШЕЙ ответственности.
БУДЬТЕ ГОТОВЫ К ТОМУ, ЧТО НОСИТЕЛЬ КЛЮЧЕЙ СВЯЗИ МОЖЕТ СЛОМАТЬСЯ В ЛЮБОЙ МОМЕНТ!!!
В УФК ВАШИХ ЗАКРЫТЫХ КЛЮЧЕЙ И ПАРОЛЕЙ НЕТ!!!
ЕСЛИ НА СЪЕМНОМ НОСИТЕЛЕ БУДЕТ ПРИСУТСТВОВАТЬ ПАПКА С КЛЮЧАМИ И ВЫ ПРЕДОСТАВИТЕ ЕЕ В УФК,
ТО ДОКУМЕНТЫ У ВАС НЕ ПРИМУТ!!!
ВАМ ВСЕ ПРИДЕТСЯ ПЕРЕДЕЛЫВАТЬ ЗАНОВО, ВСЗЯЗИ С КОМПРОМЕТАЦИЕЙ КЛЮЧЕЙ!!!
1-Обязательно укажите причину в связи с чем хотите получить сертификат абонентского пункта (предоставлением права использования СКЗИ Континент АП, плановой сменой ключа абонентского пункта или указать другую причину).
2-Введите паспортные данные владельца сертификата, на которого возложены полномочия на эксплуатацию СКЗИ «Континет-АП»
3-Укажите приказ, на основании которого работнику предоставлены полномочия на эксплуатацию СКЗИ Континент АП (либо отдельно созданный приказ о наделении полномочий, либо заново переизданные приказы о назначении ответственных лиц при осуществлении электронного документооборота по нашим предлагаемым шаблонам)
Наша команда имеет большой опыт в сопровождении казначейских программ. Мы готовы помочь вам в любом вопросе. Рекомендуйте нас своим коллегам.
Создаем запрос на сертификат Континент АП
Во первых нам понадобится письмо на получение сертификата Континент АП — Письмо актуально для Ставропольского края.
Переходим непосредственно к созданию запроса. С 1 Июня 2019 сам запрос чуть изменился. Информацию здесь я уже обновил.
1. Для начала нам нужно нажать на значок континента правой кнопкой мыши (в низу с права) и выбрать Сертификаты — Создать запрос на пользовательский сертификат.
2. Заполняем поля как на картинке — вписывая реквезиты Вашей организации!!! Убираем галочку в самом низу «бумажная форма» и проверяем путь, куда это все сохранится (надо сохранить на Вашу флешку, что бы в дальнейшем отнести ее в казначейство с электронной версией запроса). Жмете после заполнения ОК.
3. Целимся в мишень пока полоска не дойдет до 100%
4. Ставим пароль (из 6 символов).
5. Выбираем ключевой носитель для сохранения закрытого ключа.
6. Вот в принципе и вся процедура создания запроса.
7. Если хотите проверить — правильно ли Вы все сделали? То на этой картинке видно — что у нас получилось 2 файла.
topsecretkeys — это контейнер закрытых ключей, без него не будет работать ЭЦП и подключиться к континенту у Вас не получится.
continent.req — электронная версия запроса.
8. Осталось передать .req файл в казначейство с письмом.
В конце июля начале августа 2021 года, Федеральное казначейство анонсировало новый портал для формирования запросов на сертификаты, сокращенно ФЗС. Этот портал доступен по защищенному соединению и находится по адресу .
В остальных случаях присутствие заявителя или уполномоченного лица обязательно. Давайте разберем как раз этот случай, т.е. пусть клиент (заявитель) впервые обращается за сертификатом. Со своего рабочего места нужно зайти на портал по выше указанному адресу. Вот что мы там видим:
Необходимо нажать на кнопку, на которую указывает красная стрелка на рис. 1. Если у вас есть действующий сертификат, заметьте , т. е. срок действия которого еще не истёк, то вы можете сформировать запрос, нажав на кнопку, на которую указывает синяя стрелка. Ну а мы жмем на «красную» и видим следующее окошко:
Первое, что тут нужно сделать это выбрать субьект РФ. Если выберите не свой, то ваш запрос уйдет в тот регион, который будет выбран. Заполните все поля, обведенные красной рамкой (рис. 2). Если сведения подаются будущим владельцем сертификата (заявителем), то галочку «Сведения подаются уполномоченным лицом» ставить не нужно. Жмем «Далее» и попадаем в следующее окно:
Сначала выбираем тип будущего сертификата. Я выбрал «сертификат физического лица», потому что к этому типу относятся сертификаты СУФД, ЕИС и ГМУ. Тем самым я сразу покажу, как сделать запрос на сертификат в этих трех системах.
«Сертификат юридического лица» — это, скорее всего, сертификат СМЭВ (рис. 3), а вот «сертификат юридического лица без ФИО», с таким я не сталкивался, поэтому ничего сказать о нем не могу.
Итак, после выбора типа сертификата (отметив нужный тип галочкой), становится доступной кнопка «Внести сведения». Нажмем на нее, как показано на рис. 3 и попадем в следующее окошко:
Тут многое нам знакомо по программе «АРМ генерации ключей». На рисунке 4 внутри синих стрелочек я сделал надписи о системах, в которых будут работать сертификаты, если поставить эти полномочия. Для СУФД выбираем ветку «АСФК», для работы на сайте ГМУ выбираем «Работа с ГМУ. Базовый OID». Как видно из рисунка для работы на сайте «Закупки» больше не нужны никакие полномочия, достаточно галочки «Аутентификация клиента», которую убрать мы не можем, потому что она нужна для всех типов сертификатов. Если заявитель работает во всех трех системах, то он может иметь один сертификат.
Полномочия ЕИС убрали потому, что теперь их раздает администратор организации, который, в свою очередь, назначается руководителем организации после автоматической регистрации его на сайте в качестве руководителя согласно ЕГРЮЛ.
По кнопке «Обзор» (рис 4), можно выбрать свой сертификат, который у вас есть, но срок действия его истек и вы не можете воспользоваться «синей стрелочкой» (рис. 1). В этом случае все поля (ФИО, СНИЛС, ИНН, Организация) заполнятся автоматически из вашего сертификата (рис. 4). Иначе придется их заполнять вручную.
С ними все понятно, нас интересуют два последних нижних поля. Это «Класс средства ЭП» и «Криптопровайдер CSP». Класс средства ЭП оставляйте как есть, КС1, а Криптопровайдер CSP с 1 января 2021 года нужно будет выбирать другой, в названии которого есть ГОСТ 2021. Пока тоже оставляйте как есть (рис. 4). Стоит отметить, что возможность выбора криптопровайдера присутствует только в Крипто Про 4.0.
Итак, все поля заполнены, всё внимательно проверено, нет ли где ошибок, вставлен ключевой носитель для генерации на него ключей, жмем кнопку «Сохранить и сформировать запрос на сертификат» (рис. 4). После этого будут появляться стандартные окна генерации ключей, о которых я не раз упоминал в предыдущих своих статьях. Здесь я останавливаться на этом не буду. После всего этого вы попадете в следующее окно:
Первое, что бросается в глаза (рис. 5), это номер запроса. В АРМ генерации ключей такого не было. Итак, тут мы видим, что запрос на сертификат создан и присутствует в виде *.req файла. Кстати, его теперь в казначейство предоставлять не надо, он и так к ним попадет. Нужно записать только номер запроса. Но это я отвлекся, о нем будет дальше.
Еще такой момент. Давайте посмотрим на «желтый» блок (рис.5), там мы видим, что наш запрос уже сохранен в системе и мы всегда, точнее в течении месяца, можем к нему вернуться. Это, на мой взгляд, очень удобно. Представьте, что у вас на каком-нибудь документе, нет подписи руководителя и сегодня он подписать не может. Поэтому если скопировать ссылку и номер запроса, то к редактированию этого запроса можно вернуться позже.
Итак, жмем кнопку «Внести сведения» (рис. 5) для того, чтобы сформировать документы для получения сертификата и попадаем в следующее окно:
Если поставить галочку «Сведения подаются уполномоченным лицом» (рис. 2), то рисунок 6 изменится, там добавятся два дополнительных документа, которые обязательны для заполнения. На рис. 14 эти поля обведены красной рамкой. Итак, все сделано, жмем «Сохранить»:
Запрос на сертификат создан, документы на получения сертификата добавлены и сохранены в системе, осталось сформировать заявление. Жмем соответствующую кнопку (рис. 7) и нам открывается само заявление:
На рисунках выше, заявление представлено в виде трех картинок, где я обвел красной рамкой те поля, на которые обращают свое внимание в Федеральном казначействе. Некоторые поля в заявлении можно редактировать, там все интуитивно понятно. Когда все будет сделано и форма будет сформирована, то ее можно будет распечатать:
Жмем «Печать» (рис. 9), на бумажном экземпляре заполняем все поля, указанные на рис. 8 и сканируем заполненный документ, чтобы потом прикрепить его в систему по кнопке «Обзор» (рис. 10). Все документы предоставлены и теперь становится доступной кнопка «Подать запрос» (рис. 11). Нажмем на нее и увидим следующее:
Тут все понятно, если не уверены, то не нажимайте кнопку «Да» (рис. 12), а если нажмете, то попадете в окно (рис. 13), где можно будет распечатать памятку по предоставлению комплекта документов в Удостоверяющий центр Федерального казначейства. На мой взгляд, важным тут является номер запроса, потеряв который или забыв, вы не получите сертификат. К этому надо относиться серьезно, иначе всю работу, о которой я рассказывал в этой статье, вам придётся проделать заново.
На этом все, берёте комплект документов, предусмотренный пунктом 5.5 Регламента и распечатанный или записанный где-нибудь номер запроса и приходите в свой территориальный орган Федерального казначейства (рис. 13). Удачи!
И ещё одно немаловажное замечание. Если вы для создания запроса вошли по сертификату, то такой запрос подается только от имени владельца сертификата. Ни какого уполномоченного лица быть не может. Это, по моему, ясно и логично.
Для получения квалифицированного сертификата ключа проверки электронной подписи (далее – сертификат), созданного Удостоверяющим центром Федерального казначейства (далее – УЦ ФК), необходимо:
Порядка реализации Федеральным казначейством функций аккредитованного удостоверяющего центра и исполнения его обязанностей, утвержденному приказом Федерального казначейства от 16.03.2020 № 11н.
Проверить настройку АРМ для работы с Порталом заявителя ИС УЦ (
Получить средство электронной подписи (КриптоПро CSP версии 4.0) в ТОФК, в случае его отсутствия.
Настроить автоматизированное рабочее место (далее – АРМ) для работы с Порталом заявителя:
Подать документы на создание сертификата с использованием Портала заявителя:
Для подачи документов на создание сертификата без использования ЭП, необходимо руководствоваться инструкцией подачи запроса на сертификат без использования ЭП;
Для подачи документов на создание сертификата с использованием действующего ключа ЭП, который соответствует сертификату, созданному УЦ ФК, необходимо руководствоваться инструкцией по смене сертификата с использованием ЭП.
В случае возникновения ошибок при работе с Порталом заявителя рекомендуем воспользоваться «Списком часто задаваемых вопросов» либо обратиться в Единый контактный центр Федерального казначейства по номеру телефона
Для работы с Порталом заявителя нажмите на кнопку ниже
О формировании заявлений и запросов на сертификат через портал ФЗС
- С 01.02.2019 Удостоверяющий центр Федерального казначейства осуществляет выдачу сертификатов только с использованием схемы электронной подписи по ГОСТ Р34.10-2012.
- Для сайта закупок достаточно роли «Аутентификация клиента». Появившиеся в секции «Резерв ФК» роли Заказчика клиентов не касаются.
- Многие УФК требуют прикладывать согласие на обработку ПД по форме со страницы УФК, а не шаблон из ФЗС
- Место рождения получателя сертификата в карточке запроса указывается точно как в паспорте.
- Если при плановой смене сертификата вас просят переформировать запрос как при первичном обращении это связано с тем, что в ВРС прикреплена старая форма согласия, либо копия паспорта была заверено неверно. При входе по сертификату старые документы изменить нельзя. Просьба отнестись с пониманием.
С августа 2018 года казначейство просит вас формировать заявления и запросы на сертификат с помощью портала ФЗС (https://fzs.roskazna.ru)
Инструкции по формированию запроса и заявления:
Портал заявителя с функционалом формирования запросов на квалифицированные сертификаты ключей проверки электронных подписей (ФЗС), позволяет получателю сертификата (уполномоченному лицу) формировать комплект документов и сведений для создания/смены сертификата и направлять его в электронном виде в территориальный орган Федерального казначейства (ТОФК). В некоторых случаях без посещения ТОФК.
Требования к автоматизированному рабочему месту, порядок получения доступа к функционалу ФЗС и его описание представлено в документе «Информационная система «Удостоверяющий центр Федерального казначейства». Руководство пользователя».
Извините, но у вас недостаточно прав для комментирования
Flynn пишет: Пытаюсь разобраться с запросом на сертификат для Континента. Заполнил все поля. Нажимаю ‘ОК’. Выдает ошибку ‘Ошибка создания запроса 0x80090017. Тип поставщика не определен’.
По приведенной ссылке на совет ТП от К-АП не вполне ясно о восстановлении чьего криптопровайдера речь.
А вот на этом форуме автор поста вполне подробно расписал всю картину маслом:
Для тех у кого ошибка с криптопровайдером 0х80090017 тип поставщика не определен
Есть конечно варианты переустановки К-АП с или без провайдера от КБ. Но,
, это зависит от следующего:
Flynn пишет: КриптоПро для этого нужен установленный на компьютере?
Логично предположить, что К-АП на АРМе пользователя нужен для подключения к СУФД, а ей таки необходимо установленное СКЗИ от другого провайдера — КриптоПро.
Тогда,
, следует:
1. Обновить КриптоПро как минимум до версии 4.0.9944 (R3), а лучше до
(R4);
2. Переустановить Континент-АП с чистящей утилитой CspCleaner от КБ до версии минимум 3.7.5.514, а лучше до
.
Если верить разрабам сих СКЗИ в последних версиях указанных творений уже д.б. решены проблемы «неуживчивости» на одном АРМ-е 2-х криптопровайдеров — от КриптоПро и Кода Безопасности.
MotoArhangel пишет: Либо проблема с гостами.
Либо со старыми версиями крипты и К-АП, не дружащими с ГОСТ-2012, да и друг с другом.
Хотя безусловно: корневой от МКС и промежуточный от ФК серты по ГОСТ-2012 + актуальный корневой для Континента из вашего УФК конечно д.б. установлены, еще до генерации, однозначно! (с)
Новый алгоритм подачи и обработки запросов на сертификат ч/з портал ФЗС
С 14.05.2019 по 17.05.2019 проводится опытная эксплуатация новых функциональных возможностей ИС «УЦ ФК» версии 4.0. Поменялся алгоритм подачи и обработки запросов на сертификат ч/з портал ФЗС.
Алгоритм подачи запросов на сертификат через Портал заявителя неавторизованным пользователем
1. Неавторизованный пользователь осуществляет формирование и загрузку пакета электронных документов на получение сертификата с помощью Портала заявителя.
2. После подачи запроса Получателем сертификата сведения запроса проверяются посредством сервисов, опубликованных в СМЭВ.
a. В случае успешных проверок запроса в СМЭВ, автоматически создается запрос в реестре запросов на создание сертификатов подсистемы ВРС в статусе «Новый из ФЗС».
b. В случае нахождения расхождений сведений запроса и сведений, полученных из СМЭВ, запрос отклоняется, и Получатель сертификата получает соответствующее уведомление.
c. В случае если запрос находится на проверке в СМЭВ дольше заданного в конфигурации периода времени, проверка запроса в СМЭВ автоматически прерывается. На основании запроса создается запрос в реестре запросов на создание сертификатов подсистемы ВРС с отметкой, что проверка запроса в СМЭВ не была завершена (с указанием сервиса, в котором проверка не была завершена).
3. Оператор УЦ предварительно одобряет запрос в подсистеме ВРС и приглашает Получателя сертификата для личного визита для предоставления оригиналов документов для подачи запроса на сертификат, о чем Получателю сертификата отправляется соответствующее уведомление.
a. После предоставления оригиналов документов Получателем сертификата Оператор УЦ в подсистеме ВРС прикладывает копию предоставленного документа, удостоверяющего личность, к запросу, подписывая добавляемые сведения своей ЭП.
b. Если рассмотрение запроса осуществлялось оператором УРЦР, запрос отправляется на согласование оператору РЦР.
c. После прохождения необходимых проверок, запрос выгружается в подсистему Центра сертификации для выпуска сертификата.
4. Если Оператор УЦ отклоняет запрос в подсистеме ВРС, запрос переходит в статус «Отклонен», о чем Получателю сертификата отправляется соответствующее уведомление.
Алгоритм подачи запросов на сертификат через Портал заявителя авторизованным пользователем
1. Авторизованный пользователь осуществляет формирование и загрузку пакета электронных документов на получение сертификата с помощью Портала заявителя.
a. В случае успешных проверок запроса в СМЭВ, запрос становится доступным руководителю (или Получателю сертификата, которому делегированы полномочия руководителя) для согласования.
c. В случае если запрос находится на проверке в СМЭВ дольше заданного в конфигурации периода времени, проверка запроса в СМЭВ автоматически прерывается с отметкой, что проверка запроса в СМЭВ не была завершена (с указанием сервиса, в котором проверка не была завершена), и запрос переходит на согласование руководителю.
3. Руководитель осуществляет согласование запроса, после чего автоматически создается запрос в реестре запросов на создание сертификатов подсистемы ВРС. В случае подачи запроса на сертификат руководителем, этап согласования руководителем пропускается.
4. В случае если сведения, указанные Получателем сертификата в пакете документов на получение сертификата, не изменились по сравнению с ранее предоставляемыми в УЦ документами, оператор УЦ осуществляет согласование запроса на сертификат без личного визита Получателя сертификата.
5. В случае если сведения, указанные Получателем сертификата в пакете документов на получение сертификата, изменились по сравнению с ранее предоставляемыми в УЦ документами, то требуется личный визит Получателя сертификата в УЦ для предоставления оригиналов изменившихся документов.
a. Оператор УЦ предварительно одобряет запрос в подсистеме ВРС и приглашает Получателя сертификата для личного визита, о чем Получателю сертификата отправляется соответствующее уведомление.
b. После предоставления оригиналов изменившихся документов Получателем сертификата Оператор УЦ в подсистеме ВРС прикладывает копию предоставленного документа к запросу, подписывая добавляемые сведения своей ЭП.
6. Если рассмотрение запроса осуществлялось оператором УРЦР, запрос отправляется на согласование оператору РЦР.
7. После прохождения необходимых проверок, запрос выгружается в подсистему Центра сертификации для выпуска сертификата.
8. Если Оператор УЦ отклоняет запрос в подсистеме ВРС, запрос переходит в статус «Отклонен», о чем Получателю сертификата отправляется соответствующее уведомление.
ОБНОВЛЕНО ноябрь 2021г.
2. Выбираем теперь свой Субьект РФ (край, регион и т.д.) а ниже уже код ТОФК через значок лупы — это код Вашего казначейства, с которым Вы работаете и в котором Вы обслуживаетесь. Вашу заявку на ЭЦП будут отрабатывать именно там. Огрн проставился автоматически. Жмем ДАЛЕЕ
3. Теперь отмечаем пункт: Сертификат физического лица, а чуть ниже выбираем ВНЕСТИ СВЕДЕНИЯ
4. Тут проверяем паспортные данные, серию, номер и т.д. Нажимаем СОХРАНИТЬ
5. Переходим к следующему этапу — ВНЕСТИ СВЕДЕНИЯ
6. Это важный этап, здесь мы отмечаем полномочия — проще говоря площадки, где будет работать наше ЭЦП. При плановой смене тут уже все проставлено за нас. Но я все же озвучу некоторые нюансы.
Аутентификация клиента — оно стоит по умолчанию, это полномочие дает нашему сертификату возможность работать в СУФД, ЕИС, электронном бюджете. Но для начала нам надо получить сертификат, а потом уведомить казначейство — что бы они подвязали новый сертификат в ЭБ и СУФД. Автоматически они там не обновляются!!!
Работа с ГМУ. Базовый OID. Тут раскрываем этот пункт и отмечаем два полномочия. Эти галки дают нам возможность работать на сайте bus.gov.ru. Но нам понадобится для этого заполнить обязательное поле «Ученый номер организации ГМУ»
Остальные полномочия не ставим, Вам они не понадобятся (исключение полномочие Россреестра, но она для отдельных категорий клиентов, которым это полномочие разрешено и необходимо). Во всех остальных случаях вам придет отказ.
Больше ни чего не трогаем, оставляем все как есть по умолчанию. Это касается полей Класс средств ЭП, Криптопровайдер (CSP), Экспортируемый закрытый ключ.
Жмем СОХРАНИТЬ И СФОРМИРОВАТЬ ЗАПРОС НА СЕРТИФИКАТ.
7. Жмем Да
8. Тут будьте внимательны. В этот момент формируются закрытые ключи от вашей ЭЦП. И если вы их сохраните и не запомните куда, ЭЦП ваша работать не будет!!! Закрытые ключи рекомендую формировать на флешку. Кто по опытней в реестр формирует, на токен и т.д. Главное их не потерять!!!! Потом уже на любой носитель можно перенести. Выбираем носитель и жмем ОК
9. Ну в принципе ))) небольшая пауза. Двигайте мышкой, тыкайте по клавиатуре — Ваша цель, зеленная полоска — которая должна полностью заполнить строку.
10. Еще один важный момент. Некоторые клиенты, или «горе программисты» — которые им помогают или обслуживают, ставят здесь пароль, ну и конечно его забывают! Собственно если с Вами так и произошло ПОЗДРАВЛЯЮ!!! Вам придется делать новую эцп! Оставляйте поле пустым, либо записывайте обязательно пароль!!! ОК
11. Переходим к пункту СФОРМИРОВАТЬ ЗАЯВЛЕНИЕ
12. Мы не будем рассматривать здесь случаи, когда ЭЦП делается на бухгалтера или иное лицо, на которое требуется выписка из приказа на должность или доверенность на владение ЭЦП. Укажите должность, проверьте дату. И жмите СОХРАНИТЬ.
13. Можете проверить актуальность электронного почтового адреса и нажать ПОДПИСАТЬ СВЕДЕНИЯ ЭП И ПОДАТЬ ЗАПРОС
14. Нажимаем ДА
15. Тут нам выдает как бы электронную форму запроса на получение сертификата, с реквизитами владельца и прочим. Нажимаем ПОДПИСАТЬ ЭП
16. Окошко, нужно нажать Да
17. Тут выбираем сертификат и нажимаем ПОДПИСАТЬ ЭП
18. Финиш ))) уведомление о том что запрос сформирован, подписан и подан в обработку. ОК
19. Можно отслеживать статус запроса. Вкладка Мои запросы
20. Вот и наступил долгожданный момент — ИЗГОТОВЛЕН СЕРТИФИКАТ
21. ПОДТВЕРДИТЬ И ПОДПИСАТЬ ЭП
22. Еще совсем немного!!! Финишная прямая в паре шагов от нас ))) Жмем Да
23. Снова выбираем сертификат как в пункте 17, ПОДПИСАТЬ ЭП
24. Внизу экрана видим всплывающее окошко. Жмем сохранить как, и сохраняем сертификат. На флешку — которую мы выбирали в пункте 8
Пару лайф хаков, которые облегчат Вам ))) работу на портале. Следите за сроком ЭЦП, если вы заблаговременно подадите запрос через плановую смену! Вам не придется идти в казну. 2 – 3 недели до окончания срока действия ЭЦП, отличное время что бы задуматься о продлении.
Инструкция по созданию сертификата
1. Этот пункт выбирается в случае первичного получения ЭЦП. Если у организации появился новый сотрудник, для которого нужно изготовить ЭЦП. А так же если срок действия сертификата истек и Вы не смогли под ним зайти что бы изготовить новый на основании предыдущего (с автозоплнением реквизитов и полномочий с прошлого сертификата).
2. Заполняете поля Субъект РФ (выбираете свой регион)Орган ФК — казначейство, в котором Вы обслуживаетесь. ОГРН (Вашей организации) ИНН (Вашей организации) Вводим капчу и жмем кнопку «ДАЛЕЕ»
3. Выбираем сертификат физического лица Нажимаем ВНЕСТИ СВЕДЕНИЯ
4. Заполняем поля очень Внимательно!!! Фамилия Имя Отчество ИНН (Физического лица! Не организации!) Ваш электронный адрес -e-mail Регион, Населенный пункт Формализованная должность это признак 1 или 2 подписи. У руководителей это только Руководитель, даже если это заместитель или ИО руководителя. У бухгалтеров только Главный бухгалтер!
5. После этого выйдет такое окошечко. Жмем Да.
6. Внимательно выбирайте сьемный носитель (Флешку) — на которой будет Ваша ЭЦП. На этом этапе будет производиться сохранение закрытых ключей. А без этих ключей ЭЦП работать не будет.
8. Рекомендую оставить поле пустым. Если Вы поставите пароль. То при установке в Крипто ПРО сертификата, он Вас спросит этот самый пароль. Если Вы этот пароль не вспомните, то использовать ЭЦП у Вас в дальнейшем не получится. Жмем ОК.
9. Жмем ВНЕСТИ СВЕДЕНИЯ
11. Нажимаем СФОРМИРОВАТЬ ЗАЯВЛЕНИЕ
12. Заполняем поля на верху. Номер и дату договора присоединения (если не помните уточняйте в своем казначействе). Если заявка делается на Руководителя то реквизиты документа подтверждающего полномочия получателя сертификата оставляете пустым. Если это филиал или любой другой человек организации — отличный от руководителя, то на него нужна доверенность или приказ на ЭЦП (на филиал — на руководителя то от вышестоящей организации). Все это я уже описывал в пункте 10. Ключевая фраза: можно любое слово Должность руководителя Организации — вписываете должность и И.О. Фамилию руководителя. Не забываем ставить даты. Жмем СОХРАНИТЬ И СФОРМИРОВАТЬ ПЕЧАТНУЮ ФОРМУ.
13. Нажимаем ПЕЧАТЬ.
14. Печатаем, ставим печать, подписи в 2 местах. Сканируем в .pdf одним файлом (желательно) После того как Вы подписали документ и поставили гербовую печать. Нажимаем ОБЗОР — прикрепляем сканированный файлик. После этого станет активная кнопка ПОДАТЬ ЗАРПОС Нажимаем ПОДАТЬ ЗАПРОC
15. Жмем ДА.
После этого проходит около суток, прежде чем Вашу заявку увидят в казначействе (проходит предварительный автоматический контроль и сверка).
Анонс
В предыдущей статье «Сам себе PKI: Теория на примере Let’s Encrypt» мы рассмотрели теорию и разобрали пример, как происходит установка HTTPS соединения между браузером и веб-сайтом при использовании сертификатов Let’s Encrypt. В этой статье перейдем к практике и самостоятельно реализуем ту же самую схему:
- Сначала вручную (с помощью OpenSSL) пройдем цепочку генерации и использования самоподписанных сертификатов в HTTPS сервере.
- Далее развернем собственный удостоверяющий центр Smallstep и будем получать сертификаты, подписанные им.
Схема PKI остаётся той же, только изменяются компоненты:
- В качестве CA вместо Let’s Encrypt, будет использоваться OpenSSL и CA Smallstep.
- В роли Web-сервера вместо Интернет веб-сайта, будет выступать простой HTTPS сервер, запущенный на Node.js.
Практика Self-signed certificate
Начнем с классики криптографии OpenSSL. Сейчас широко используется версия 1.1.1, но ее поддержка заканчивается в 2023. Следующая версия 3.0 будет поддерживаться до 2026 года. Проверка установленной версии:
OpenSSL 1.1.1k FIPS 25 Mar 2021
Если OpenSSL не установлен, то его можно установить на всех востребованных платформах.
Реализация TLS
openssl req -x509 -new -key root_ca.key -days 365 -out root_ca.crt
openssl x509 -text -in root_ca.crt
openssl req -new -key server.key -subj «/CN=xx.xx.xx.xx/CN=server/CN=server.example.com» -out server.csr
openssl req -text -in server.csr
openssl x509 -req -in server.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out server.crt -days 365 -extensions SAN -extfile openssl.cnf
- С ключами и сертификатами закончили, переходим к запуску HTTPS сервера. Копируем следующие файлы на компьютер, на котором будет работать HTTPS сервер:
- Пишем простейший HTTPS сервер, на JS:
sudo yum groupinstall ‘Development Tools’
sudo yum install nodejs
При первом запросе возникнет ошибка:
curl: (60) SSL certificate problem: self signed certificate in certificate chain
Это значит, что самоподписанный корневой сертификат нашего CA (root_ca.crt) не находится в хранилище доверительных сертификатов. Процесс загрузки сертификатов в это хранилище специфичен для операционной системы. Приведу алгоритм для RH Linux:
openssl x509 -in root_ca.crt -out root_ca.pem -outform PEM
Это значит, что мы установили TLS соединение только с проверкой сертификата сервера, а не клиента. Переходим к mTLS.
Реализация mTLS
В коде сервера включаем mTLS, а именно выставляем в true параметр requestCert, чтобы HTTPS сервер запрашивал клиентский сертификат и параметр rejectUnauthorized, чтобы сервер отклонял запросы клиентов, которые не прошли авторизацию:
Алгоритм генерации клиентских сертификатов аналогичен серверным.
openssl req -new -key client.key -subj «/CN=xx.xx.xx.xx/CN=client/CN=client.example.com» -out client.csr
openssl x509 -req -in client.csr -CA root_ca.crt -CAkey root_ca.key -CAcreateserial -out client.crt -days 365 -extensions SAN -extfile openssl.cnf
Файл openssl.cnf — такой же как и для сервера, только вместо «server» пишем «client».
- Копируем следующие файлы на компьютер, на котором будет работать клиент:
- Теперь если просто вызвать curl:
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
Это значит, что мы установили mTLS соединение с проверкой сертификата как сервера, так и клиента. Теперь установим mTLS из браузера.
Реализация mTLS в браузере
Если просто запустить наш запрос к серверу (https://server.example.com:9443) из браузера, то выдается ошибка клиентского сертификата ERR_BAD_SSL_CLIENT_AUTH_CERT. Рабочие адреса закрасил желтым:
Для загрузки в браузер клиентский сертификат и приватный ключ надо сконвертировать в формат p12. Этот формат определяется стандартом PKCS #12 и является архивом для хранения нескольких объектов. В нашем случае файл будет хранить клиентский сертификат и его приватный ключ. Понятно, что приватный ключ — это чувствительная к разглашению информация и ее владелец не должен выкладывать p12 сертификат в открытый доступ. Для конвертации тоже используем OpenSSL:
openssl pkcs12 -inkey client.key -in client.crt -export -out client.p12
Импортируем client.p12 в браузер. Для этого, например в Chrome, идем в меню: Settings / Privacy and security / Manage certificates, в открывшемся окне нажимаем Import, выбираем наш файл client.p12 и место хранения «Personal». Видим, что клиентский сертификат, выданный нашим удостоверяющим центром «My CN», появился в хранилище персональных сертификатов:
Вызываем запрос заново, уже лучше, но браузер все равно пишет, что соединение не безопасно. Это из-за того, что клиентский сертификат выдан удостоверяющим центром «My CN», которого нет в списке доверительных CA (Trusted Root Certification Authorities).
Добавляем корневой сертификат нашего CA (root_ca.crt) в Trusted Root Certification Authorities. Делается с помощью того же вызова Import, что и для клиентского сертификата, но хранилище указываем Trusted Root Certification Authorities. Проверяем, что наш CA «My CN» появился в хранилище:
Повторяем наш запрос (https://server.example.com:9443). При первом запросе браузер находит подходящий клиентский сертификат и просит явно подтвердить его использование:
Дальнейшие вызовы проходят без запросов на подтверждение клиентского сертификата:
Если щелкнуть на замочке а адресной строке, то можно посмотреть сертификат сервера и убедиться, что мы взаимодействуем с правильным сервером (Issued to: server.example.com), сертификат которому выдан нашим удостоверяющим центром (Issued by: My CN) и время действия сертификата еще не прошло (Valid to: 31.05.2023):
Таким образом мы организовали mTLS соединение из браузера. Далее приведу для справки несколько дополнительных возможностей OpenSSL, которые могут пригодиться в процессе работы.
Дополнительные возможности OpenSSL
openssl x509 -outform der -in client.crt -out client.der
openssl x509 -inform der -in client.cer -out client.pem
Отладка с помощью OpenSSL
openssl verify -verbose -x509_strict -CAfile root_ca.pem server.crt
openssl s_server -accept 9443 -cert server.crt -key server.key
openssl s_client -connect xx.xx.xx.xx:9443 -prexit -showcerts -state -status -tlsextdebug -verify 10
- При вызове curl параметр:-k — позволяет подсоединяться к серверу без проверки цепочки сертификатов (certificate path validation). —ssl-no-revoke — предотвращает проверку отозванных сертификатов
- -k — позволяет подсоединяться к серверу без проверки цепочки сертификатов (certificate path validation).
- —ssl-no-revoke — предотвращает проверку отозванных сертификатов
Практика CA Smallstep
CA Smallstep — это open source CA, который можно развернуть локально для автоматического получения X.509 сертификатов. На официальном сайте есть ряд инструкций по его установке и настройке. Для экспериментов я использовал вариант с docker:
sudo yum -y update
sudo yum install -y yum-utils
sudo yum-config-manager —add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum -y install docker-ce
sudo systemctl start docker
sudo docker run hello-world
sudo docker pull smallstep/step-ca
docker run -it -v step:/home/step smallstep/step-ca step ca init
должна вернуться строка:
На этом же или другом компьютере по инструкции устанавливаем утилиту CLI step. Краткая выжимка:
tar -xf step_linux_0.19.0_386.tar.gz
step ca health
Все готово для генерации ключей и сертификатов.
Генерация ключей и сертификатов
Также как и в случае с OpenSSL, сначала генерируем ключ и сертификат для сервера и установки TLS соединения, потом для клиента и установки mTLS.
step certificate create —csr —no-password —insecure —kty=RSA —size=2048 «xx.xx.xx.xx» server.csr server.key
step ca sign server.csr server.crt
step certificate inspect server.crt
step ca root root_ca.crt
step certificate inspect root_ca.crt
Все нормально, теперь генерируем ключ и сертификат для клиента.
step certificate create —csr —no-password —insecure —kty=RSA —size=2048 «xx.xx.xx.xx» client.csr client.key
step ca sign client.csr client.crt
step certificate inspect client.crt
- Копируем на клиента:
- Для проверки вызываем curl с параметрами:
Отлично — mTLS тоже работает с выданными CA Smallstep сертификатами!
Дополнительные возможности CA Smallstep
С помощью CLI step можно проверить необходимость обновления сертификата:
step certificate needs-renewal server.crt
certificate does not need renewal
step ca renew server.crt server.key
step ca revoke —cert server.crt —key server.key
step certificate inspect server.crt —bundle
STEPDEBUG=1 step /команда/
Заключение
В данной статье мы рассмотрели две возможности генерации ключей и сертификатов для клиента и сервера:
- С помощью OpenSSL.
- Используя CA Smallstep.
И двумя способами установили TLS и mTLS соединения:
- С помощью curl.
- Из браузера, загрузив в него клиентский и корневой сертификаты.
Теперь у нас есть понимание, как организовать свою систему PKI с помощью CA любого производителя, т.к. логика взаимодействия у всех аналогичная. Более того, большинство CA используют под капотом OpenSSL, оборачивая его в свой API.