Ошибка создания запроса на сертификат 1с

Обновлено: 05.07.2024

Добрый день! Подскажите пожалуйста сертификат готов, как войти в личный кабинет если у старого сертификат вышел срок?

matreshka пишет: Добрый день! Подскажите пожалуйста сертификат готов, как войти в личный кабинет если у старого сертификат вышел срок?


Меняйте системную дату на компе. Дату назад переведите и пробуйте.

Flynn пишет: Пытаюсь разобраться с запросом на сертификат для Континента. Заполнил все поля. Нажимаю 'ОК'. Выдает ошибку 'Ошибка создания запроса 0x80090017. Тип поставщика не определен'. Где может быть проблема?

КриптоПро для этого нужен установленный на компьютере?

Подскажите вы нашли как решить эту проблему, у меня такая же песня

Flynn пишет: Пытаюсь разобраться с запросом на сертификат для Континента. Заполнил все поля. Нажимаю 'ОК'. Выдает ошибку 'Ошибка создания запроса 0x80090017. Тип поставщика не определен'. Где может быть проблема?

КриптоПро для этого нужен установленный на компьютере?

Подскажите вы нашли как решить эту проблему, у меня такая же песня

Flynn пишет: Пытаюсь разобраться с запросом на сертификат для Континента. Заполнил все поля. Нажимаю 'ОК'. Выдает ошибку 'Ошибка создания запроса 0x80090017. Тип поставщика не определен'.

По приведенной ссылке на совет ТП от К-АП не вполне ясно о восстановлении чьего криптопровайдера речь.
А вот на этом форуме автор поста вполне подробно расписал всю картину маслом: Для тех у кого ошибка с криптопровайдером 0х80090017 тип поставщика не определен
Есть конечно варианты переустановки К-АП с или без провайдера от КБ. Но, имхо, это зависит от следующего:

Flynn пишет: КриптоПро для этого нужен установленный на компьютере?

Логично предположить, что К-АП на АРМе пользователя нужен для подключения к СУФД, а ей таки необходимо установленное СКЗИ от другого провайдера - КриптоПро.
Тогда, имхо, следует:
1. Обновить КриптоПро как минимум до версии 4.0.9944 (R3), а лучше до 4.0.9963 (R4);
2. Переустановить Континент-АП с чистящей утилитой CspCleaner от КБ до версии минимум 3.7.5.514, а лучше до 3.7.7.651.
Если верить разрабам сих СКЗИ в последних версиях указанных творений уже д.б. решены проблемы "неуживчивости" на одном АРМ-е 2-х криптопровайдеров - от КриптоПро и Кода Безопасности.

MotoArhangel пишет: Либо проблема с гостами.

Либо со старыми версиями крипты и К-АП, не дружащими с ГОСТ-2012, да и друг с другом.
Хотя безусловно: корневой от МКС и промежуточный от ФК серты по ГОСТ-2012 + актуальный корневой для Континента из вашего УФК конечно д.б. установлены, еще до генерации, однозначно! (с) Бесконечно можно смотреть на 3 вещи: огонь, воду и . открытие сайта "веселые картинки" ГМУ (опыт IT-шника) Сформировал запрос на сертификат, пришел отказ, необходимо изменить заявление. Вошел, изменил распечатал, пока подписывал глюканул IE и отстрелился. Теперь не могу войти на страницу сформированного запроса, при вводе номера запроса, данных организации и капчи говорит: "Указанный запрос на сертификат уже загружен в систему". Не подскажете как еще можно попасть на страницу сформированного запроса для внесения изменений? Или уже никак, только начать все по новой?

sysrise пишет: Сформировал запрос на сертификат, пришел отказ, необходимо изменить заявление. Вошел, изменил распечатал, пока подписывал глюканул IE и отстрелился.

Это не IE глюканул, наверно, вы как-то вошли на старую незакрытую страницу, или еще что-то.

sysrise пишет: Теперь не могу войти на страницу сформированного запроса, при вводе номера запроса, данных организации и капчи говорит: "Указанный запрос на сертификат уже загружен в систему".

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

sysrise пишет: Не подскажете как еще можно попасть на страницу сформированного запроса для внесения изменений? Или уже никак, только начать все по новой?

В разделе приведены сценарии выпуска сертификата:

Перед началом интеграции Администратору DSS необходимо:

  • Выпустить и зарегистрировать на DSS cертификат аутентификации Оператора DSS
  • Зарегистрировать OAuth-клиента
  • Подключить к Сервису Подписи модуль взаимодействия с УЦ

Общий подход для Пользователей и Операторов при выпуске сертификата:

  1. Аутентификация на Центре Идентификации
  2. Получение параметров выпуска запроса на сертификат
  3. Создание запроса на сертификат
  4. Подтверждение создания запроса на сертификат (для пользователей)
  5. Установка сертификата
Примечание

Создание запроса на сертификат

Параметры выпуска запроса на сертификат можно получить из политики Сервиса Подписи (метод /policy). Политика Сервиса Подписи содержит:

  • список параметров Удостоверяющих Центров, подключенных к DSS;
  • список криптопровайдеров, подключенных к DSS.

Каждый элемент списка параметров УЦ содержит:

  • Идентификатор УЦ
  • Тип УЦ
  • Шаблон различительного имени (Distinguished Name)
  • Список шаблонов сертификатов
  • Отображаемое имя

В интерфейсе интегрируемой системы должна быть возможность выбора Удостоверяющего Центра, для которого будет создан запрос на сертификат. Для каждого Удостоверяющего Центра Сервис Подписи передаёт отображаемое имя (DSSCAPolicy -> Name ), которое может быть показано пользователю.

Для выбранного пользователем Удостоверяющего Центра в интерфейсе интегрируемой системы должна отображаться форма для заполнения идентифицирующих данных. Форма составляется в соответстии с шаблоном имени (DSSCAPolicy -> NamePolicy ). У каждого компонента имени в шаблоне есть отображаемое имя ( Name ), строковый идентификатор ( StringIdentifier ) и требование к заполнению ( IsRequired ).

Также на форме создания запроса должен быть отображен спискок шаблонов сертификатов ( EkuTemplates ). Каждый шаблон сертификата имеет отображаемое имя.

Если политика Сервиса Подписи содержит более одного криптопровайдера, необходимо предоставить пользователю возможность выбора.

Данные с формы передаются в метод /requests для создания запроса на сертификат:

  • Идентификатор Удостоверяющего Центра
  • Различительное имя
  • Шаблон сертификата
  • ПИН-код на закрытый ключ (опционально)
  • Идентификатор криптопровайдера (опционально)

Данные передаются в структуре CertificateRequest.

Идентификатор Удостоверяющего Центра ( AuthorityId ) является константой. Он может быть получен от Администратора DSS и зафиксирован в настройках интегрируемой системы.

Примечание

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

Различительное имя может быть передано в двух форматах:

  • Список пар oid:value ( DistinguishedName )
  • Строковое представление ( RawDistinguishedName )

Объектные идентификаторы (OID) компонентов имени указаны в шаблоне имени.

Примечание

Строковое представление различительного имени кодируется согласно RFC 1779.

Шаблон сертификата представляет собой набор объектных идентификаторов, которые попадут в расширение Enhanced Key Usage (EKU) запроса на сертификат, или идентификатор шаблона сертификата КриптоПро УЦ 2.0, который попадёт в расширение Certificate Template (1.3.6.1.4.1.311.21.7).

Шаблон передаётся через разные поля запроса на сертификат в зависимости от типа:

  • Enhanced key usage - передаётся в дополнительных параметрах запроса Parameters в ключе EkuString в формате oid1,oid2. oidN.
Примечание

Данный шаблон используется при создании запроса на сертификат к Удостоверяющему Центру типа 0 (КриптоПро УЦ 1.5) и 2 (Сторонний УЦ).

  • Certificate Template - передаётся в параметре Template запроса на сертификат.
Примечание

Данный шаблон используется при создании запроса на сертификат к Удостоверяющему Центру типа 1 (КриптоПро УЦ 2.0) и 2 (Сторонний УЦ).

Идентификатор криптопровайдера должен быть задан, если в Политике Сервиса Подписи доступно более одного криптопровайдера. Идентификатор криптопровайдера (DSSCSPPolicy -> GroupId ) передаётся в дополнительных параметрах запроса в ключе GroupId

Создание запроса на сертификат с подтверждением при помощи вторичной аутентификации

При создании запроса на сертификат с подтверждением при помощи вторичной аутентификации требуется выполнить следующую последовательность действий (шагов):

При этом в массиве параметров транзакции метода /transactions должны быть отображены следующие поля запроса на сертификат:

CertificateRequest Параметры транзакции
AuthorityId CAId
PinCode Не используется
Template CertTemplateOid
DistinguishedName Не используется
RawDistinguishedName CertSubjectName
Parameters ->EkuString EkuString
Parameters ->GroupId GroupId

Примечание

При создании запроса на сертификат с подтверждением с подтверждением при помощи вторичной аутентификации различительное имя может быть передано только в строковом представлении.

Примеры запросов

Пример запроса с указанием различительного имени в строковом представлении:

Пример запроса с указанием различительного имени в виде набора компонентов:

Пример запроса с указанием шаблона сертификата:

Запрос на сертификат с подтверждением:

Типовые ошибки

Обработка ответа Сервиса Подписи

При успешном создании запроса на сертификат Сервис Подписи в ответе вернёт структуру DSSCertRequest.

Дальнейшее поведение пользователя зависит от значения поля Status в структуре DSSCertRequest и типа УЦ, на котором создавался запрос на сертификат.

ACCEPTED - запрос на сертификат принят и обработан УЦ. В данном случае в поле CertificateID будет записан идентификатор выпущенного сертификата.

REGISTRATION - запрос на сертификат принят в КриптоПро УЦ 2.0 и находится на этапе регистрации пользователя УЦ.

В зависимости от настроек подключения DSS к КриптоПро УЦ 2.0, необходимо:

  • ожидать одобрения запроса на сертификат Администратором УЦ;
  • одобрить запрос Оператором DSS.

PENDING - запрос на сертификат находится в обработке.

Если запрос отправлен на КриптоПро УЦ 2.0, то в зависимости от настроек подключения DSS к КриптоПро УЦ 2.0 необходимо:

  • ожидать одобрения запроса на сертификат Администратором УЦ;
  • одобрить запрос Оператором DSS.

Если запрос создавался через "Сторонний Удостоверяющий Центр", необходимо:

  • скачать запрос на сертификат по идентификатору /requests;
  • передать запроса на сертификат в УЦ;
  • выпущенный сертификат установить в DSS.

REJECTED - запрос отклонён. Дальнейшая обработка запроса невозможна. Для выяснения причин отклонения запроса необходимо обратиться к Администратору УЦ.

Выпуск сертификата Оператором DSS

Аутентификация Оператора DSS на Центре Идентификации

Для получения AccessToken используется OAuth сценарий с использованием кода авторизации. Подробная информация по протоколу аутентификации: The OAuth 2.0 Authorization Framework

Администратор DSS должен предварительно настроить OAuth клиента на сервере DSS:

  • создав нового клиента:
  • измененив настройки существующего клиента:
Примечание

Значение RedirectUri urn:ietf:wg:oauth:2.0:oob:auto говорит серверу DSS о том, что AccessToken необходимо вернуть непосредственно в ответе на запрос клиента. Данное значение используется в тех случаях, когда для клиента трудозатратно открыть слушателя на другом URL.

AccessToken , полученный на шаге 3, позволит Оператору DSS получить Политику Сервиса Подписи.

Для выполнения действий от имени пользователя на Сервисе Подписи необходимо получить делегирующий AccessToken. Делегирующий AccessToken позволит Оператору DSS выпустить сертификат пользователя, просмотреть список сертификатов и запросов пользователя и т.п.

Инициация аутентификации

Конечная точка для аутентификации Оператора DSS: /authorize/certificate

Примеры запросов

Получение кода авторизации

В случае успешной аутентификации

Т.е. в примере используется специальное значение redirect_uri , то клиенту необходимо из заголовка Location извлечь значение параметра code. Значение параметра code будет использовано для получения AccessToken на следующем шаге.

Пример ответа

Типовые ошибки

Получение AccessToken

Для получения маркера доступа используется конечная точка oauth/token.

Пример запроса

В случае успешной аутентификации ответ будет содержать:

  • access_token - AccessToken, выпущенный Центром Идентификации DSS
  • token_type - Тип токена
  • expires_in - Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи.

Примечание

Данный access_token не даёт право Оператору DSS выполнять операции на Сервисе Подписи от имени пользователей. access_token может быть использован для получения Политики Сервиса Подписи.

Получение делегирующего AccessToken

Для получения AccessToken для делегирования используется конечная точка oauth/token. Подробная информация по протоколу получения AccessToken для делегирования: OAuth 2.0 Token Exchange.

  • grant_type - тип разрешения, в данном сценарии равен urn:ietf:params:oauth:grant-type:token-exchange.
  • resource – идентификатор Сервиса Подписи.
  • actor_token - AccessToken, полученный на предыдущем шаге
  • actor_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
  • subject_token_type – тип маркера доступа, должен иметь значение urn:ietf:params:oauth:token-type:jwt.
  • subject_token – неподписанный JWT-токен, содержащий логин управляемого пользователя.

В декодированном виде subject_token имеет вид:

Пример кодирования JWT-токена можно посмотреть по ссылке.

Первая часть (до точки) называется header, вторая – payload. Для получения закодированного значения необходимо выполнить следующее преобразование:

Внимание!

Символ “.” в конце получившегося значения является обязательным.

Пример запроса

В случае успешной аутентификации ответ будет содержать:

  • access_token - делегирующий AccessToken, выпущенный Центром Идентификации DSS
  • token_type - Тип токена
  • expires_in - Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи.

Пример ответа

Получение Политики Сервиса Подписи

Пример запроса

Пример ответа

Создание запроса на сертификат

Пример запроса

Согласно параметрам УЦ из Политики Сервиса Подписи Оператор формирует запроса на сертификат.

Пример ответа

Установка сертификата

Сервер вернул запрос на сертификат в поле Base64Request . Запрос на сертификат необходимо передать в Удостоверяющий Центр для выпуска сертификата.

Пример запроса

Пример ответа

Выпуск сертификата Пользователем DSS

Аутентификация пользователя на Центре Идентификации

В примере рассматривается авторизация с использованием учётных данных пользователя (логин/пароль). Подробная информация по протоколу аутентификации: The OAuth 2.0 Authorization Framework

  • grant_type - тип разрешения, в данном сценарии равен password.
  • password – пароль пользователя.
  • resource – идентификатор Сервиса Подписи.
Примечание

В примере значение параметр password оставлено пустым, так как пользователю в качестве первичной аутентификации назначен метод "Только Идентификация"

Примеры запросов

В случае успешной аутентификации ответ будет содержать:

  • access_token - AccessToken, выпущенный Центром Идентификации DSS
  • token_type - Тип токена
  • expires_in - Время жизни токена в секундах

Значение параметра access_token необходимо будет использовать при обращениях к Сервису Подписи и Сервису Подтверждения Операций.

1С:Подпись – обеспечивает заполнение заявки на регистрацию квалифицированного сертификата ключа проверки электронной подписи в Удостоверяющем центре "1С", получение и установку сертификата на компьютере пользователя.

Сертификат ключа проверки электронной подписи (СКП) – электронный документ подтверждающий соответствие между открытым ключом и информацией, идентифицирующей владельца ключа. Содержит информацию о владельце ключа, сведения об открытом ключе, его назначении и области применения

Заявление – бумажный документ, подписываемый законным представителем организации, включающий реквизиты, подлежащие указанию в СКП и в реестре изданных сертификатов (в соответствии с требованиями законодательства РФ), соглашение о присоединении к Регламенту Удостоверяющего центра.

Мастер подготовки заявки – компонента программного продукта 1С:Подпись, предназначенная для подготовки заявки в пошаговом режиме.

Криптопровайдер – программа, осуществляющая реализацию криптографических алгоритмов для выполнения электронной подписи.

Настройка криптопровайдера

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

Установка и настройка криптопровайдеров осуществляется в соответствии с технической документацией на эти продукты.

В настройках информационной базы необходимо указать установленный криптопровайдер, для этого перейдите в Настройки электронной подписи и шифрования

на вкладку «Программы» и нажмите кнопку «Добавить».

Выберите из списка криптопровайдер, установленный в Вашей системе и нажмите кнопку «Записать и закрыть».

Запуск Мастера

Для запуска мастера подготовки заявки на СКП необходимо перейти на вкладку «Сертификаты», нажать кнопку «Добавить» и выбрать пункт «Заявление на выпуск сертификата».

Подготовка заявления на выпуск нового квалифицированного сертификата

Выбор типа заявителя

Выберите нужный тип заявителя с помощью выпадающего меню.

Заполнение заявки

Для Юридических лиц:

Заполните реквизиты организации вручную или выберите из справочника организаций.

Заполните данные владельца сертификата или выберите сотрудника из справочника.

Укажите ФИО, должность и основание полномочий подписанта заявления на изготовление сертификата

Для Индивидуальных предпринимателей:

Заполните реквизиты индивидуального предпринимателя или выберите из справочника.

Заполните данные владельца сертификата - индивидуального предпринимателя.

Для Физических лиц:

Заполните данные владельца сертификата – физического лица или выберите из справочника.

Тут и далее значком «?» указано наличие подсказок и пояснений к порядку заполнения. Кнопка с таким значком в нижнем правом углу позволит перейти в соответствующий раздел справочной системы.

Для автоматического прикрепления Вашей заявки к Личному кабинету обслуживающей организации укажите ее ИНН/КПП или выберите организацию из справочника контрагентов. Это позволит сократить срок рассмотрения Вашей заявки.

Создание ключа электронной подписи

Внимательно проверьте указанные сведения и выберите криптопровайдер, настроенный в разделе 2 данного Руководства.

Сформируйте ключ электронной подписи и запрос с помощью интерфейса криптопровайдера. Для хранения ключа электронной подписи рекомендуется использовать защищенный ключевой носитель (информационный выпуск № 24982 от 21.09.2018 Расширение ассортимента защищенных носителей "Рутокен" для ключей электронной подписи от российского разработчика Компании "Актив").

При необходимости, обращайтесь к технической документации на используемое вами средство электронной подписи.

Подготовка комплекта заявительных документов

Распечатайте и подпишите заявление на изготовление сертификата.

Подготовьте и передайте комплект документов уполномоченному представителю Вашей обслуживающей организации.

Для Юридических лиц:

  • Заявление на выпуск сертификата (подготовленное на предыдущем шаге).
  • Копия* свидетельства о постановке на учет в налоговом органе (ИНН).
  • Копия* свидетельства о государственной регистрации юридического лица (ОГРН) или лист записи ЕГРЮЛ (Форма № Р50007).
  • Копия* документа, удостоверяющего личность представителя организации, указанного для выпуска сертификата.
  • Копия* страхового свидетельства обязательного пенсионного страхования (СНИЛС) представителя организации, указанного для выпуска сертификата.
  • Копия* документа, подтверждающего полномочия представителя организации, указанного для выпуска сертификата (решение собственника, протокол собрания учредителей, выписка ЕГРЮЛ или доверенность)

Для Индивидуальных предпринимателей:

  • Заявление на выпуск сертификата (подготовленное на предыдущем шаге).
  • Копия* свидетельства о постановке на учет в налоговом органе (ИНН).
  • Копия свидетельства о государственной регистрации индивидуального предпринимателя (ОГРН) или лист записи ЕГРИП (Форма Р60009).
  • Копия документа, удостоверяющего личность индивидуального предпринимателя.
  • Копия* страхового свидетельства обязательного пенсионного страхования (СНИЛС) индивидуального предпринимателя.

Для Физических лиц:

  • Заявление на выпуск сертификата (подготовленное на предыдущем шаге).
  • Копия* свидетельства о постановке на учет в налоговом органе (ИНН).
  • Копия документа, удостоверяющего личность физического лица.
  • Копия* страхового свидетельства обязательного пенсионного страхования (СНИЛС) физического лица.

Отправка заявки в 1С:Подпись

Проверка состояния заявления и установка сертификата в контейнер

Для проверки текущего статуса отправленной заявки выберите ее на вкладке «Сертификаты» в Настройках электронной подписи и шифрования и нажмите «Изменить» (F2) в контекстном меню. Нажатием кнопки можно актуализировать ее статус.

По окончании обработки заявки сертификат будет получен и установлен в контейнер автоматически.


Для отправки заявления на выпуск сертификата КЭП, составленного по новой форме, фирма «1С» рекомендует обновить прикладные конфигурации.

Что изменилось в форме заявления

С 1 сентября этого года вступил в силу приказ ФСБ № 795, в котором утверждены новые требования к форме квалифицированного сертификата ключа проверки электронной подписи.

В частности, в форме заявки на получение сертификата в составе дополнительных атрибутов имени появились новые обязательные атрибуты:

  • INNLE для указания ИНН юридических лиц. Значение атрибута INNLE представляет собой строку, состоящую из 10 цифр
  • OGRNIP для указания ОГРНИП владельца квалифицированного сертификата – физического лица, являющегося индивидуальным предпринимателем. Значением атрибута OGRNIP станет строка, состоящая из 15 цифр.
  • IdentificationKind, определяющий метод идентификации заявителя при получении сертификата ключа проверки ЭП. Может иметь значения:
    • 0 – сертификат выдавался при личном присутствии;
    • 1 – без личного присутствия с использованием имеющейся квалифицированной ЭП;
    • 2 – без личного присутствия, по данным паспорта и биометрическим персональным данным;
    • 3 – без личного присутствия с применением единой биометрической системы.

    Подробное описание всех изменений есть в приложении к приказу об утверждении требований к форме квалифицированного сертификата ключа проверки электронной подписи.

    Фирма «1С» рекомендует обновиться

    При этом сертификаты, выпущенные по заявлениям, отправленные до 1 сентября, останутся действительными до окончания их срока действия и не потребуют перевыпуска.

    Поддержка новой формы заявления уже реализована в большинстве тиражных продуктов или запланирована на первую половину сентября. График выпуска обновлений опубликован в разделе «Монитор законодательства» на сайте «1С».

    Читайте также: