Сертификат dss контур для айфон

Как выпустить новую электронную подпись вместо Контур.Сертификата

Инструкция для тех, кто перевыпускает Контур.Сертификат.

Контур.Сертификата больше нет

Раньше для отправки отчёта вам нужен был только телефон, на который приходило СМС с кодом. Вы вводили код в Эльбу, и отчёт отправлялся. Так работал Контур.Сертификат, но эта технология электронной подписи устарела. Поэтому при перевыпуске мы предлагаем выбрать новую: DSS или сертификат на носителе — эти решения безопаснее и сертифицированы ФСБ.

Удобен, как Контур.Сертификат, только отправку отчёта надо подтверждать не с помощью СМС, а через мобильное приложение.

Достаточно установить приложение myDSS на телефон и привязать к нему свою электронную подпись. Каждый раз, когда вы будете отправлять отчёт из Эльбы, в приложение будет приходить запрос на подтверждение отправки. Вы соглашаетесь — отчёт из Эльбы отправляется. Для этого вам нужен телефон на iOS или Android с доступом в интернет.

Чтобы выпустить сертификат DSS, в задаче по выпуску подписи нажмите «У меня есть телефон на iOS или Android‎» и следуйте инструкции.

Подпись на носителе

Такой сертификат нужно установить в реестр компьютера или на флэшку. Подойдёт тем, кто планирует пользоваться подписью на Госуслугах, nalog.ru и других сервисах.

Чтобы установить электронную подпись на носителе, нажмите в задаче на ссылку «У меня нет подходящего телефона».

Разница между DSS и подписью на носителе

Если ещё не определились с типом подписи, посмотрите таблицу ниже:

Подпись на носителе

Где хранится подпись

На нашем сервере, но доступ к ней — только с вашего мобильного телефона

компьютер или флэшка

только iOS не ниже 8.0 версии или Android не ниже 4.0 версии

удобнее работать на Windows, чем на Mac, потому что на Mac сложно установить специальное ПО для подписи

— пока телефон рядом, сможете отправить отчёт с любого компьютера или мобильного;
— если потеряете телефон или забудете пароль, то восстановите доступ к подписи без перевыпуска.

— пока на компьютере установлена подпись/вставлена флэшка с подписью, отчёт отправляется без дополнительного подтверждения;
— можно использовать в сервисах других компаний (на сайте налоговой, Госуслуг).

если телефон без доступа к интернету, то отчёт отправить не получится

— если потеряете флэшку с подписью, то придётся её перевыпускать;

— если установили подпись на компьютер, то будете к нему привязаны;

— не получится отправить отчёт с телефона.

Статья актуальна на 01.02.2021

Получайте новости и обновления Эльбы

Подписываясь на рассылку, вы соглашаетесь на обработку персональных данных и получение информационных сообщений от компании СКБ Контур

Источник

Сертификат dss контур для айфон

Раздел содержит руководство разработчика по выпуску сертификата пользователя. В разделе приведены основные сценарии использования, примеры HTTP-запросов и ответов сервисов DSS.

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

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

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

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

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

Примечание

В примере рассматривается выпуск сертификата пользователя через Сторонний УЦ. Созданный на шаге 3 запрос на сертификат (PKCS#10) Пользователь или Оператор самостоятельно передать в УЦ для выпуска Сертификата. Выпущенный сертификат должен быть установлен на Сервисе Подписи через API.

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

Параметры выпуска запроса на сертификат можно получить из политики Сервиса Подписи (метод /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

Примечание

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

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

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

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

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

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

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

HTTP-код	Ошибка	Описание
400	pending_requests_exist	У пользователя есть необработанный запрос на сертификат (статус PENDING).

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

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

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

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

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

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

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

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

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

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

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

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

Запрос на сертификат (PKCS#10) в формате Base64 содержится в поле Base64Request структуры DSSCertRequest.

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

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

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

Аутентификация Оператора DSS производится по сертификату (HTTPS с аутентификацией клиента).

Для получения 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 – зарегистрированный на Центре Идентификации адрес возврата (по этому адресу будет возвращён запрошенный код авторизации). Допустимые значения данного параметра сохраняются в ЦИ на этапе регистрации клиента.
• response_type – в данном сценарии всегда должен иметь значение code.
• scope – области использования маркера. Должен содержать значение dss.
• resource – идентификатор Сервиса Подписи.

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

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

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

• ответ сервера будет иметь статус HTTP 302
• В заголовке Location будет сожержаться адрес получения AccessToken.

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

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

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

HTTP-код	Ошибка	Описание
400	invalid_client	OAuth-клиент не зарегистрирован или неверно указан clienID
400	unauthorized_client	OAuth-клиент использует незарегистрированный сценарий аутентификации (Flow)
400	invalid_request	Неверно сформирован параметр resource
500	An error has occurred	1. Проверяющая сторона с идентификатором resource не зарегистрирована.

Получение AccessToken

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

• grant_type — тип разрешения, в данном сценарии равен authorization_code.
• code – код авторизации, полученный на предыдущем шаге.
• resource – идентификатор Сервиса Подписи.
• redirect_uri – зарегистрированный на Центре Идентификации адрес возврата.

В заголовке Authorization HTTP-запроса клиент должен передать идентификатор OAuth-клиента и секрет (если используется): Authorization: Basic Base64( : )

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

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

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

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

Примечание

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

HTTP-код	Ошибка	Описание
400	invalid_client	OAuth-клиент не зарегистрирован или неверно указан clienID
400	unauthorized_client	OAuth-клиент использует незарегистрированный сценарий аутентификации (Flow)
400	invalid_request	Неверно сформирован параметр resource
400	invalid_grant	Невалидный код авторизации.
500	An error has occurred	1. Проверяющая сторона с идентификатором resource не зарегистрирована.

Получение делегирующего 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. Для получения закодированного значения необходимо выполнить следующее преобразование:

Внимание!

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

В заголовке Authorization HTTP-запроса клиент должен передать идентификатор OAuth-клиента и секрет (если используется): Authorization: Basic Base64( : )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTTP-код	Ошибка	Описание
400	invalid_certificate_format	Сертификат имеет неверный формат. Например, сертификат передан с заголовками.

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

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

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

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

В заголовке Authorization HTTP-запроса клиент должен передать идентификатор OAuth-клиента и секрет (если используется): Authorization: Basic Base64( : )

Примечание

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

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

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

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

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

Источник