Цифровой сертификат: для чего нужен, где и как его получить

Содержание

Что такое ssl-сертификат?
Ev сертификаты
Ov сертификаты
Другие сервисы
Зачем нужны сертификаты¶
Защита клиентов и бизнеса
И ещё о сертификатах¶
Инфраструктура с открытыми ключами
Как вручную проверить цепочку сертификатов¶
Как получить цифровой сертификат?
Какими бывают ssl-сертификаты
Каталог.
Классификация сертификатов
Корректировка ключей и управление историями ключей
Номенклатура сертификатов
Нотариальная аутентификация.
Откуда берутся сертификаты?
Примечания
Принцип работы ssl
Принцип работы[]
Публикация сертификата.
Регистрация.
Российские стандарты[]
Сервисы управления сертификатами
Сертификат атрибутов
Сертификат¶
Словарный запас
Структура сертификата[]
Сценарий №1 — найти следующего в связке
Терминология
Технические подробности¶
Хранение информации в архиве.
Часть 1. самоподписанный сертификат
Часть 2. сертификат 2-го уровня
Заключение

Что такое ssl-сертификат?

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

Ev сертификаты

Extended validation – сертификаты с расширенной проверкой – используются для более тщательной проверки компании и ее полномочий. Наиболее престижная разновидность, вызывающая больше доверия у пользователей. Сертификаты OV и EV, к примеру, продаются DigiCert – одним из ведущих удостоверяющих центров.

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

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

Выделяют сертификаты для одного, нескольких и всех поддоменов конкретного домена, сертификаты открытого ключа и прочие.

Ov сертификаты

Сертификаты следующего уровня – Organization validation. Используются организациями и проверяют связь между именем домена, его владельцем и компанией, использующей сертификат. Он подтверждает не только имя домена, но и его принадлежность существующей организации.

Другие сервисы

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

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

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

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

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

Защита клиентов и бизнеса

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

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

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

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

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

Инфраструктура с открытыми ключами

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

Эффективная PKI должна включать следующие элементы:

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

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

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

Для верификации используем команду openssl verify, в ней мы должны указать файл с «доверенными» сертификатами, в нашем случае это один сертификат GD_root.pem, указывается через аргумент -CAfile GD_root.pem. Также мы указываем заведомо несуществующий путь к главному хранилищу сертификатов удостоверяющих центров, чтобы в процессе верификации участвовал только один сертификат, это делается через аргумент -CApath /nope. В новых версиях openssl (начиная с 1.1.0) введён специальный новый параметр -no-CApath.

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

Как получить цифровой сертификат?

Распространением SSL-сертификатов занимаются не специализированные центры, а их партнеры. На территории России сертификаты наиболее известных удостоверяющих центров реализуются множеством компанией; их корневые сертификаты предустановлены практически во все браузеры.

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

Не все сертификаты предоставляются на платной основе. Длительность использования бесплатного сертификата не превышает одного года.

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

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

Какими бывают ssl-сертификаты

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

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

Каталог.

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

Поддержка невозможности отказа от цифровых подписей

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

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

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

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

Классификация сертификатов

VeriSign предложила следующую концепцию классификации цифровых сертификатов :

Корректировка ключей и управление историями ключей

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

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

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

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

~~пищевой~~

цепочке доверия.

По степени

~~крутизны~~

дороговизны и надежности сертификаты делятся на 3 вида:

DVOVEV

Нотариальная аутентификация.

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

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

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

Создать свой собственный сертификат и самому же его подписать. Плюсы — это бесплатно, минусы — сертификат будет принят лишь вами и, в лучшем случае, вашей организацией.
Приобрести сертификат в УЦ. Это будет стоить денег в зависимости от различных его характеристик и возможностей, указанных выше.
Получить бесплатный сертификат LetsEncrypt, доступны только самые простые DV сертификаты.

Про сертификаты: Инструктор-тренер CMAS/КПДР RUS/F00/I3/12/000039 Валерий Мухин - Обучение. Техника безопасности. Обмен опытом. - Люди Воды

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

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem

Далее, создает CSR — запрос на подписание сертификата.

openssl req -new -sha256 -key private.key -out server.csr -days 730

И подписываем.

openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crt

Результат можно посмотреть командой:

openssl x509 -text -noout -in public.crt

Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:

openssl -help
openssl x509 -help
openssl s_client -help

Ровно то же самое можно сделать с помощью java утилиты keytool.

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

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

What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct?

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

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12

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

keytool -list -v -alias selfsigned -storepass password -keystore keystore.jks

Alias name: selfsigned
Creation date: 20.01.2021
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Issuer: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Serial number: 1f170cb9
Valid from: Sat Jan 20 18:33:42 MSK 2021 until: Tue Jan 15 18:33:42 MSK 2021
Certificate fingerprints:
     MD5:  B3:E9:92:87:13:71:2D:36:60:AD:B5:1F:24:16:51:05
     SHA1: 26:08:39:19:31:53:C5:43:1E:ED:2E:78:36:43:54:9B:EA:D4:EF:9A
     SHA256: FD:42:C9:6D:F6:2A:F1:A3:BC:24:EA:34:DC:12:02:69:86:39:F1:FC:1B:64:07:FD:E1:02:57:64:D1:55:02:3D

Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 30 95 58 E3 9E 76 1D FB   92 44 9D 95 47 94 E4 97  0.X..v...D..G...
0010: C8 1E F1 92                                        ....
]
]

Значению ObjectId: 2.5.29.14 соответствует определение ASN.1, согласно RFC 3280 оно всегда non-critical. Точно так же можно узнать смысл и возможные значения других ObjectId, которые присутствуют в сертификате X.509.

subjectKeyIdentifier EXTENSION ::= {
    SYNTAX SubjectKeyIdentifier
    IDENTIFIED BY id-ce-subjectKeyIdentifier
}

SubjectKeyIdentifier ::= KeyIdentifier

Примечания

Как только страница обновилась в Википедии она обновляется в Вики 2.Обычно почти сразу, изредка в течении часа.

Принцип работы ssl

Переданная в защитном виде информация расшифровывается только при помощи специального ключа сертификата цифровой подписи. Такой подход гарантирует сохранность данных. Защита информации посетителей веб-ресурса, даже если она не важна, обеспечивается SSL-сертификатом. Если сайт не защищен, то клиенты могут его покинуть. Наличие сертификата отображается в строке браузера иконкой замка.

Схема действия цифрового сертификата:

Пользователь заходит на защищенный ресурс.
Проверяется DNS и определяется IP-адрес хостинга сайта.
Отыскивается конкретная запись веб-ресурса, осуществляется переход на сервер хоста.
Запрашивается с хоста сайта безопасное SSL-соединение.
В ответ хост направляет валидный SSL-сертификат.
Устанавливается защитное соединение, шифруются все передаваемые данные.

Принцип работы[]

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

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

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

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

Публикация сертификата.

Выпущенный однократно сертификат включается в каталог (в соответствии со спецификациями стандарта X.500 или иными требованиями), чтобы третьи стороны могли иметь к нему доступ. В одних случаях каталог контролируется доверенным центром, в других — третьей стороной.

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

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

Выработка политики ДЦ.

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

Вспомогательные сервисы

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

Регистрация.

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

Российские стандарты[]

В России действуют свои криптографические стандарты. Использование их совместно с сертификатами описано в RFC4491: Using GOST with PKIX.

ar:شهادات رقميةca:Certificat digitalcs:

Digitální certifikátde:Digitales Zertifikatel:

Ψηφιακό πιστοποιητικόen:Public key certificatees:Certificado digitalfa:گواهی دیجیتالfr:Certificat électroniqueit:

Certificato digitaleja:公開鍵証明書nl:Certificaat (PKI)pl:

Certyfikatpt:Certificado digitaluk:

Цифровий сертифікатvi:Chứng thực khóa công khaizh:電子證書

Сервисы управления сертификатами

Сервисы управления сертификатами — это сервисы, образующие ядро инфраструктуры с открытыми ключами. К ним относятся:

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

Аналогично аннулированию осуществляется приостановление действия сертификата. Оно заключается в однократной отмене сертификата на определенный период времени в течение срока его действия. После этого действие сертификата возобновляется автоматически или же сертификат аннулируется.

Сертификат атрибутов

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

Сертификат¶

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

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

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

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

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

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3

Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1SEQUENCE обозначает примерно то же самое, что и 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 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией.

Структура сертификата[]

Перечень обязательных и необязательных полей, которые могут присутствовать в сертификате, определяется стандартом на его формат (например, X.509). Как правило, сертификат включает в себя следующие поля:

Про сертификаты: Сертификаты на товары

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

Связка сертификатов — Объединение нескольких X.509 сертификатов в один файл, чаще всего в формате PEM. Связка передается по сети в момент протокола рукопожатия SSL/TLS.

Самый сок начинается, когда имеете дело со связкой сертификатов, a. k. a certificate chain. Часто просматривая лапшу в связке ключей jks непросто понять как найти родительский сертификат, когда там россыпь новых и старых сертификатов на несколько доменных имен.

Терминология

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

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

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

Список аннулированных сертификатов (САС — список недействительных сертификатов, в большинстве случаев генерируется доверенным центром.

Подписчик (абонент) сертификата — лицо, которое получает сертификат, выпущенный доверенным центром.

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

Пользователь сертификата — лицо, которое использует сертификат, например, подписчик сертификата или доверенная сторона.

Сертификация — это процесс генерации сертификатов для физических и юридических лиц, оборудования и т.д.

Доверенный центр (ДЦ) — доверенное лицо (физическое или юридическое), которое выпускает, публикует, аннулирует сертификаты, приостанавливает их действие.

Правила организации сертификации — документ, который устанавливает процедуры сертификации в соответствии с политикой конкретного ДЦ. Правила организации сертификации раскрываются всем лицам, внешним по отношению к ДЦ, в том числе пользователям.

Взаимная (перекрестная) сертификация — двусторонний процесс сертификации двух доверенных центров.

Регистрационный центр (РЦ) — лицо (физическое или юридическое), которое с санкции ДЦ выполняет функции аутентификации в процессе выпуска или аннулирования сертификата. Регистрационный центр не выпускает сертификаты и не ведет списки аннулированных сертификатов.

Доверяющая сторона — лицо, которое получает сертификат и полагается на него при совершении сделок или обмене сообщениями. Доверяющей стороной может быть не только подписчик.

Архив — система хранения сертификатов и списков аннулированных сертификатов.

Иерархия доверия — система проверки цифровых сертификатов. Каждый сертификат связан с сертификатом подписи того субъекта, который снабдил его цифровой подписью. Так, сертификат абонента связан с сертификатом ДЦ низшего уровня, который, в свою очередь, связан с сертификатом ДЦ более высокого уровня и так далее до ДЦ высшего уровня. Следуя по цепочке доверия до известной доверенной стороны, можно убедиться в действительности сертификата.

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

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

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

Хранение информации в архиве.

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

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

Для начала рассмотрим вариант самоподписанного сертификата корневого уровня.

Для упрощения задачи сгенерируем сертификат, который будет содержать только необходимые параметры:

Сделать это можно с помощью библиотеки Bouncy Castle, следующим образом:

private void button1_Click(object sender, EventArgs e)
        {            

            var KeyGenerate = new RsaKeyPairGenerator();

            KeyGenerate.Init(new KeyGenerationParameters(new SecureRandom(new CryptoApiRandomGenerator()), 1024));

            AsymmetricCipherKeyPair kp = KeyGenerate.GenerateKeyPair();

            var gen = new X509V3CertificateGenerator();

            var certName = new X509Name("CN=CA");
            var serialNo = new BigInteger("1",10);            

            gen.SetSerialNumber(serialNo);
            gen.SetSubjectDN(certName);            
            gen.SetIssuerDN(certName);
            gen.SetNotAfter(DateTime.Now.AddYears(100));
            gen.SetNotBefore(DateTime.Now);
            gen.SetSignatureAlgorithm("SHA1WITHRSA");            
            gen.SetPublicKey(kp.Public);     
            var myCert = gen.Generate(kp.Private);
            byte[] result = DotNetUtilities.ToX509Certificate(myCert).Export(X509ContentType.Cert);

            FileStream fs = new FileStream("D:\test1.crt", FileMode.CreateNew);
            fs.Write(result, 0, result.Length);
            fs.Flush();
            fs.Close();
        }

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

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

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

Имя сертификата	CA
Издатель	CA
Версия сертификата	3
Серийный номер	0x1
Недействителен до...	15.09.2021 15:35:00 GMT
Недействителен после...	22.09.2113 15:35:00 GMT
Цифровая подпись (SHA-1)	F9 AD 58 B5 50 3D F6 36 5E B8 89 D4 DC C8 5F CC 25 4B 93 A2
Цифровая подпись (SHA-256)	42 02 24 20 4E 8F 3A 3E 31 38 88 E5 C5 E7 C3 03 14 3A A6 52 EA 78 B9 77 42 5B 99 EB 4B BA 23 82
Открытый ключ(1024 битный)		Алгоритм открытого ключа	rsaEncryption
Модуль	
00: 8D 80 B5 8E 80 8E 94 D1 04 03 6A 45 1A 54 5E 7E
10: EE 6D 0C CB 0B 82 03 F1 7D C9 6F ED 52 02 B2 08
20: C3 48 D1 24 70 C3 50 C2 1C 40 BC B5 9D F8 E8 A8
30: 41 16 7B 0B 34 1F 27 8D 32 2D 38 BA 18 A5 31 A9
40: E3 15 20 3D E4 0A DC D8 CD 42 B0 E3 66 53 85 21
50: 7C 90 13 E9 F9 C9 26 5A F3 FF 8C A8 92 25 CD 23
60: 08 69 F4 A2 F8 7B BF CD 45 E8 19 33 F1 AA E0 2B
70: 92 31 22 34 60 27 2E D7 56 04 8B 1B 59 64 77 5F
Экспонента	01 00 01                                       

Подпись		Алгоритм подписи	sha1WithRSAEncryption
Подпись	
00: 0A 1C ED 77 F4 79 D5 EC 73 51 32 25 09 61 F7 00
10: C4 64 74 29 86 5B 67 F2 3D A9 39 34 6B 3C A9 92
20: B8 BF 07 13 0B A0 9B DF 41 E2 8A F6 D3 17 53 E1
30: BA 7F C0 D0 BC 10 B7 9B 63 4F 06 D0 7B AC C6 FB
40: CE 95 F7 8A 72 AA 10 EA B0 D1 6D 74 69 5E 20 68
50: 5D 1A 66 28 C5 59 33 43 DB EE DA 00 80 99 5E DD
60: 17 AC 43 36 1E D0 5B 06 0F 8C 6C 82 D3 BB 3E 2B
70: A5 F1 94 FB 53 7B B0 54 22 6F F6 4C 18 1B 72 1C

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

Про сертификаты: Муниципальное автономное учреждение «Информационно-методический центр» | Сертификаты доп.образования

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

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

С помощью языка ASN.1 можно описывать сложные структуры, состоящие из данных различных типов. Типичный пример ASN.1-файла выглядит как-то так:

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

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

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

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

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

3082 01 8F3081 F9A0030201 02 0201 01 30
0D0609 2A 86 48 86 F7 0D 01 01 05 0500300D
310B30090603 55 04 03 0C02 43 41 302017
0D 31 33 30 39 31 35 31 35 33 35 30 32 5A 180F
32 31 31 33 30 39 32 32 31 35 33 35 30 32 5A 30
0D310B30090603 55 04 03 0C02 43 41 3081
9F 300D0609 2A 86 48 86 F7 0D 01 01 01 0500
0381 8D 00 3081 890281 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 0203 01 00 01
300D0609 2A 86 48 86 F7 0D 01 01 05 050003
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

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

SEQUENCE(3 elem)
	SEQUENCE(7 elem)
		[0](1 elem)
			INTEGER 2
		INTEGER 1
		SEQUENCE(2 elem)
			OBJECT IDENTIFIER 1.2.840.113549.1.1.5
			NULL
		SEQUENCE(1 elem)
			SET(1 elem)
				SEQUENCE(2 elem)
					OBJECT IDENTIFIER 2.5.4.3
					UTF8String CA
		SEQUENCE(2 elem)
			UTCTime 13-09-15 15:35:02 UTC
			GeneralizedTime 2113-09-22 15:35:02 UTC
		SEQUENCE(1 elem)
			SET(1 elem)
				SEQUENCE(2 elem)
					OBJECT IDENTIFIER 2.5.4.3
					UTF8String CA
		SEQUENCE(2 elem)
			SEQUENCE(2 elem)
				OBJECT IDENTIFIER 1.2.840.113549.1.1.1
				NULL
			BIT STRING(1 elem)
				SEQUENCE(2 elem)
					INTEGER 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
					INTEGER 65537
		SEQUENCE(2 elem)
			OBJECT IDENTIFIER 1.2.840.113549.1.1.5
			NULL
	BIT STRING 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

Это уже более похоже на то, что мы видим при открытии сертификатов в браузере или Windows. Пробежимся по каждому элементу:

Важным моментом, о котором стоит особенно упомянуть являются данные, для которых вычисляется подпись. Интуитивно может показаться, что подписываются все данные идущие до последнего поля BIT STRING, содержащего подпись. Но на самом деле это не так. В стандарте x.

	SEQUENCE(7 elem)
		[0](1 elem)
			INTEGER 2
		INTEGER 1
		SEQUENCE(2 elem)
			OBJECT IDENTIFIER 1.2.840.113549.1.1.5
			NULL
		SEQUENCE(1 elem)
			SET(1 elem)
				SEQUENCE(2 elem)
					OBJECT IDENTIFIER 2.5.4.3
					UTF8String CA
		SEQUENCE(2 elem)
			UTCTime 13-09-15 15:35:02 UTC
			GeneralizedTime 2113-09-22 15:35:02 UTC
		SEQUENCE(1 elem)
			SET(1 elem)
				SEQUENCE(2 elem)
					OBJECT IDENTIFIER 2.5.4.3
					UTF8String CA
		SEQUENCE(2 elem)
			SEQUENCE(2 elem)
				OBJECT IDENTIFIER 1.2.840.113549.1.1.1
				NULL
			BIT STRING(1 elem)
				SEQUENCE(2 elem)
					INTEGER 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
					INTEGER 65537

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

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

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

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

Заключение

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

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

RFC5280 — спецификация x.509 сертификата и списка отзывов сертификатов.
Руководство по выживанию — SSL/TLS и сертификаты X.509
ASN.1 простыми словами, вариант статьи для хабра
on-line утилита для декодирования DER-файлов
Первичный стандарт ITU-T X.509 ( русский перевод). Спасибо ystr за ссылку.