Кстати что общего между 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 ] укажите.
А дальше все как обычно, создаем закрытый ключ и подписываем сертификат.
Общее имя (ОИ (CN)) для сертификата с поддержкой субдоменов
SSL-сертификат с поддержкой субдоменов рассматривается как вариант, если требуется защита нескольких субдоменов в рамках одного и того же доменного имени. Эти сертификаты, используя знак подстановки (*) в поле доменного имени, защищают многочисленные субдомены (хосты), связанные с одним и тем же базовым доменом.
Общее имя для сертификатов с поддержкой субдоменов всегда начинается со звездочки и точки (*.).
Например, стандартный выпущенный сертификат с поддержкой субдоменов для *.domain.com будет защищать www.domain.com, mail.domain.com, info.domain.com и т.д., но не будет защищать mail.test.com.
Альтернативные имена субъектов (SAN) должны быть доменом с поддержкой субдоменов (например, *.yourdomain.com) или основаны на указанных вами в списке доменах с поддержкой субдоменов. Например, если один из ваших доменов с подстановочным знаком – это *.example.com, вы можете использовать www.example.com или www.app.example.com, но не можете использовать mail.secure.com. Исключение для сертификата Secure Site Pro SSL, который защищает оба домена.
По умолчанию запрашиваемый сертификат предполагается установить во всех соответствующих доменах. Тем не менее, для каждого веб-сервера, поддерживаемого DigiCert, существуют некоторые правила, которые требуют, чтобы сертификат был установлен только на квалифицированных доменах.
При поступлении запроса на автоматизацию сервер находит соответствующие блоки сервера на основе CN или SAN, используемых в запросе.
Nginx сравнивает server_name с CN или SAN, указанными в запросе.
Если будет найдено совпадение server_name в наборе серверных блоков, все совпадающие серверные блоки будут защищены.
В приведенном выше примере, когда вы запрашиваете автоматизацию для:
При поступлении запроса на автоматизацию сервер находит соответствующие блоки на основе CN или SAN, используемых в запросе.
Apache сравнивает ServerName и ServerAlias с CN или SAN, указанными в запросе.
Если будут найдены соответствующие ServerName или ServerAlias в наборе виртуальных хостов, все совпадающие блоки виртуальных хостов будут защищены.
В приведенном выше примере, когда вы запрашиваете автоматизацию для:
Сервер IIS не ищет соответствующие CN или SAN, используемые в запросе на автоматизацию. Сертификат будет установлен только по запрошенному IP-адресу и порту.
В приведенном выше примере, когда вы запрашиваете автоматизацию для:
При поступлении запроса на автоматизацию сервер находит соответствующие блоки на основе CN и (или) SAN, используемых в запросе.
Tomcat сравнивает SSLHostConfig hostNameс CN и (или) SAN, указанными в запросе.
Если будет найден соответствующий SSLHostConfig Hostname в наборе блоков коннекторов, все совпадающие блоки будут защищены.
В приведенном выше примере, когда вы запрашиваете автоматизацию для:
Для успешной автоматизации все блоки SSLHostConfig в составе коннектора должны иметь установленный сертификат.
Например, для успешной автоматизации и установки сертификатов на все блоки SSLHostConfig, необходимо разместить запрос на автоматизацию с:
CN=*.example.com и SAN=*.mail.test.com
При поступлении запроса на автоматизацию сервер находит соответствующие блоки на основе CN или SAN, используемых в запросе.
IBM-сервер сравнивает ServerName и ServerAlias с CN или SAN, указанными в запросе.
Если будут найдены соответствующие ServerName или ServerAlias в наборе виртуальных хостов, все совпадающие блоки виртуальных хостов будут защищены.
В приведенном выше примере, когда вы запрашиваете автоматизацию для:
О проекте
DigiCert is the world’s leading provider of scalable TLS/SSL, IoT and PKI solutions for identity and encryption. The most innovative companies, including 89% of the Fortune 500 and 97 of the 100 top global banks, choose DigiCert for its expertise in identity and encryption for web servers and Internet of Things devices. DigiCert supports TLS and other digital certificates for PKI deployments at any scale through its certificate lifecycle management solution, CertCentral®. The company is recognized for its enterprise-grade certificate management platform, fast and knowledgeable customer support, and market-leading security solutions. For the latest DigiCert news and updates, visit digicert.com or follow @digicert.
Этот сайт используйте файлы «cookie» и другие технологии отслеживания для облегчения навигации и предоставления вам возможности оставлять отзывы, для анализа использования вами наших продуктов и сервисов, помощи в наших действиях по продвижению и рекламированию и предоставления содержания третьих сторон. Прочитайте нашу Политика в отношении файлов «cookie» и Политику конфиденциальности для получения более подробной информации.
Если для создания запроса сертификата от стороннего центра сертификации или другого центра сертификации инфраструктуры открытых ключей используется командлет New-ExchangeCertificate, убедитесь, что выполнена проверка полей сертификата и формата сертификата, которые запрашиваются центром сертификации.
В этом разделе описываются наиболее важные поля сертификатов и предоставляются некоторые рекомендации по созданию сертификатов и запросов сертификатов.
Имя субъекта
«Имя субъекта» TLS-сертификата — это поле, используемое службами, взаимодействующими с DNS. Поле «Имя субъекта» привязывает сертификат к определенному имени сервера или домена.
Имя субъекта — это различающееся имя X.500, которое состоит из одного или нескольких относительных различающихся имен, которые также упоминаются как RDN (relative distinguished names). В следующей таблице перечисляются относительные различающиеся имена, часто используемые для идентификации организаций или объектов серверов.
Имя
Аббревиатура
Тип
Макс. размер
Частота Макс.\рекомендуемая в сертификате\запросе
Порядок в субъекте
Коды страны/региона являются кодами ISO 3166-1. Дополнительные сведения см. по ссылке Английские названия стран и элементы кода.
«Компонент домена» и «Страна/регион» согласно соглашению являются взаимно исключающими. Рекомендуется ссылаться на имя по стране/региону или по имени, существующему в службе доменных имен. Также следует иметь в ввиду, что максимальный размер компонента домена (255 символов) является суммой всех значений компонента домена.
Важно!
Хотя сертификаты могут иметь несколько полей общего имени, некоторые службы предполагают, что существует только одно общее имя. Поэтому наличие нескольких общих имен может быть причиной проблем взаимодействия. Рекомендуется, чтобы создаваемый сертификат или запрос сертификата содержал только одно общее имя.
Указание относительных различающихся имен
Другие имена субъектов, которые могут представлять тот же самый сервер, приводятся в следующих примерах:
При наличии зарегистрированного DNS-имени, которое применяется для отправки SMTP-почты, рекомендуется использовать соглашение по компонентам доменов и DNS-имя для имени сертификата, например DC=contoso, DC=com, CN=mail1.contoso.com.
Однако при создании запроса сертификата для поставщика центра сертификации необходимо ясно понимать требования центра сертификации, предъявляемые к полю «Имя субъекта», и потребности своей уникальной инфраструктуры открытого ключа. В некоторых случаях, возможно, потребуется использовать код страны/региона («C»). В этом случае необходимо зарегистрировать относительное различающееся имя в центре регистрации X.500.
Международные имена субъектов
Для имен субъектов, содержащих символы, отличные от ASCII-символов, можно ввести параметр SubjectName в качестве различающегося имени, заключенного в кавычки, как показано ниже:
—SubjectName » C=ES,O=Diversion de Bicicleta,CN=mail1. DiversiondeBicicleta.com «
Имена субъектов и имена доменов
По соглашению общее имя может содержать полное доменное имя (FQDN). Хотя этот способ широко практикуется, необходимо обратить внимание на следующие две проблемы.
Во-первых, максимальный размер поля общего имени равен 64 символам. Это меньше, чем максимальный размер полного доменного имени. Поэтому при использовании имени FQDN, содержащего более 64 символов, необходимо поместить доменное имя в поле «Дополнительное имя субъекта». Параметр DomainName — это параметр, сопоставленный с дополнительным именем субъекта в конечном сертификате.
Во-вторых, полное доменное имя ограничено подмножеством набора символов ASCII. Однако общее имя (CN) поддерживает Юникод. Поэтому можно создать действительный сертификат с общим именем, которое выглядит как DNS-имя, но является недопустимым DNS-именем. Программное обеспечение, ищущее полное доменное имя в общем имени сертификата, не вернет правильный результат, если общее имя содержит символы, отличные от ASCII-символов. Например, если создать сертификат с именем субъекта, где CN=mail.microsoft.com, данное имя не будет считаться полным доменным именем, поскольку оно содержит символ Юникода — «i» с диакритическим знаком (x00ef). Общее имя в Юникоде легко спутать с именем FQDN из-за незначительных различий между символом «i» с диакритическим знаком (x00ef) и символом «i» в ASCII (x0069). Задача сертификата Exchange не требует, чтобы общее имя субъекта было допустимым именем FQDN. По умолчанию это означает, что командлет включает полное доменное имя сервера в качестве общего имени по умолчанию.
Имена доменов в сертификатах
Для протокола TLS сертификаты должны содержать DNS-имена, так как TLS является протоколом, работающим на основе службы DNS. Клиенты проверяют, чтобы DNS-имя сервера, к которому они подключаются с помощью DNS-имени, позволяло подключиться к требуемому серверу. Это верно для веб-браузеров, которые подключаются к веб-сайту по протоколу HTTPS, и для SMTP-серверов, передающих электронную почту через Интернет или интранет.
Одиночный сервер может поддерживать несколько DNS-имен по следующим причинам:
Если после установки TLS-подключения клиент обнаружит искомое имя, клиент игнорирует другие имена в сертификате. Несколько имен домена и сервера могут добавляться в поле дополнительного имени субъекта TLS-сертификата. Сертификат, содержащий несколько дополнительных имен субъекта, можно создать с помощью параметра DomainName командлета New-ExchangeCertificate. Параметр DomainName является многозначным, поэтому может принимать несколько имен.
Сертификаты X.509 могут содержать в расширении сертификата «Дополнительное имя субъекта» (SubjectAltName) одно или несколько DNS-имен либо вообще не содержать DNS-имен. DNS-имена в расширении SubjectAltName точно соблюдают ограничения, существующие для DNS-имен. Они не должны содержать более 255 символов, и, кроме того, должны состоять только из символов A-Z, a-z, 0-9 и тире (-).
Логика сопоставления имен для функции безопасности домена
Логика сопоставления имен сертификатов для функции безопасности домена проверяет соответствие имени домена в полученному сертификате имени домена, в который отправляется почта. В качестве примера рассмотрим имя FQDN домена получателя woodgrovebank.com. Логика сопоставления имен сертификатов выполняет поиск всех DNS-имен в сертификатах, и если одно из DNS-имен совпадает, сертификат считается соответствующим указанному домену.
В данном примере логика сопоставления имен сертификатов принимает сертификат с полностью совпадающим именем домена, таким как woodgrovebank.com. Кроме того, в сертификатах могут использоваться подстановочные знаки для имен доменов, поэтому сертификат с DNS-именем *.woodgrovebank.com считается соответствующим. Дополнительные сведения об именах домена с подстановочными знаками в подразделе «Имена домена с подстановочными знаками» ниже в данном разделе.
Логика сопоставления имен сертификатов также выполняет поиск в DNS глубиной в один узел. Поэтому mail1.woodgrovebank.com также считается соответствующим woodgrovebank.com. Тем не менее, DNS-имена с глубиной более двух узлов не принимаются. Поэтому, например, mail1.us.woodgrovebank.com не будет считаться соответствующим woodgrovebank.com.
Рекомендации по доменным именам для SMTP-серверов в Интернете
При создании сертификата или запроса сертификата для пограничного транспортного сервера, осуществляющего TLS-взаимодействие по протоколу SMTP через Интернет, в запрос необходимо включить следующий набор имен доменов:
Доменные имена с подстановочными знаками
Доменные имена с подстановочными знаками относятся к специальному типу доменных имен, представляющих несколько подчиненных доменов. Доменные имена с подстановочными знаками помогают упростить сертификаты, так как одно доменное имя с подстановочными знаками представляет все подчиненные домены этого домена. Эти имена представляются символом звездочки ( * ) в DNS-узле. Например, *.contoso.com представляет contoso.com и все поддомены для contoso.com. Если при создании сертификата или запроса сертификата для всех принятых доменов использовать подстановочный знак, можно существенно упростить запрос.
Выбор сертификата
Exchange выполняет различные процессы выбора сертификата в зависимости от типа SMTP-подключения.
При взаимодействии транспортных серверов-концентраторов друг с другом или с пограничными транспортными серверами в организации используются анонимные сертификаты TLS. Дополнительные сведения см. в разделах Выбор входящих анонимных сертификатов TLS и Выбор исходящих анонимных TLS-сертификатов.
Когда узел или клиент SMTP подключается к пограничному транспортному серверу или транспортному серверу-концентратору, используется процесс выбора сертификата STARTTLS. Дополнительные сведения см. в разделе Выбор входящих сертификатов STARTTLS.
Создание сертификатов TLS
Во время установки сервера Exchange 2010 создается самозаверяющий сертификат, который использует все имена серверов и доменов, известные приложению Exchange на момент установки. Можно клонировать этот сертификат для использования на дополнительных серверах. Этот сертификат можно также заменять сертификатами, выданными сторонним центром сертификации. В следующих разделах приведены пошаговые инструкции для каждой задачи.
Ссылки
Дополнительные сведения о технологиях криптографии и сертификатов, а также об используемых понятиях см. в следующих публикациях:
Так уж вышло, что несмотря на относительно неплохое понимание инфраструктуры открытых ключей, содержимое *.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 типов данных. Приведем таблицу кодирования для этих типов:
Наименование типа
Краткое описание
Представление типа в DER-кодировке
SEQUENCE
Используется для описания структуры данных, состоящей из различных типов.
30
INTEGER
Целое число.
02
OBJECT IDENTIFIER
Последовательность целых чисел.
06
UTCTime
Временной тип, содержит 2 цифры для определения года
17
GeneralizedTime
Расширенный временной тип, содержит 4 цифры для обозначения года.
18
SET
Описывает структуру данных разных типов.
31
UTF8String
Описывает строковые данные.
0C
NULL
Собственно NULL
05
BIT STRING
Тип для хранения последовательности бит.
03
Зная как кодируется каждый из этих типов, мы можем попытаться распарсить наш *.crt файл.
Преобразуя байты-идентификаторы типов и убирая байты описывающие длину блоков получим следующую структуру:
Важным моментом, о котором стоит особенно упомянуть являются данные, для которых вычисляется подпись. Интуитивно может показаться, что подписываются все данные идущие до последнего поля 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 сертификат.
Поля, используемые сертификатами для служб TLS
Поля, используемые сертификатами для служб TLS
Важно!