Сертификат континент

В одной из своих статей я рассказывал как установить программу Континент АП на Windows 7. Дело в том, что эта программа использует в своей работе сертификаты, с помощью которых создается защищенное соединение и обмен данными с сервером доступа Континента АП. В этой статье я постараюсь рассказать как создать запрос на издание сертификата для Континента АП, а также как установить этот сертификат в программу.

Показывать буду как всегда с картинками, правда сделаны они были на компьютере, под управлением Windows XP. Итак приступим…

После установки Континента АП, у вас в трее должен появиться значёк «серый щит». Если кликнуть этот «щит» правой кнопкой мышки, то появится контекстное меню, как показано на картинке ниже:

Тут надо выбрать пункт меню «Сертификаты», а затем «Создать запрос на пользовательский сертификат». Откроется следующее окошко (рис.2):

Эту форму необходимо заполнить. Перед этим не забудьте вставить чистый ключевой носитель. Ведь после заполнения этой формы начнется генерация закрытых ключей, которая происходит на отторгаемый ключевой носитель. Это может быть, например, флешка. Если вы используете на своём компьютере программу Крипто ПРО 3.6 и выше, то там флешки включены по умолчанию. А если быть более точным, то «Все съёмные носители». Генерацию на ключевой носитель типа «Реестр» не рассматриваю, т.к. это запрещено в нашем УФК.

Итак, вернемся к заполнению формы (рис.2). Как можно видеть, она состоит как бы из двух блоков. Я их обвел желтым контуром. Если с верхним блоком все интуитивно понятно (надо заполнить все поля), то на нижнем остановлюсь подробнее. Сразу необходимо установить галку «бумажная форма». По умолчанию она не установлена. По кнопкам «Обзор» можно выбрать место для сохранения файлов. А их будет два. *.reg и *.html. Имена файлов можно отредактировать так, как вам будет удобно, не меняя, конечно же, расширения файлов.

По умолчанию программа предлагает сохранить под следующим именем: имя компьютера в сети (я обвёл синим контуром), дата и время создания запроса. Как видно из рисунка, запрос создавался 10.12.2015 в 9 часов 51 минуту 46 секунд на компьютере с именем «imyacompa». Последние 3 символа добавляются случайным образом. Они всегда состоят из трёх цифр и какой-то системы в их генерации я не заметил.

Стоит отметить, что если вы скачали у меня с сайта программу Континент АП версии 3.5.68.0, то скорее всего там старый шаблон печатной формы. После установки данной программы, вам необходимо поменять этот шаблон. Это актуально для нашего региона, а именно Челябинской области. Изменение шаблона печатной формы затронет только печатную форму в формате *.html, на *.req файл это не окажет никакого влияния.

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

Итак, определившись с именем файлов, можно запустить генерацию запроса на сертификат, нажав кнопку «ОК». Как уже было сказано выше, мы получим 2 файла *.req и *.html, а также закрытые ключи на флешке или любом другом носителе.

Дальше необходимо действовать в соответствии с порядком предоставления запросов на сертификат, который действует в вашем УФК. У нас мы распечатываем *.html файл на бумажном носителе, подписываем владельцем сертификата и руководителем организации. Затем передаем в казначейство бумажный экземпляр и *.req файл на съёмном носителе и взамен получаем сертификат.

Итак, запрос отправлен в УФК, мы получили сертификат. Кстати, между отправкой запроса и получением сертификата может пройти время, у всех по разному, но главное дождаться сертификата. Что же дальше? А дальше кликаем правой кнопкой мыши на «щите» Континента АП и делаем то, что показано на рисунке ниже:

А именно: идем опять на «Сертификаты», а потом «Установить сертификат пользователя». Стрелочки на рисунке 3 показывают, что надо делать. Перед этим вставьте ключевой носитель с закрытыми ключами, полученными в результате генерации, а также подготовьте полученный из УФК сертификат. Я его переписал на ключевой носитель, чтобы он всегда был под рукой. Вы можете поступить по своему: переписать его куда угодно, главное, чтобы при установке Вы смогли до него добраться. Кстати, вместе с пользовательским сертификатом, наше УФК выдает также и корневой сертификат Континента АП. Этот сертификат, при установке, должен быть расположен в том же каталоге, что и пользовательский. В общем, на рисунке ниже всё это показано:

Корневой сертификат Континента АП — это файл root. Этот сертификат нужен при установке Континента АП в первый раз. После установки пользовательского сертификата, программа устанавливает корневой, если он не установлен. В противном случае — ничего не делает. Но если в первый раз программа не найдет корневой, то будут проблемы. Поэтому лучше пусть будет всегда вместе с сертификатом пользователя в одном каталоге.

Здесь, рисунок 4, при установке надо выбирать, конечно же, сертификат пользователя. Он подчеркнут мною на картинке. А желтая папка — это закрытые ключи, полученные при генерации запроса. Там шесть файлов с расширением *.key. Кстати, ключи стандартные для программы Крипто Про 3.6. Ведь именно она генерирует эти ключи. Итак, выбрав сертификат пользователя, нажимаем кнопку «Открыть» и попадаем на следующую картинку:

Самая верхняя строчка — это как раз и есть ключевой контейнер с закрытыми ключами. А на этом этапе мы как раз и должны указать программе соответствующий нашему сертификату ключевой контейнер. А именно тот, который был сгенерирован при создании запроса на сертификат. Вообще, позволю себе небольшое отступление… Все ЭЦП, которые генерируются с помощью Крипто Про (вы ведь не думаете, что ключи генерирует Континент АП), состоят из двух частей:

• закрытый ключ — это ключевой контейнер, получаемый при генерации;
• открытый ключ — это сертификат, полученный из казначейства.

Эти части соединяются (опять же, с помощью Крипто Про) только в том случае, если они соответствуют друг другу. Не составляет труда сделать вывод: если одна из частей утеряна или повреждена, то перестаёт работать всё ЭЦП. И исправить эту ситуацию невозможно, кроме генерации новой ЭЦП. Есть способы сделать копию ЭЦП, но в этой статье я касаться этого не буду.

Итак, возвращаемся к «нашим баранам». На рисунке 5 надо обязательно кликнуть по верхней строчке с ключевым контейнером, а потом нажать «ОК». После того как всё это будет проделано, Вы получите следующее окно:

Ну тут только «ОК», других путей не дано… Поздравляю Вас, сертификат установлен. Настало время проверить его работоспособность. Для этого надо сделать так, как подсказывает нам следующая картинка:

ПКМ на «щите», идем «Установить/разорвать соединение» -> «Установить соединение Континент АП» и попадаем в следующее окно:

Нажмем туда, куда показывает красная стрелка (рис. 8). Если на предыдущих этапах Вы следовали этой инструкции, то у Вас выскочит как минимум один сертификат. Вы должны выбрать именно тот, который только что установили (см. рис 9):

Выбрав его, отметьте галочкой «всегда использовать данный сертификат при подключении». В этом случае Ваш Континент АП будет подключаться к серверу используя указанный сертификат. В противном случае (если галка не установлена), он будет предлагать выбрать сертификат при каждом подключении. Чтобы узнать правильно ли был выбран сертификат, можно воспользоваться кнопкой «Свойства». Она покажет всё о выбранном сертификате. В конце, как всегда кнопка «ОК». Начнется процесс подключения Континента АП к серверу доступа. Если все сделано правильно, то в результате вы увидите в трее, как «щит» сменил цвет с серого на синий:

Если у Вас получилось то же, что и у меня, то я рад поздравить Вас с удачной установкой сертификата для континента АП. После того, как Вы подключились к серверу доступа, можете загружать СУФД и начинать в ней работать.

P.S. Ну и ещё: Я думаю, что я достаточно подробно тут всё изложил. Но все равно могут возникнуть какие-нибудь вопросы. В этом случае пишите их в комментариях ниже. Кстати, для зарегистрированных пользователей моего сайта, комментарии появляются сразу, без модерации.

И напоследок… Если вам понравилась эта статья и вы почерпнули из нее что-то новое для себя, то вы всегда можете выразить свою благодарность в денежном выражении. Сумма может быть любой. Это вас ни к чему не обязывает, все добровольно. Если вы всё же решили поддержать мой сайт, то нажмите на кнопку «Поблагодарить», которую вы можете видеть ниже. Вы будете перенаправлены на страницу моего сайта, где можно будет перечислить любую денежную сумму мне на кошелек. В этом случае вас ждет подарок. После успешного перевода денег, вы сможете его скачать.

04 декабря 2018

До конца 2018 года все аккредитованные удостоверяющие центры России должны были перейти на формирование и проверку сертификатов квалифицированной электронной подписи в соответствии со стандартом ГОСТ Р 34.10-2012.

Эксперты «Инфотекс Интернет Траст» рассказывают о процессе перехода на новый криптографический стандарт.

ГОСТ Р 34.10-2012 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи» — российский криптографический стандарт, описывающий алгоритмы формирования и проверки электронной подписи, принятый и введённый в действие вместо ГОСТ Р 34.10-2001 Приказом Федерального агентства по техническому регулированию и метрологии от 7 августа 2012 года №215-ст.

Введение нового стандарта

В начале 2014 года ФСБ России известила разработчиков средств криптографической защиты информации о начале перехода на использование нового национального стандарта ГОСТ Р 34.10-2012 в средствах электронной подписи для информации, не содержащей сведений, составляющих государственную тайну.

Документ ФСБ России №149/7/1/3-58 от 31.01.2014 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования», выписка из которого была опубликована на сайте ТК26, устанавливал следующие требования:

• после 31 декабря 2013 года прекратить сертификацию средств электронной подписи на соответствие требованиям к средствам электронной подписи, утверждённым приказом ФСБ России от 27.12.2011 г. №796, если в этих средствах не предусматривается реализация функций в соответствии с ГОСТ Р 34.10-2012;
• после 31 декабря 2018 года запретить использование ГОСТ Р 34.10-2001 для формирования электронной подписи.

В октябре 2017 года Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации опубликовало на портале Федерального ситуационного центра электронного правительства Разъяснение по переходу на ГОСТ Р 34.10-2012, в котором подтверждалось, что использование схемы ГОСТ Р 34.10-2001 для формирования электронной подписи после 31 декабря 2018 года не допускается, в том числе и для формирования списка отзыва сертификатов, а после 31 декабря 2018 года формирование электронной подписи должно производиться по алгоритму ГОСТ Р 34.10-2012.

Также в разъяснении Минкомсвязи сообщалось о том, что выпуск сертификатов для подчиненных аккредитованных удостоверяющих центров с использованием схемы подписи, установленной стандартом ГОСТ Р 34.10-2012, планируется начать не позднее середины июля 2018 года.

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

В соответствии с разъяснением Минкомсвязи сценарий перевода пользователей на работу с квалифицированными сертификатами, выпущенными по ГОСТ-2012, предполагал, что все пользователи должны будут получить сертификаты, сформированные в соответствии с новым стандартом, несмотря на то, что удостоверяющие центры могли приступить к выпуску этих сертификатов только с августа 2018 года — после получения в Головном удостоверяющем центре квалифицированного сертификата подчинённого удостоверяющего центра, сформированного по ГОСТ-2012.

16 июля 2018 года Минкомсвязь опубликовала Уведомление о начале выпуска сертификатов ключей проверки электронных подписей подчинённых удостоверяющих центров на Головном удостоверяющем центре в соответствии с ГОСТ Р 34.10-2012, после чего аккредитованные удостоверяющие центры, запросившие в Головном удостоверяющем центре сертификат подчинённого удостоверяющего центра, сформированный по ГОСТ-2012, получили возможность выпускать сертификаты пользователей в соответствии с новым стандартом.

Чем вызвана необходимость перехода на новый ГОСТ?

В 2012 году было выпущено два новых стандарта — ГОСТ Р 34.10-2012 по формированию и проверке электронной подписи и ГОСТ Р 34.11-2012 по функции хэширования. Новые стандарты заменили ГОСТ по электронной подписи 2001 года и ГОСТ по функции хэширования 1994 года. В алгоритме формирования и проверки электронной подписи нового стандарта изменений не произошло, а вот функция хеширования существенно изменилась. Новая российская функция хеширования Стрибог с криптографической точки зрения существенно превосходит ту, что использовалась ранее и была описана в стандарте 1994 года.

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

Проблемы перехода на ГОСТ-2012

В октябре 2017 года, после того как Минкомсвязь объявила о том, что выпуск сертификатов для подчиненных удостоверяющих центров по схеме ГОСТ Р 34.10-2012 планируется начать не ранее июля 2018 года, стало ясно, что к установленному ФСБ России контрольному сроку, после которого запрещается использование ГОСТ-2001, — 31 декабря 2018 года, затруднительно обеспечить безболезненный перевод всех владельцев сертификатов ГОСТ-2001 на сертификаты ГОСТ-2012 без существенных дополнительных расходов со стороны удостоверяющих центров.

В связи с этим весной 2018 года Минкомсвязь инициировала ряд совещаний с представителями аккредитованных удостоверяющих центров по вопросу организации перехода на схему формирования электронной подписи по ГОСТ-2012. В ходе совещаний обсуждались проблемы удостоверяющих центров, связанные с жестким требованием обеспечить всех пользователей сертификатами ГОСТ-2012 до конца 2018 года, поскольку с начала 2019 года использование сертификатов ГОСТ-2001 запрещалось утвержденным ФСБ России порядком перехода на новый стандарт.

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

С какими сложностями сопряжён переход на новый ГОСТ?

Процесс перехода на новый ГОСТ достаточно длительный. Средства электронной подписи, в обязательном порядке поддерживающие новые ГОСТы, разрабатываются с конца 2013 года — с этого момента не принимаются технические задания на разработку средств электронной подписи без поддержки ГОСТ Р 34.10/11-2012. Соответственно, поскольку срок действия сертификата на средства электронной подписи и средства удостоверяющего центра обычно составляет 3 года, все такие сертифицированные средства уже давно поддерживают новые алгоритмы.

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

Еще одно препятствие на пути к применению новых сертификатов — неготовность информационных систем к приёму и проверке электронной подписи, сформированной по новому ГОСТу.

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

На момент написания статьи (ноябрь 2018 года) проблема в большей степени заключается в готовности информационных систем, чем удостоверяющих центров. Не все информационные системы готовы принимать сертификаты по новому стандарту при том, что до конца года осталось менее двух месяцев. Будем надеяться, что к первому января процесс перехода полностью завершится.

Продление срока действия ГОСТ Р 34.10-2001

Учитывая вышеуказанные обстоятельства, ФСБ продлила срок действия стандарта ГОСТ Р 34.10-2001 до 31 декабря 2019 года письмом от 07.09.2018 №149/7/6-363 после консультаций с исполнительными органами власти, представителями удостоверяющих центров, разработчиками СКЗИ, операторами ИС и порталов.

В связи с этим 12 сентября 2018 года Минкомсвязь опубликовала новое Уведомление об организации перехода на использование схемы электронной подписи по ГОСТ Р 34.10-2012 с подробным планом мероприятий по реализации перехода на новый стандарт, сроками перехода и рекомендациями производителям средств электронной подписи и удостоверяющих центров, аккредитованным удостоверяющим центрам, владельцам квалифицированных сертификатов и операторам информационных систем, в которых используется электронная подпись.

Основные положения уведомления Минкомсвязи, непосредственно касающиеся аккредитованных удостоверяющих центров:

• срок действия стандарта ГОСТ Р 34.10-2001 продлевается до 31 декабря 2019 года;
• до конца 2018 года производители средств электронной подписи должны продлить сроки действия сертификатов соответствия ФСБ России на средства электронной подписи, поддерживающие ГОСТ-2001, иначе электронные подписи, формируемые в 2019 году по ГОСТ-2001 с помощью средства ЭП со сроком действия сертификата ФСБ России до 31 декабря 2018 года, не будут считаться квалифицированными;
• после 31 декабря 2019 года аккредитованные удостоверяющие центры должны прекратить выпуск квалифицированных сертификатов по схеме ГОСТ-2001;
• владельцы квалифицированных сертификатов должны быть оповещены о том, что создание квалифицированной ЭП по схеме ГОСТ-2001 после 31 декабря 2019 года будет невозможным в связи с тем, что сертификаты соответствия ФСБ России на средства ЭП, поддерживающие ГОСТ-2001, прекратят свое действие 1 января 2020 года;
• при выдаче квалифицированных сертификатов для ключей ГОСТ-2001 после 30 сентября 2018 года аккредитованные удостоверяющие центры должны ограничивать период их действия датой не позднее 31 декабря 2019 года (например, ограничением периода действия сертификата или включением в состав сертификата расширения Private Key Usage Period со значением, не превосходящим 31 декабря 2019 года);
• мероприятия по встраиванию ГОСТ-2012 в информационные системы, использующие электронную подпись, и ввод их в эксплуатацию должны быть завершены до 31 декабря 2018 года;
• информация о готовности ИС к работе с электронной подписью по ГОСТ-2012 будет публиковаться на портале Федерального ситуационного центра электронного правительства.

Переход к использованию сертификатов по ГОСТ-2012: что важно знать абонентам

На основании письма ФСБ РФ от 07.09.2018 №149/7/6-363 и Уведомления Минкомсвязи об организации перехода на использование схемы электронной подписи по ГОСТ Р 34.10-2012, использование стандарта ГОСТ Р 34.10-2001 для формирования электронной подписи продлевается до 31 декабря 2019 года. Начиная с 1 января 2020 года формировать электронную подпись можно будет только в соответствии с ГОСТ Р 34.10-2012.

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

*на правах рекламы.

Инструкция по созданию сертификата для программы Континент АП

Во первых, сразу напомню о том — что при генерации ключа для СУФД, очень многие забывают, что параллельно с ним еще заканчивается срок действия сертификата для Континент АП. Какое сопроводительное письмо еще писать, что бы казначейство отработало вашу заявку — спрашивайте по месту обслуживания. Здесь чисто «технический» вопрос и сама инструкция.

Нажимаем на значок правой кнопкой мышки и выбираем пункт «Создать запрос на пользовательский сертификат …»

Далее нам надо заполнить поля. Внимательно!!!! Специфика запроса стала иной, теперь нет пункта ФИО — в этом пункте пишем ИНН организации.

Имя сотрудника: Краткое или полное наименовании организации.
Описание: ИНН Организации
Организация: Краткое или полное наименовании организации.
Подразделение: можете оставить пустым, или написать Руководство или название организации
Регион: Ваш регион
Город: Ваш город
e-mail: Ваш электронный адрес
В поле «Электронная форма» обязательно выбираем носитель, куда будет сохраняться .req файл
Важно! Криптопровайдер!!! Код безопасности CSP
Имя контейнера: можете сами придумать. После нажимаем ОК.

Здесь нам придется немного поиграться, почувствуй себя Робин Гудом!

ждем пока шкала станет зеленной на отметке 100%Обязатель запомните пароль, иначе будете делать новый запрос на ЭЦП! Если у Вас не спросил пароль, значит вы ошиблись на 2 этапе и не выбрали нужный Криптопровайдер. Проверяем — устранем — ставим пароль.Выбираем флешку, на которой будет наш будущий ключ для подключения к Континент АПВот собственно и все, на флешке должно появиться два новых файлика. Папка (это закрытые ключи, без них Вы не сможете подключиться к серверу Континент АП и зайти потом в СУФД. А файлик continent.req Вы должне передать в казначейство.

Сегодняшняя статья о программе КриптоПро. При формировании заявок на вход по сертификату появляется сообщение с ошибкой: При формировании запроса произошла ошибка: Error: CertEnroll::CX509Enrollment::_CreateRequest: Неизвестный криптографический алгоритм. 0x80091002 (-2146889726). Расскажем о возможных причинах возникновения проблемы, а ниже дадим краткую инструкцию как исправить сбой. Вот так выглядит само уведомление о проблеме.

При формировании запроса произошла ошибка Error CertEnroll

Причины сбоя

В основном ошибки КриптоПро возникают из-за конфликта версий или ошибок в системном реестре. Конфликт версий связан с некорректной или неполной установкой, удалением программы. При чем не всегда вина на пользователе, виной могут служить:

1. Сбои в операционной системе;
2. Вирусы, вредоносные программы и потенциально опасное ПО;
3. Нелицензионная версия программы
4. Несовместимость с текущей версией Windows или текущей версией программы;
5. Конфликты в системе или неверная разрядность программы (могут быть разные версии программ 32х и 64х разрядных систем);

Узнать разрядность системы можно комбинацией клавиш «Windows+Pause Break”.

Что бы исправить ошибку нужно просмотреть все пункты, но для большинства случаев лечение ошибки сводится к небольшой чистке реестра, о которой мы напишем ниже.

Чистим ветки реестра

Запускаем редактор реестра – сделать это можно написав в командной строке Windows «regedit”. И нажимаем Enter.
В операционной системе Windows 10 даже будет подсвечена эта программа.

Запускаем редактор реестра regedit

Далее идем по пути указанному ниже, открываем папки HKEY_LOCAL_MACHINE, SOFTWARE, Microsoft.

Открываем нужную папку в реестре

Далее находим и удаляем следующие ветки записей для Windows x64 – две, для систем разрядности x32 только первую.

Соблюдайте осторожность выполняя любые действия в реестре операционной системы. Можно удалить необходимые системе записи ключей и повредить работоспособность ПК.

Если ошибка появилась вновь, попробуйте сделать следующее:

1. Предварительно сохраните все нужные данные и заявки на сертификаты;
2. Удалите полностью программу с вашего компьютера;
3. Затем почистите реестр по инструкции выше;
4. Установите последнюю КриптоПро для вашей системы;

Заключение и рекомендации

Надеюсь вы знаете как исправить ошибку в КриптоПро при формировании запроса Error: CertEnroll. Если у вас остались вопросы задавайте из в комментариях к этой странице.
Рекомендуем держать последнюю версию одной из антивирусных программ типа Касперского, ESET Nod32 или Доктор Веб с актуальными антивирусными базами. В наше время защита информации одна из приоритетных задач в повседневном использовании ПК.
Перед установкой программ внимательно читайте список поддерживаемой версии Windows и ее разрядности. Напишите в комментариях помогла ли вам данная инструкция. Так же задавайте другие вопросы по работе программы или ошибках – наша команда постарается в кратчайшие сроки дать вам работоспособные способы решения проблем.