x 509 сертификат что это

Разбираем x.509 сертификат

Привет, %username%!

Так уж вышло, что несмотря на относительно неплохое понимание инфраструктуры открытых ключей, содержимое *.crt файлов всегда оставалось для меня полнейшей загадкой.
Нет, не поймите неправильно. Я знаю, что x.509 сертификат содержит информацию о владельце, открытый ключ, сведения об удостоверяющем центре и электронную цифровую подпись. Но при установке очередного сертификата меня всегда мучило любопытство.
Чем отличается идентификатор ключа от отпечатка? Какие данные сертификата подписываются, а какие нет? И что за структура данных позволяет хранить всю эту информацию, сводя избыточность к минимуму.
Но вот наконец-то любопытство перебороло лень и в данном посте я постараюсь описать структуру x.509 сертификатов и ответить на эти и другие вопросы.

Часть 1. Самоподписанный сертификат

В результате выполнения данной процедуры будет создан стандартный x.509 сертификат, который, будучи открытым с помощью hex-редактора, выглядит вот таким чудесным образом:

Тот же самый сертификат, но уже открытый с помощью стандартных средств windows:

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

Прежде всего, нужно отметить, что файл *.crt хранит информацию о сертификате в закодированном виде. Для кодирования применяется особый язык, называемый ASN.1.

ASN.1 — стандарт записи, описывающий структуры данных для представления, кодирования, передачи и декодирования данных. Wikipedia

Однако ASN.1 разрабатывался в те светлые времена, когда «640 КБ должно было хватать каждому» и тратить место на такую громоздкую запись не было никакой возможности. Поэтому, в целях экономии места, а также более удобной обработки хранимой в ASN.1-форме информации, был разработан специальный метод кодирования — DER.

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

К примеру, для кодировки целого числа INTEGER 65537 используется следующая форма: 02 03 01 00 01.
Здесь первый байт 02, определяет тип INTEGER (полную таблицу типов вы можете найти например тут), второй байт 03 показывает длину блока. А следующие за этим байты 01 00 01, являются шестнадцатеричной записью нашего числа 65537.

В нашем случае, для описание простейшего самоподписаного сертификата, достаточно 9 типов данных. Приведем таблицу кодирования для этих типов:

Зная как кодируется каждый из этих типов, мы можем попытаться распарсить наш *.crt файл.

30 82 01 8F 30 81 F9 A0 03 02 01 02 02 01 01 30
0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 0D
31 0B 30 09 06 03 55 04 03 0C 02 43 41 30 20 17
0D 31 33 30 39 31 35 31 35 33 35 30 32 5A 18 0F
32 31 31 33 30 39 32 32 31 35 33 35 30 32 5A 30
0D 31 0B 30 09 06 03 55 04 03 0C 02 43 41 30 81
9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00
03 81 8D 00 30 81 89 02 81 81 00 8D 80 B5 8E 80
8E 94 D1 04 03 6A 45 1A 54 5E 7E EE 6D 0C CB 0B
82 03 F1 7D C9 6F ED 52 02 B2 08 C3 48 D1 24 70
C3 50 C2 1C 40 BC B5 9D F8 E8 A8 41 16 7B 0B 34
1F 27 8D 32 2D 38 BA 18 A5 31 A9 E3 15 20 3D E4
0A DC D8 CD 42 B0 E3 66 53 85 21 7C 90 13 E9 F9
C9 26 5A F3 FF 8C A8 92 25 CD 23 08 69 F4 A2 F8
7B BF CD 45 E8 19 33 F1 AA E0 2B 92 31 22 34 60
27 2E D7 56 04 8B 1B 59 64 77 5F 02 03 01 00 01
30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03
81 81 00 0A 1C ED 77 F4 79 D5 EC 73 51 32 25 09
61 F7 00 C4 64 74 29 86 5B 67 F2 3D A9 39 34 6B
3C A9 92 B8 BF 07 13 0B A0 9B DF 41 E2 8A F6 D3
17 53 E1 BA 7F C0 D0 BC 10 B7 9B 63 4F 06 D0 7B
AC C6 FB CE 95 F7 8A 72 AA 10 EA B0 D1 6D 74 69
5E 20 68 5D 1A 66 28 C5 59 33 43 DB EE DA 00 80
99 5E DD 17 AC 43 36 1E D0 5B 06 0F 8C 6C 82 D3
BB 3E 2B A5 F1 94 FB 53 7B B0 54 22 6F F6 4C 18
1B 72 1C

Преобразуя байты-идентификаторы типов и убирая байты описывающие длину блоков получим следующую структуру:

Важным моментом, о котором стоит особенно упомянуть являются данные, для которых вычисляется подпись. Интуитивно может показаться, что подписываются все данные идущие до последнего поля BIT STRING, содержащего подпись. Но на самом деле это не так. В стандарте x.509 подписывается определенная часть сертификата, называемая TBS-сертификат (to be signed). В TSB-сертификат входит последовательность SEQUENCE второго уровня со всеми вложенными данными.

Т.о. если перед вами будет стоять задача проверить ЭЦП x.509 сертификата, то для этого сперва необходимо извлечь TBS-сертификат.

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

Часть 2. Сертификат 2-го уровня

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

Распарсив наш сертификат и преобразовав его к читаемому виду, получим следующую красоту:

Как видите, единственное отличие от самоподписанного сертификата заключается в наличие дополнительного блока:

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

Заключение

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

Источник

Шпоры по сертификатам 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 ] укажите.

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

Источник

Зачем нужны сертификаты¶

Итак, сертификат (certificate) — это файл, содержащий информацию о персоне или организации и подписанный цифровой подписью, нечто вроде паспорта персоны или организации. Главное содержимое сертификата — это публичный ключ шифрования. У любого сертификата существует его автор-создатель и у этого автора есть секретный ключ шифрования. По сути сертификат — это всего лишь обёртка над публичным ключом, где помимо собственно ключа содержится разнообразная дополнительная информация: имя персоны или организации, страна, телефон, емейл и так далее.

Секретный и публичный ключи используются для асиметричной схемы шифрования: данные шифруются секретным ключом, а расшифровываются публичным. Или наоборот: шифруются публичным, а расшифровываются секретным. За подробностями традиционно отправляю в википедию, в статью Криптосистема с открытым ключом.

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

Но тут возникает вопрос: а где гарантия, что этот сертификат (и соответственно публичный ключ) настоящий, что он действительно создан автором сайта, а не вклинившимся в сеть злоумышленником? Как проверить подлинность этого «удостоверения сайта»?

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

Если для SSH схема с заранее сохранённым сертификатом более-менее работает, то для HTTPS в браузере она уже не годится, абсолютно невозможно получить сертификаты для всех сайтов в интернете. Поэтому в HTTPS используется другая схема, называемая инфраструктурой публичных ключей или по-английски Public Key Infrastructure, сокращённо PKI.

Суть PKI очень простая: в браузере хранятся не сертификаты браузеров, а сертификаты так называемых удостоверяющих центров (по-английски Certificate Authority, сокращённо CA). Предназначение CA — это подписывание всех остальных сертификатов, это означает, что когда ваш браузер получает сертификат сайта при установке соединения, он видит помимо адреса сайта ещё и «адрес» удостоверяющего центра, а также цифровую подпись, которую сгенерировал удостоверяющий центр с использованием своего секретного ключа. Дальше браузер берёт из локального хранилища сертификат удостоверяющего центра, достаёт из него публичный ключ и с помощью него проверяет подпись в сертификате сайта. Если подпись правильная, соединение успешно устанавливается.

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

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

Технические подробности¶

А теперь самое главное, ради чего эта статья и писалась — технические подробности, стандарты и особенности реализации системы сертификатов.

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

Секретный ключ¶

Главный компонент всего — криптография, точнее криптографические алгоритмы.

Всё начинается с генерации пары ключей: секретного и публичного. Сначала при помощи математической и компьютерной магии генерируется секретный ключ, а затем из него вычисляется публичный. Чаще всего для сертификатов используется алгоритм RSA, вот как это делается в консоли через программу openssl:

С подобным форматом представления криптографических данных вам предстоит сталкиваться постоянно, называется он PEM, что расшифровывается как Privacy-enhanced Electronic Mail. Его предназначение — кодировать бинарные криптографические данные в виде ASCII-текста. И фактически между маркерами из минусов находятся закодированные в base64 бинарные данные, в данном случае — секретный ключ.

Мы можем при помощи openssl сконвертировать секретный ключ из текстового формата PEM в изначальный бинарный, сохраним его в файл private.der:

Имя формата данных DER расшифровывается как Distinguished Encoding Rules и является частью стандарта ASN.1. В стандарте ASN.1 описываются правила и структуры для кодирования, раскодирования и передачи данных по телекоммуникационным и компьютерным сетям. По сути можно считать ASN.1 форматом для сериализации структурированных бинарных данных. Существует специальный компилятор, который из формальных спецификаций ASN.1 генерирует C-код для работы с бинарными данными такой структуры.

Вот так, например, выглядит дамп нашего созданного секретного ключа:

В нашем файле секретного ключа «упакованы» девять целых чисел, структура ключа для алгоритма RSA весьма простая и описана, например, в RFC 3447, в секции A.1.2 RSA private key syntax.

Ну и чтобы два раза не вставать, вытащим из секретного ключа публичный ключ в файл public.der, закодированный в бинарный формат DER, openssl умеет делать и это тоже:

И сразу же посмотрим на его структуру через dumpasn1:

Структура публичного ключа также описана в RFC3447, в секции A.1.1, если вы туда посмотрите, то увидите, что дамп файла public.der не соответствует этому описанию. Поздравляю с первыми граблями в openssl, с ними вам тоже придётся сталкиваться постоянно. В данном случае зачем-то добавляется заголовок, указывающий, что дальше будет RSA, и на этом заголовке многим библиотекам срывает крышу.

Для манипуляциями публичными и секретными ключами можно также использовать команду pkey, она позволяет работать с произвольными поддерживаемыми типами ключей. Вот как выглядит её вызов для вытаскивания публичного ключа из приватного:

Сертификат¶

Но хватит о ключах, поговорим теперь о сертификатах. Напомню, что сертификат — это обёртка над публичным ключом. Неформально файл сертификата состоит из двух частей: данных сертификата (DATA) и цифровой подписи (SIGNATURE).

В секции DATA содержится смысловая часть сертификата, главное поле там — Subject (он же Субъект), это владелец сертификата, именно его публичный ключ находится в поле Subject Public Key Info. Также в сертификат входят другие поля, о которых мы поговорим позже, когда будем рассматривать уточнённую схему.

В секции SIGNATURE содержится цифровая подпись всех данных из секции DATA. Напомню, что в модели PKI цифровую подпись генерирует центр авторизации, используя свой секретный ключ, удостоверяя подлинность данных сертификата.

Естественно, вся работа с сертификатами регламентируется международными стандартами, конкретно для наших сертификатов используется стандарт X.509, вот его официальный сайт: http://www.itu.int/rec/T-REC-X.509. X.509 описывает множество аспектов PKI, не только форматы данных, но ещё и алгоритмы.

Для описания структур данных используется уже знакомая нам нотация ASN.1, она достаточно простая и выразительная.

Вот так определяется сертификат (раздел 4.1. Basic Certificate Fields):

Это всё значит, что сертификат состоит из трёх компонентов: tbsCertificate, signatureAlgorithm и signatureValue

tbsCertificate собственно тело сертификата, его данные, буквы tbs в названии поля расшифровываются как «to be signed», то есть это блок данных, который будет подписан, описывается ASN.1 стуктурой TBSCertificate ; signatureAlgorithm в этом поле задаётся алгоритм подписи, определяется ASN.1 структурой AlgorithmIdentifier ; signatureValue а в этом поле находится бинарный неструктурированный блок с собственно подписью.

Перед тем как погружаться в структуру тела сертификата, рассмотрим поле signatureAlgorithm, в его описании фигурирует очень важный для дальнейшего понимания элемент, но сначала формальное ASN.1-описание (раздел 4.1.1.2. signatureAlgorithm):

Как и другие порождения ASN.1/X.509, OID имеет чётко заданную структуру, по которой можно однозначно идентифицировать тип и свойства объекта. Существуют разные способы представления OID. Рассмотрим их на простом примере. Для генерации цифровой подписи может использоваться алгоритм, который неформально можно описать так: посчитаем SHA256 тела сертификата и дальше зашифруем это значение приватным ключом центра авторизации. Для этого алгоритма существует OID, у этого OID есть несколько равнозначных способов представления:

Все эти способы отражают иерархичную сущность OID, по компонентам можно определить, например, кто внёс этот OID в реестр, какая страна, какая организация и так далее. Существует специальный сайт — http://www.oid-info.com, — на котором ведётся большой реестр всевозможных OID. В принципе, таких сайтов несколько, но этот самый популярный. Вот, например, страница OID для алгоритма sha256WithRSAEncryption: http://www.oid-info.com/get/1.2.840.113549.1.1.11.

Я не буду полностью описывать семантику этих полей, это всё приводится с подробностями в разделе 4.1. Basic Certificate Fields RFC 5280. Так, коротко пробежимся по основным полям.

В поле signature должно быть то же самое значение, что и в поле signatureAlgorithm, то есть алгоритм, которым CA подписывает сертификат.

В поле issuer находится имя центра авторизации, в поле subject — имя владельца сертификата. Оба этих имени также являются структурированными (ASN.1-структура Name) и должны быть непустыми, их тип определяется стандартом X.501 и носит название distinguished name, сокращённо DN. Это тот же самый DN, что и в LDAP.

Поля в структуре Name также задаются через OID. Вот небольшой пример, как поле issue «разворачивается» из текстового представления в строго формализованное. Возьмём DN-фрагмент реального сертификата (https://google.ru):

Небольшой хинт, как скачать сертификат с сайта и сразу конвертнуть его в DER в файл certificate.der:

А вот, в какую ASN.1-структуру «разворачивается» этот текст:

По факту это последовательность пар ключ-значение, где в роли ключа выступает OID. То есть кажущаяся обычным текстом строка оказывается одной из форм представления строго структурированного объекта. Каждая такая пара ключ-значение называется RelativeDistinguishedName, в роли ключа выступает OID.

Для дальнейшего изучения темы нам понадобится настоящий живой сертификат. Я взял сертификат c twitter.com, вы его можете скачать сами (если знаете, как это сделать вашим браузером) или взять сохранённую мной версию в виде DER-файла (скачать сохранённую версию).

Итак, сначала посмотрим, как сертификат выглядит в «человечном» формате, вот его полная распечатка (немного отформатированная, чтобы длинная строка не распирала экран):

Разберём последовательно поля сертификата.

Дальше я рекомендую выполнить команду dumpasn1 certificate-twitter.com.der и сравнить только что прочитанное с показанным в дампе, параллельно полезно держать открытыми RFC 5280 и RF 3280.

Цепочки удостоверяющих сертификатов¶

Удостоверяющий центр может выдать сертификат, в котором в поле X509v3 Basic Constraints разрешается его использование как удостоверяющего. Этим сертификатом тоже можно подписывать «доменные» сертификаты. Таким образом, все CA-сертификаты образуют цепочку, а в целом — дерево. В вершине этого дерева находится Самый Главный Сертификат, он называется корневым сертификатом (по-английски root certificate).

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

Естественно, центры авторизации не выписывают CA-сертификаты кому попало, но крупная организация может этого добиться, например, у Google есть свой CA-сертификат.

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

Корневой сертификат является самоподписанным, то есть он подписан тем же самым ключом, публичный ключ для которого находится в теле сертификата. У корневого сертификата совпадают поля issuer и subject.

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

Как вручную проверить цепочку сертификатов¶

Иногда возникает необходимость проверить, подписан ли один сертификат другим. Это можно сделать через openssl.

Возьмём три сертификата из Go Daddy, вот они: GD_root.pem (это корневой сертификат Go Daddy), GD_good.pem, GD_bad.pem. Нам нужно проверить, подписаны ли сертификаты GD_good.pem и GD_bad.pem корневым сертификатом Go Daddy.

И альтернативный вариант (предыдущий в новых версиях не работает):

И ещё о сертификатах¶

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

Вот как выглядит попытка распечатать его как текст:

Обратите внимание на поле Signature Algorithm: 1.3.6.1.4.1.6801.1.2.2, openssl не смог распознать этот алгоритм, так как в его коде нет такого OID. Если мы попытаемся найти этот OID в репозитории http://www.oid-info.com/get/1.3.6.1.4.1.6801.1.2.2, то обнаружим, что им он неизвестен. Но зато им известен «родительский» OID (помним, что схема OID иерархичная), по адресу http://www.oid-info.com/get/1.3.6.1.4.1.6801 находим координаты владельца этой схемы — казахстанская фирма Gamma Technologies, OID предыдущего уровня (1.3.6.1.4.1.6801.1.2) выдаёт нам GOST28147, https://ru.wikipedia.org/wiki/ГОСТ_28147-89.

Как мы видим, фирма использует X.509 для хранения своих собственных сертификатов. Браузер его не сможет переварить, а вот специализированный софт — вполне. Например, dumpasn1 отлично показывает структуру ASN.1-объектов.

Следующий файл для препарирования — сертификат удостоверяющего центра Бурятии, скачайте файл ca-bur.der. Предлагаю вам самим его скачать и запустить команду:

А затем такую, для контраста:

Комментарии

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

Вот простой пример, сертификаты для него тут:

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

-CApath /dev/null указываю для гарантии, что не будет использоваться системное хранилище сертификатов.

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

Это всё инфраструктурные вопросы, они вне области собственно сертификатов лежат.

Сама суть инфраструктуры публичных ключей (PKI) предполагает, что корневой сертификат попадает на машину клиента другим путём, не через сетевой коннект, поэтому нормального способа «запомнить» или «автоматически скачать» нет.

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

«Понятное имя» в сертификате прописать нельзя.

Теоретически самоподписанный сертификат установить можно, но почти все программы его будут игнорировать.

Это не опечатка, просто эта опция есть не во всех версиях openssl. Спасибо за напоминание, обновлю текст.

Источник