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

Разбираем 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 с открытым ключом

Сертификаты 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

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

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

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

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

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

Источник

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

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

Источник

Как конвертировать SSL-сертификат в нужный формат

Как конвертировать SSL-сертификат в нужный формат

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

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

Существует четыре основных формата сертификатов:

PEM — популярный формат используемый Центрами Сертификации для выписки SSL-сертификатов.

Сертификаты PEM подходят для установки на веб-серверы nginx, apache2.

DER — это бинарная форма сертификата PEM.

Сертификаты DER подходят для установки на серверы Java.

В файлах содержатся строки вида

Сертификаты P7B подходят для установки на серверы MS Windows, Java Tomcat

Сертификаты PFX подходят для установки на серверы Windows, в частности Internet Information Services(IIS).

Способы конвертации

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

Конвертация SSl сертификатов посредством OpenSSL

OpenSSL — это надежный, коммерческий и полнофункциональный инструментарий для протоколов Transport Layer Security (TLS) и Secure Sockets Layer (SSL). А также библиотека криптографии общего назначения. Конвертация с использованием библиотеки OpenSSL считается одним из самых безопасных способов: все данные будет сохранены непосредственно на устройстве, на котором будут выполняться операции по конвертированию.

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

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

Конвертировать PEM в DER можно посредством команды:

Аналогично, для других типов:

PEM в P7B

PEM в PFX

Обращаем ваше внимание, что после выполнения команды, будет запрошена установка пароля ключа.

DER в PEM

P7B в PEM

P7B в PFX

PFX в PEM

Конвертация при помощи онлайн-сервисов

Для конвертации сертификатов самый удобный способ — использование специальных сайтов, например, https://ssl4less.ru/ssl-tools/convert-certificate.html

Этот способ считается наименее безопасным методом: никогда не знаешь, сохраняет ли автор сайта ваш приватный ключ при конвертации.

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

Конвертация с PEM в DER

Конвертация с PEM в P7B

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

Что такое цепочка сертификатов и для чего она нужна, можно узнать в статье «Что такое корневой сертификат»

Конвертация с PEM в PFX

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

Конвертация из DER в PEM

Конвертация из P7B в PEM

Конвертация из P7B в PFX

Конвертация из PFX в PEM

Конвертация скриптом openssl-ToolKit

OpenSSL ToolKit — скрипт, который облегчает работу с библиотекой OpenSSL. Работа со скриптом является безопасным решением, т.к сертификаты и ключи сертификата никуда не передаются, а используются непосредственно на вашем сервере.

Для начала работы скрипт необходимо скачать и запустить. Сделать это можно одной командой:

После выполнения команды откроется следующее окно:

Нас интересует пункт 2. Convert certificates

После перехода в пункт 2. появится следующее меню, с выбором нужного типа конвертирования

После выбора преобразования, в данном случае PEM to FPX, скрипт предложит выбрать директорию с сертификатами на том устройстве, где запускается скрипт.

В нашем случае мы их скачали в директорию /home/ivan/crt/

После корректного ввода директории, скрипт отобразит все файлы в этой директории.

Далее нужно ввести имя сертификата, который будем конвертировать, в нашем случае это site.pem

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

Сделать это можно простой командой

Данное действие необходимо только для конвертации из PEM в PFX.

Мы рассмотрели пример конвертации PEM в PFX. Этим же путем можно конвертировать сертификаты в другие форматы. Единственное, что вам уже не понадобится шаг с объединением файлов.

Источник

Корневые и промежуточные сертификаты уполномоченных Удостоверяющих Центров России

Как и многие другие страны, Россия для официального электронного документооборота использует x509 сертификаты, выпускаемые уполномоченными Российскими Удостоверяющими Центрами (УЦ). И в отличие от многих других стран, использует свои собственные шифры.

Я давно хотел автоматизировать проверку подписей ответов органов власти (я много переписываюсь) и проверку «выгрузок» Роскомнадзора на подлинность (по роду общественной деятельности). Самой большой проблемой было достать промежуточные сертификаты из цепочки. Потому что существовал невнятный Excel-файл корневых УЦ на сайте Минсвязи и всё. А промежуточные надо было искать по сайтам соответствующих УЦ. Жизнь — боль.

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

Внезапно (я не знаю точно когда) и незаметно на сайте Госуслуг появилась вот такая ссылочка:
e-trust.gosuslugi.ru/CA

Я наскоро написал программку, которая превращает XML-файл со списком УЦ и сертификатами с этого сайта в привычный PEM формат.

Затем я автоматизировал её и получил постоянно поддерживаемый репозиторий сертификатов в привычном для *NIX мира виде.

Шифрование ГОСТ

Шифрование ГОСТ поддерживается в LibreSSL не помню с какой версии. Но в Alpine Linux от 3.5 уже поддерживается. С OpenSSL всё сложнее. Шифрование ГОСТ идёт с OpenSSL от версии 1.0.0 до версии 1.0.2 включительно. Но например в CentOS шифрования ГОСТ нет. Пользователи CentOS должны страдать. Для Debian, Mint, Ubuntu с OpenSSL версии 1.1.0 и выше требуется установка пакета libengine-gost-openssl1.1, поддерживаемого криптоэнтузиастом Вартаном Хачатуровым (кстати, можно ему помочь).

Ну и в 2018 году у нас есть Docker, а в Alpine Linux, как я уже упоминал, всё работает.

Как это использовать

Короткие примеры для проверки «выгрузки» Роскомнадзора с открепленной подписью. Файл «выгрузки» — dump.xml, открепленной подписи — dump.xml.sig. Даже я проверял их раньше только на целостность подписи, но не на соответствие источнику.

И с этого момента можно не пользоваться сайтом Госуслуг, Контура и странными программами вроде КриптоПро для простой задачи проверки подписи. А главное, что теперь можно и автоматизировать.

Источник