Что такое oid сертификата

Объектные идентификаторы области использования ключа

Объектные идентификаторы (OID) определяют отношения, при осуществлении которых электронный документ, подписанный ЭЦП, будет иметь юридическое значение.

OID, зарегистрированные в Удостоверяющем центре, включаются состав следующих расширений сертификата ключа подписи: Key Usage (использование ключа), Extended Key Usage (расширенное использование ключа), Application Policy (политики применения сертификата).

В каждый сертификат издаваемый нашим Удостоверяющим центром включаются следующие OID:

Остальные объектные идентификаторы включаются в издаваемый сертификат на основании Заявления на изготовление сертификата ключа подписи.

Перечень объектных идентификаторов используемых в различных информационных системах

Текст ограниченной лицензии КриптоПро CSP

Ограниченная лицензия на использование любого экземпляра программы для ЭВМ СКЗИ «Крипто-Про CSP» версии 3.6 для использования с ключом электронной подписи (закрытым ключом электронной цифровой подписи) соответствующего сертификата ключа проверки электронной подписи (сертификата ключа подписи) жителями города Москвы, работниками органов исполнительной власти города Москвы и работниками иных учреждений и организаций, осуществляющих свою деятельность в интересах органов исполнительной власти города Москвы и/или участвующих в процессах оказания государственных услуг и/или исполнения государственных функций с использованием современных технологий

Источник

Что такое сертификат ЭЦП

Из нашей статьи вы узнаете:

Под сертификатом электронной подписи понимают официальное свидетельство, подтверждающее то, что ЭЦП принадлежит определённому человеку. Допускается оформление документа как на бумаге, так и в электронном формате. Благодаря наличию последнего можно проверить, является ли ЭП подлинной.

Для чего нужен сертификат эцп? При отсутствии сертификата никто не сможет использовать ЭЦП, так как проверка её подлинности в данном случае будет невозможна. Задача такой проверки — подтверждение авторства подписи и того, что документ является подлинным.

Понятие OID

Object Identifier является дополнительным атрибутом в составе сертификата ЭЦП. Он необязателен, но может предоставить дополнительные данные (например, об обладателе подписи, центре удостоверения, ключах и т.п.). Также работа Object Identifier может быть связана с приложениями и сервисами, используемыми сертификатом ЭП.

ЭЦП и федеральное законодательство

Существует федеральный закон об ЭП №63-ФЗ от 06.04.2011:

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

Рекомендация: перед обращением в центр удостоверения с целью получения ЭЦП нужно заранее знать, какие торговые площадки-онлайн станут сферой её применения. Их следует выбрать заблаговременно, во избежание неожиданностей. Также нужна информация и об OID — для того, чтобы работать на конкретной «виртуальной точке». С этой целью владелец подписи может обратиться в техническую поддержку.

Плюсы электронной подписи

Она уже успела занять серьёзное место в жизни многих людей, особенно тех, кто является руководителем предприятия или организации. Благодаря ЭЦП вы можете:

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

Важно помнить:

Как получают ЭЦП

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

Законодательством предусмотрен срок выдачи ЭЦП на год, после чего её нужно получать заново. Введение этого ограничения связано с вопросами безопасности, а также с обеспечением защитных функций.

Благодаря высокой степени защиты и соответствующим мерам, принятым на законодательном уровне, ЭЦП представляет собой надёжный способ для заверения любых документов.

Процесс получения ЭЦП

Чтобы получить электронную подпись:

Источник

Что такое oid сертификата

Не задан ID пользователя.

Если начинать с базовых понятий, электронное подписание основывается на асимметричных алгоритмах шифрования. Основная особенность этих алгоритмов в том, что для шифрования и расшифровки сообщения используются два разных ключа. Широкой общественности более знакомы симметричные алгоритмы, когда одним ключом (или паролем) мы и шифруем и расшифровываем сообщение, например архивируем файл с паролем или защищаем документ MS Word.

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

При чем тут собственно подпись? Ведь нам надо подписать документ, а не зашифровать его. Для начала надо разобраться, что такое собственно подпись и для чего она нужна. Когда вы ставите свою собственноручную подпись на бумажный документ, вы тем самым заверяете, что именно вы (а не кто-то другой) видели (и согласны) именно этот документ (а не какой-то другой). Важнейшее свойство подписи — неотрекаемость (non-repudiation). Это означает, что подписав документ, вы не можете позже отказаться от этого факта. В случае бумажной подписи вас уличит графологическая экспертиза, в случае электронной — математические методы, основанные на асимметричных алгоритмах шифрования.

Как все это работает, в двух словах. Берем асимметричный алгоритм шифрования, генерируем пару ключей (для шифрования и расшифровки). Ключ шифрования даем человеку, который будет подписывать документы. Он его должен всегда держать при себе и никому не давать. Поэтому его называют «закрытый» ключ. Другой ключ (расшифровки) даем всем желающим, поэтому он «открытый». Подписывая документ, человек должен зашифровать его своим закрытым ключом. На самом деле шифруется не сам документ, так как он может быть достаточно большим, а нам вообще-то и не нужно его шифровать. Поэтому по документу получают хэш — это некая числовая последовательность с большой долей вероятности разная для разных документов, как бы «отпечаток» документа. Его и шифруют закрытым ключом подписанта. Этот зашифрованный хэш и есть электронная подпись документа. Теперь имея документ, подпись и открытый ключ, любой может легко проверить, что именно этот документ был подписан именно этим закрытым ключом. Для этого снова получаем хэш документа, расшифровываем открытым ключом подпись и сравниваем. Должны получить две идентичные числовые последовательности.

Все это прекрасно, но пока мы получили неотрекаемость подписи для закрытого ключа, то есть доказали, что документ подписан конкретным ключом. Нам же необходимо доказать, что он был подписан конкретным человеком. Для этого существуют удостоверяющие центры и цифровые сертификаты. Самое важное, что делает удостоверяющий центр — он удостоверяет, что закрытый ключ принадлежит конкретному лицу. Чтобы это гарантировать, именно удостоверяющий центр генерирует пары ключей и выдает их лично в руки владельцам (есть варианты по доверенности, удаленно, но это уже детали). Вместе с ключами генерируется цифровой сертификат — это электронный документ (бывает и бумажное его представление), в котором содержится информация о владельце ключа, самом ключе, удостоверяющем центре и некоторая другая информация. Владелец, как правило, получает все это добро на защищенном носителе (смарт-карте, ру-токене и так далее), на котором содержится закрытый ключ и сертификат с внедренным открытым ключом. Сам носитель необходимо всегда держать при себе, а скопированный с него сертификат с открытым ключом можно давать всем желающим, чтобы они могли проверить вашу электронную подпись.

Итак, подписание производится закрытым ключом, а проверка подписи открытым. Поэтому фраза «документ подписывается набором OID» (прозвучавшая в упомянутом споре) лишена всякого смысла. В процедуре подписания и проверки участвуют только два ключа, в 63-ФЗ они и названы соответственно — ключ подписи и ключ проверки подписи.

А что такое эти пресловутые OID? Формат цифрового сертификата X.509 позволяет сохранять в нем расширения (extensions). Это некие необязательные атрибуты, при помощи которых можно хранить дополнительную информацию. Каждый такой атрибут является объектом, который задается идентификатором из иерархического справочника. Отсюда OID — Object Identifier. Углубляться в природу самих OID здесь смысла нет. По сути это некоторая дополнительная информация, которая может присутствовать в сертификате.

Данные дополнительные атрибуты могут использоваться для разных целей. Они могут либо предоставлять дополнительную информацию о владельце, ключах, УЦ, либо нести какую-то дополнительную информацию для приложений и сервисов, которые этот сертификат используют. Самое распространенное применение — это управление доступами на основе ролей. Например, в сертификате можно прописать, что владелец ключа является руководителем организации, и это даст ему возможность сразу во всех ИС получить доступ к нужным функциям и сведениям, без необходимости связываться с администраторами каждой ИС и менять настройки доступа. Все это конечно при условии, что все эти ИС используют сертификат пользователя для его авторизации и анализируют один и тот-же атрибут одинаковым образом (для того-то атрибуты и выбираются из справочника, а не задаются произвольно).

Как видим, никакие законодательные нормы не диктуют обязательного наличия в квалифицированном сертификате атрибутов, связанных с авторизацией в каких-либо информационных системах. Откуда тогда эти требования берутся? А исходят они от разработчиков (или «владельцев») конкретных систем. Возьмём например «Методические рекомендации по использованию электронной подписи при межведомственном электронном взаимодействии (версия 4.3)», размещенные на технологическом портале СМЭВ. Действительно, в пункте 6 данного документа читаем: «При подготовке сведений для формирования сертификата ЭП-СП необходимо определить необходимость запроса сведений из Росреестра (выписки из ЕГРП). При необходимости такого запроса в поле “Улучшенный ключ” (OID=2.5.29.37) в сертификате ЭП-СП должен быть указан OID по требованиям Росреестра.». То есть информационная система Росреестра использует этот атрибут для определения сведений, которые можно выдавать владельцу сертификата. Однако этот же документ содержит важное примечание, а именно — данное требование действует до полного запуска ЕСИА (единый сервис авторизации в гос. системах) и подключения к ней системы Росреестра. Это важное замечание, запомним его.

Не буду разбираться с другими ИС, применяемыми в гос. органах. Подозреваю, что там ситуация похожая. Портал госзакупок, электронные торговые площадки, различные бухгалтерские и финансовые приложения также могут требовать наличия тех или иных дополнительных OID в сертификате пользователя. При этом утверждение, что прописывая OID информационной системы в сертификате, я каким-либо образом делегирую ответственность удостоверяющему центру, мягко говоря, неверно. УЦ вносит эти данные в сертификат согласно моей заявки. Если у меня изменилась должность, а я забыл подать заявку на отзыв старого и выпуск нового сертификата, УЦ никак не может отвечать за мою забывчивость. К тому-же закон 63-ФЗ прямо закрепляет ответственность за неправильное использование сертификата за его владельцем. В пункте 6 статьи 17 читаем:
Владелец квалифицированного сертификата обязан:
1) не использовать ключ электронной подписи и немедленно обратиться в аккредитованный удостоверяющий центр, выдавший квалифицированный сертификат, для прекращения действия этого сертификата при наличии оснований полагать, что конфиденциальность ключа электронной подписи нарушена;
2) использовать квалифицированную электронную подпись в соответствии с ограничениями, содержащимися в квалифицированном сертификате (если такие ограничения установлены).

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

Налицо стопроцентное попадание в концепцию, именуемую в мире Attribute Certificate (или Authorization Certificate), о которой говорилось выше и при которой рекомендуется выпускать эти сертификаты другим удостоверяющим центром (Attribute Autority, в отличие от Certificate Authority — обычного УЦ, выпускающего квалифицированные сертификаты ЭП) и по упрощенной схеме. Этот сертификат сам по себе не должен содержать ключа электронной подписи и информации о владельце. Вместо этого он содержит ссылку на сертификат открытого ключа владельца, из которого можно получить остальную необходимую информацию о персоне.

Необходимо заметить, что и эта схема имеет весьма ограниченное применение и не решает всех проблем. Что если очередная информационная система решит использовать то-же поле сертификата “Улучшенный ключ” (OID=2.5.29.37), которое уже занято значением Росреестра, для своих нужд? Вписать два разных значения в одно поле не получится. Следовательно придется выпускать ещё один AC! Другая проблема связана с коротким временем жизни PKC (один год). Если имеем несколько AC (в которых содержится ссылка на персональный сертификат), их все придется перевыпустить по истечении срока PKC. Для эффективного применения AC необходим некий единый центр авторизации пользователей во всех информационных системах, а все приложения должны согласованно и единообразно использовать атрибуты сертификатов.

Такой единый центр авторизации для гос. органов уже есть — это ЕСИА. Вспомним про примечание, касающееся OID’ов Росреестра. В будущем они будут заменены информацией из ЕСИА. Так же должны поступать и прочие информационные системы, в которых работают гос. служащие. Вместо использования AC для авторизации, необходимо интегрироваться с ЕСИА и получать необходимую информацию оттуда. ЕСИА должна иметь возможность привязки квалифицированного сертификата ЭП к учетной записи, таким образом информационные системы смогут проводить аутентификацию пользователя по персональному ключу, а его авторизацию (предоставление доступа к приложению) через ЕСИА. Такая система представляется универсальней и надежней, чем применение полей сертификатов, а в перспективе позволит автоматизировать управление доступами. Если будет создана единая система кадрового учета гос. служащих, ЕСИА сможет брать информацию о полномочиях того или иного лица непосредственно оттуда. Перевелся человек на другую должность — автоматически потерял доступ к одним системам и получил к другим. При этом он продолжает пользоваться своим ключом ЭП для подписания документов, ничего перевыпускать не нужно.

Вывод — OID’ы информационных систем в сертификате, не являясь абсолютным злом сами по себе, требуют взвешенного применения. У данного подхода есть альтернативы, которые стоит рассмотреть, например единые сервисы авторизации.

Источник

Шпоры по сертификатам X.509

Чудище обло, озорно, огромно, стозевно и лаяй.

Кстати что общего между LDAP, SNMP и X.509 ну кроме того, что им еще не скоро предстоит собрать стадионы фанатов? Их объединяет ASN.1 — мета-язык описания объектов древности. Если бы эти технологии создавали сейчас, в ход бы пошли XML, DTD или какой-нибудь другой ML. Но в то время стандарты создавались титанами, для которых даже SNMP был простым делом.

Словарный запас

Определение X.509 сертификатов есть в архиве ITU-T

Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1 SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.

Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.

Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.

Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией. Полгода назад Гугл пригрозил компании Симантек, что перестанет доверять их сертификатам из-за того, что те выпустили аж 30,000 неисправных сертификатов.

Номенклатура сертификатов

Давайте рассмотрим, какие сертификаты X.509 встречаются в природе, если рассматривать их по расположению в пищевой цепочке доверия.

По степени крутизны дороговизны и надежности сертификаты делятся на 3 вида: DV, OV и EV.

Редко, кто на это готов раскошелиться. Навскидку Яндекс, StackOverflow.com и Хабр могут жить и без него. Но те, кто готов пойти ради этого на жертвы должны выполнить следующие требования:

По свои свойствам сертификаты бывают следующих типов.

В России понятие КС квалифицированного сертификата определено законодательно в связи с доступом к ГосУслугам. По ссыске Хабрапост с былиной об извлечении персональных данных из КС.

Откуда берутся сертификаты?

Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.

Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:

Следует серия вопросов, чтобы было чем запомнить поля owner и issuer

Конвертируем связку ключей из проприетарного формата в PKCS12.

Смотрим на результат:

LetsEncrypt

Сценарий №1 — найти следующего в связке

Так и есть, SKI сертификат DigiCert имеет то же значение.

Сценарий №2 — используй subjectAltnName, Люк

Откройте файл openssl.cnf и в секции req добавьте следующие линии.

Далее, в секции [ v3_ca ] укажите.

А дальше все как обычно, создаем закрытый ключ и подписываем сертификат.

Источник

Руководство. Общие сведения о сертификатах X.509 с открытым ключом

Сертификаты X.509 — это цифровые документы, которые представляют пользователя, компьютер, службу или устройство. Они могут выдаваться корневым или подчиненным центром сертификации (ЦС) либо центром регистрации и содержат открытый ключ субъекта сертификата. Они не содержат закрытый ключ субъекта, который должен храниться безопасно. Сертификаты с открытым ключом определяются в документе RFC 5280. Они имеют цифровую подпись и обычно содержат следующую информацию:

Поля сертификата

Со временем появились три версии сертификата. В каждой из версий добавлялись новые поля. Версия 3, которая действует в настоящий момент, содержит все поля версий 1 и 2, дополненные полями версии 3. Версия 1 определяет следующие поля:

В версии 2 добавлены следующие поля с информацией об издателе сертификата, хотя эти поля редко используются:

В сертификатах версии 3 добавлены следующие расширения:

Форматы сертификатов

Сертификаты можно сохранить в нескольких форматах. Для проверки подлинности в Центре Интернета вещей Azure обычно используются форматы PEM и PFX.

Двоичный сертификат

Содержит двоичный сертификат в необработанном формате в кодировке DER ASN.1.

Формат ASCII PEM

Ключ ASCII (PEM)

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

Сертификат PKCS#7

Этот формат предназначен для передачи подписанных или зашифрованных данных. Он определяется стандартом RFC 2315. В нем может содержаться полная цепочка сертификатов.

Ключ PKCS#8

Этот формат предназначен для хранения закрытого ключа и определен в стандарте RFC 5208.

Ключ и сертификат PKCS#12

Дополнительные сведения

Дополнительные сведения см. в следующих разделах:

Дальнейшие действия

Если вы хотите создать тестовые сертификаты, которые можно использовать для проверки подлинности устройств в Центре Интернета вещей, изучите следующие разделы:

Если у вас есть сертификат корневого или подчиненного центра сертификации (ЦС), который вы хотите отправить в центр Интернета вещей и подтвердить права владения, см. руководство Подтверждение принадлежности сертификата ЦС.

Источник