Ещё больше и лучше о цифровых сертификатах: X.509, PKI, PKCS — Expertus metuit

Основы криптографии¶

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

Википедия нам даёт такое определение:

Криптогра́фия (от др.-греч. κρυπτός «скрытый» γράφω «пишу») — наука о методах обеспечения конфиденциальности (невозможности прочтения информации посторонним), целостности данных (невозможности незаметного изменения информации), аутентификации (проверки подлинности авторства или иных свойств объекта), шифрования (кодировка данных).

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

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

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

Важным для нас вариантом асимметричного шифра является криптосистема с открытым ключом (public-key cryptography). В её основе лежат такие принципы:

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

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

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

Алгоритм подписи чаще всего оперирует не с сообщением целиком, а с его дайджестом (digest), то есть «сжатым» при помощи алгоритма криптографического хеширования (например, SHA-1 или гостовского СТРИБОГ). И в целом схема выглядит так:

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

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

──────────────────

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

приложение. требования к форме квалифицированного сертификата ключа проверки электронной подписи | гарант

------------------------------

------------------------------

Certificate ::= SIGNED { SEQUENCE {

    version                 [0]     Version DEFAULT v l,

    serialNumber                    CertificateSerialNumber,

    signature                       AlgorithmIdentifier,

    issuer                          Name,

    validity                        Validity,

    subject                         Name,

    subjectPublicKeyInfo            SubjectPublicKeyInfo,

    issuerUniqueIdentifier  [1]     IMPLICIT UniqueIdentifier OPTIONAL,

    subjectUniqueIdentifier [2]     IMPLICIT UniqueIdentifier OPTIONAL,

    extensions              [3]     Extensions OPTIONAL } }

SIGNED { ToBeSigned } ::= SEQUENCE {

    toBeSigned                      ToBeSigned,

    COMPONENTS OF                   SIGNATURE { ToBeSigned } }

SIGNATURE { ToBeSigned } ::= SEQUENCE {

    algorithmIdentifier             AlgorithmIdentifier,

    encrypted                       ENCRYPTED-HASH { ToBeSigned } }

ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING (CONSTRAINED BY

                                       { ToBeSigned }).

------------------------------

------------------------------

------------------------------

------------------------------

KeyUsage ::= BIT STRING {

    digitalSignature      (0),

    contentCommitment     (1),

    keyEncipherment       (2),

    dataEncipherment      (3),

    keyAgreement          (4),

    keyCertSign           (5),

    cRLSign               (6),

    encipherOnly          (7),

    decipherOnly         (8)}.

IssuerSignTool ::= SEQUENCE {

    signTool            UTF8String SIZE(1.200),

    cATool              UTF8String SIZE(1..200),

    signToolCert        UTF8String SIZE(1.. 100),

    cAToolCert          UTF8String SIZE(1.100) }.

Закрытый ключ rsa¶

Классическая команда для создания ключа RSA длиной 512 бит в файле rsa512_1.pem выглядит так:

Результатом будет файл с одним PEM-блоком с меткой RSA PRIVATE KEY:

Внутри этого блока закодирован объект в формате, описанном в стандарте PKCS#1. PKCS#1 описывает алгоритм RSA, на данный момент его актуальный текст опубликован в виде RFC 3447. В стандарте описаны бинарные структуры ключей, именно в этом формате их создаёт команда openssl genrsa.

Вот как выглядит разобранный на составные закрытый ключ RSA в формате PKCS#1 (я сократил слишком длинные строки для читабельности, помним, что почти все объекты в нашей области закодированы в DER, который позволяет проводить автоматический разбор структуры):

Для бо́льшей наглядности я использовал аргумент -i, он отделяет вложенные блоки отступом. В данном случае мы видим, что внутри файла последовательно записаны девять чисел, в RFC 3447, раздел A.1.2 даётся такое ASN.1 определение этой структуры:

RSAPrivateKey ::= SEQUENCE {
    version           Version,
    modulus           INTEGER,  -- n
    publicExponent    INTEGER,  -- e
    privateExponent   INTEGER,  -- d
    prime1            INTEGER,  -- p
    prime2            INTEGER,  -- q
    exponent1         INTEGER,  -- d mod (p-1)
    exponent2         INTEGER,  -- d mod (q-1)
    coefficient       INTEGER,  -- (inverse of q) mod p
    otherPrimeInfos   OtherPrimeInfos OPTIONAL
}

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

Команда openssl genrsa не умеет записывать ключ сразу в формате DER. Если вам нужен именно он, можно сконвертировать ключ из rsa512_1.pem в файл rsa512_1.der вот такой командой:

Аргумент -outform DER как раз задаёт выходной формат данных, если его не указывать, то подразумевается -outform PEM.

──────────────────

Как я уже упоминал выше, данные закрытого ключа можно зашифровать симметричным алгоритмом. Для этого нужно в команду openssl genrsa передать дополнительный аргумент, после чего программа попросит вас ввести два раза пароль, которым будут зашифрованы сгенерённые данные. Например, чтобы зашифровать ключ шифром AES-128-CBC, нужно выполнить команду:

Результирующий файл rsa512_1_e.pem содержит один PEM-блок с такой же меткой RSA PRIVATE KEY, однако к блоку добавлены дополнительные атрибуты (они описаны в RFC 1421), указывающие, что данные внутри зашифрованы:

Расшифровать такой файл можно такой командой (нужно знать пароль, которым зашифрованы данные):

Ну и также вы можете зашифровать уже имеющийся закрытый ключ RSA (rsa512_1.pem) командой openssl rsa (воспользуемся алгоритмом AES-192-CBC):

Замечания

Список доступных алгоритмов для шифрования зависит от версии и сборки openssl. Базовые алгоритмы типа AES-128-CBC, AES-192-CBC, DES-CBC, DES-EDE3-CBC и несколько других обычно есть везде.

Как вы могли заметить, для создания ключей RSA используется команды openssl genrsa, а для модификации — openssl rsa. Вторая команда также может использоваться для конвертации PEM в DER и обратно, генерации открытого ключа из закрытого и некоторых других операций.

Зашифрованный ключ формата PKCS#1 нельзя хранить в виде DER-файла. Если вы попытаетесь сконвертировать закрытый RSA-ключ командой openssl rsa, то программа спросит у вас пароль и запишет DER-файл с расшифрованным ключом внутри.

Никогда не используйте закрытый RSA ключ длиной менее 2048 бит, я в статье использую 512 только для демонстрации!

Инфраструктура уц и сертификаты¶

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

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

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

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

Поля issuer и subject являются структурированными, то есть это не просто строчки текста, а оформленные в жёстко заданную структуру данные типа distinguished name. Об этом подробнее я расскажу в практическом разделе.

Таким образом любой сертификат A в подобной инфраструктуре подписан закрытым ключом, открытая часть которого записана в каком-то другом сертификате B. Для простоты обычно в таком случае говорят, что сертификат A подписан сертификатом B. В свою очередь сертификат B подписан сертификатом C и так далее.

Образуется цепочка зависимостей, которая завершается сертификатом Z специального вида, в котором поля issuer и subject совпадают. Это означает, что сертификат Z подписан закрытым ключом, открытая часть которого записана в этом же сертификате. Он так и называется — самоподписанный сертификат (self-signed certificate).

──────────────────

Считается, что вы как клиент доверяете (trust) сертификату A, если вы доверяете записанным в нём данным. Например, если вы получили сертификат организации через надёжный канал от надёжного представителя организации и записали на надёжном диске.

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

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

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

В итоге, только удостоверяющие центры (certification authority) обладают сертификатами, которые можно использовать для подписывания других сертификатов, чтобы они могли включаться в цепочку доверия. Их принято называть CA-сертификатами (CA certificate).

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

──────────────────

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

Здесь нужно отметить, что интерпретация «срока годности» сертификата целиком лежит на стороне программного обеспечения, которое сертификат использует. Нет никаких объективных причин, по которым сертификат перестаёт быть доверенным после достижения некоторой даты.

──────────────────

Когда удостоверяющий центр выписывает сертификат, он записывает в поле serialNumber числовое значение, которое должно быть разным для каждого сертификата, заверенного этим конкретным сертификатом УЦ (X.509, п. 4.1.2.2). Туда можно записывать порядковый номер, можно текущую дату-время, можно случайное число, главное требование — это число должно быть уникальным для каждого выписанного сертификата.

──────────────────

X.509 — стандарт очень гибкий и позволяет добавлять произвольные дополнительные поля помимо базовых, это делается через расширения (extensions), я о них подробнее расскажу в практической части.

Использование сертификатов для шифрования¶

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

В общем случае X.509-сертификаты не предназначены для шифрования данных, единственный пригодный для этого алгоритм — RSA, однако это исключение. Тем не менее, в разделе Используемые криптоалгоритмы я рассказал, как можно использовать сертификаты совместно с протоколом Diffie-Hellman для безопасного обмена ключами симметричного шифрования. А в этом разделе я расскажу, как это можно реализовать на практике через команды openssl.

Действующие лица: Алиса и Боб, у каждого из них есть свой X.509-сертификат с закрытым ключом, причём Алиса и Боб заранее обменялись сертификатами каким-то надёжным способом (например, при личной встрече). И с этого момента весь обмен данными происходит через небезопасный открытый канал.

Алиса хочет организовать безопасный сеанс связи с Бобом поверх небезопасного канала. Для этого отлично подходит симметричный алгоритм AES-128-CBC, однако для него обе стороны должны использовать одинаковый ключ — набор байтов размером 128 бит. Алиса и Боб будут для обмена ключом пользоваться протоколом Diffie-Hellman с аутентификацией через цифровые подписи.

Создадим сначала сертификаты и закрытые ключи к ним для каждой из сторон. Алиса создаёт закрытый ключ alice-x509.key и самоподписанный сертификат alice-x509.crt:

И Боб делает то же самое — ключ в файле bob-x509.key и самоподписанный сертификат bob-x509.crt:

Дальше стороны должны заранее надёжным и безопасным способом передать друг-другу свои сертификаты.

──────────────────

Через какое-то время Алиса захотела обменяться важными данными с Бобом через e-mail. Это начало новой сессии обмена, в которой будут использоваться новые ключи (эфемерные, то есть не фиксированные, а созданные специально для этого момента, после сессии эфемерные ключи стираются), поэтому Алиса должна выбрать параметры протокола Diffie-Hellman, это делается такой командой:

Здесь 4096 означает размер случайного простого числа в битах, он в настоящее время считается безопасным. Теперь Алиса на основе этого файла с параметрами создаёт свой закрытый ключ dh-alice.key (это ещё не эфемерный ключ, а только заготовка для него!):

И выделяет из него открытый ключ:

Затем Алиса конкатенирует два файла dhp.pem и alice-dh-pub.pem в один alice2bob.pem:

И создаёт цифровую подпись для него (в виде отдельного файла alice2bob.pem.sig), используя свой закрытый ключ от X.509-сертификата:

Дальше Алиса отправляет Бобу два файла: alice2bob.pem и alice2bob.pem.sig.

──────────────────

Боб получает от Алисы файл и цифровую подпись. Для проверки подписи ему сначала нужно извлечь из сертификата Алисы открытый ключ в файл alice-x509-pubkey.pem:

И дальше проверить им цифровую подпись:

Проверка прошла успешно, теперь Боб уверен, что полученный им файл alice2bob.pem действительно пришёл от Алисы, поэтому можно продолжать. Боб создаёт свой закрытый DH-ключ на основе полученных параметров:

Обратите внимание, что в аргументе с параметрами указан файл alice2bob.pem, в котором записано два разных PEM-блока, но так как PEM — это контейнер, openssl берёт из него только те данные, которые ему нужны в текущем контексте, а здесь контекст — это параметры DH, именно такой блок и будет прочитан. Другими словами, нет никакой необходимости разделять файл на части.

Дальше Боб выделяет открытый ключ на основе только что созданного закрытого:

И, наконец, создаёт свой эфемерный закрытый ключ в файле bob-secret.key:

Теперь Боб создаёт цифровую подпись для своего открытого DH-ключа:

И отправляет Алисе два файла: bob-dh-pub.pem и bob-dh-pub.pem.sig.

──────────────────

Алиса проверяет цифровую подпись аналогичным образом: выделяет открытый ключ из сертификата Боба и верифицирует файл bob-dh-pub.pem с подписью bob-dh-pub.pem.sig:

И, наконец, Алиса создаёт свой эфемерный ключ на основе собственного закрытого DH-ключа (alice-dh.key) и полученного от Боба открытого DH-ключа (bob-dh-pub.pem):

Мы можем убедиться, что оба их эфемерных ключа одинаковые:

──────────────────

Теперь Алиса может зашифровать файл alice-message.txt (внутри которого только одна строчка: Very secret message.), используя эфемерный ключ в качестве пароля:

Здесь мы используем алгоритм хеширования MD5, чтобы получить из файла эфемерного ключа ровно 128 бит AES-ключа.

Боб теперь может расшифровать файл так:

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

Используемые криптоалгоритмы¶

В инфраструктуре открытых ключей чаще всего используются RSA, DSA и ECC.

• RSA — криптосистема, названная по первым буквам имён её создателей: Rivest-Shamir-Adleman. В основе её теории лежит сложная задача факторизации (разделения на множители) произведения двух очень больших простых чисел. Выбирается два случайных очень больших простых числа p и q, их произведение n = p · q называется модулем / modulus и длина модуля в битах задаёт длину закрытого ключа. Чем больше длина, тем более надёжным считается ключ. Также выбирается сравнительно небольшое простое число e (чаще всего это 65537), называемое открытой экспонентой / public exponent. Дальше из модуля n вычисляется по специальному алгоритму (который я тут не буду объяснять) закрытая экспонента / private exponent. В итоге формируется открытый ключ в виде пары чисел (e, n) и закрытый ключ в виде пары (d, n). Этот алгоритм долгое время был самым распространённым и по умолчанию фигурировал во всех инструкциях и мануалах. Однако в середине девяностых был разработан алгоритм для квантовых компьютеров, выполняющий факторизацияю чисел. Хотя квантовых компьютеров ещё нет, но теперь RSA считается потенциально слабым, если длина закрытого ключа меньше 2048 бит. RSA содержит алгоритмы как для шифрования, так и для цифровой подписи.
• DSA — криптографический алгоритм, названием расшифровывается как Digital Signature Algorithm, то есть алгоритм цифровой подписи. Он основан на математической теории возведения в степень по модулю и задаче дискретного логарифмирования. В отличие от RSA, этот алгоритм может использоваться только для подписывания данных, но не для их шифрования. Исторически DSA использовался и продолжает использовать в операциях с государственными органами США, однако нас он не интересует, поэтому больше о нём не будем, просто имейте в виду, что он поддерживается при создании сертификатов тоже. DSA может использоваться только для цифровой подписи.
• ECC (или просто EC) — набор криптосистем на основе теории эллиптических кривых над конечным полем. Сейчас эти виды шифров используется всё активнее вместо RSA, поскольку они быстрее, размер ключа значительно меньше, потенциально устойчивее к взлому на квантовых компьютерах. Эллиптическая криптография построена на основе набора алгебраических операций на эллиптической кривой, которые, в свою очередь, строятся на основе операций в конечном поле, над которым задана кривая. В общем, это такая хардкорная высшая математика, знать которую совсем не обязательно для использования шифров. Крипто-алгоритмов на основе EC достаточно много, часть из них была перенесена из старых классических крипто-систем, часть придумана заново. Например, алгоритм цифровой подписи ГОСТ 34.10-2021 также использует эллиптические кривые для работы. Некоторые из ECC-алгоритмов могут использоваться для шифрования, а некоторые для цифровой подписи.

Из широко известных криптосистем только RSA позволяет собственными ключами шифровать и подписывать, все остальные непосредственно используются только для создания цифровой подписи. Однако можно пользоваться алгоритмом Diffie-Hellman для создания общего ключа для симметричного алгоритма (например, AES) и дальше уже им зашифровывать и расшифровывать данные.

Протокол Diffie-Hellman (Diffie–Hellman key exchange, дальше я буду его коротко называть DH) играет чрезвычайно большую роль в современной криптографии, поэтому я о нём расскажу подробно.

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

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

1. Алиса и Боб придумывают по секретному числу, например, Алиса выбирает 9, а Боб — 2.
2. Алиса и Боб через открытый канал договариваются о каком-нибудь общем целом числе, скажем, 18. Это число не является секретным, но при каждом сеансе DH оно должно быть новым. Самый простой способ договориться, когда сторона, начинающая коммуникацию, просто выбирает число и другая сторона его принимает.
3. Дальше каждая сторона складывает своё секретное число и общее число, у Алисы получается 9 18=27, а у Боба 2 18=20. Полученный результат каждый отправляет другой стороне по открытому каналу.
4. Полученное число Алиса и Боб складывают со своим секретным числом: у Алисы получается 20 9 = 29, а у Боба 27 2 = 29.
5. Вот это число 29 и является ключом, который каждая из сторон использует для шифрования/дешифрования.

Я выбрал операцию сложения ради простоты объяснения, в реальном протоколе используется сложно-обратимая операция. Если её обозначить через ⊕, то для произвольных значений X и Y вычисление Z = X ⊕ Y выполняется легко;

а зная Z и X, вычислить Y исключительно сложно и затратно. В реальном DH используется функция возведения в степень в мультипликативной группе вычетов по простому модулю, её обратная операция — дискретный логарифм — считается крайне сложной и на данный момент не имеет эффективного решения.

──────────────────

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

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

1. Клиент генерирует случайное секретное значение X общее публичное значение A.
2. Клиент инициирует соединение к серверу и отправляет по нему A.
3. Сервер получает A, генерирует своё секретное значение Y и вычисляет публичное значение B на основе публичного значения A и своего секретного Y.
4. Сервер вычисляет общий секретный ключ K на основе публичного значения A и своего секретного значения Y.
5. Сервер вычисляет цифровую подпись S от объединённого набора значений A и B и отправляет клиенту публичное значение B и цифровую подпись S.
6. Клиент получает публичное значение B, вычисляет на основе B и своего секретного значения X общий секретный ключ K.
7. Клиент проверяет цифровую подпись K объединённого набора значений A и только что полученного B (помним, что у клиента уже есть открытый ключ сервера).
8. Если верификация подписи проходит успешно, вычисленный ключ K используется для шифрования и дешифрования данных между клиентом и сервером при помощи симметричного алгоритма.

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

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

Просмотр сертификата¶

Просмотр сертификата — это, пожалуй, самая частая операция, которую вы будете делать. Так как первый сертификат мы сделали только что, то и команда для его просмотра в этом разделе. Вот как это выглядит на примере только что созданного сертификата demo-root-ca.crt:

Аргумент -text означает, что мы хотим посмотреть представление сертификата в текстовом человекочитаемом виде, а -noout означает, что собственно содержимое сертификата в виде PEM-блока на экран выводить не нужно.

──────────────────

Структура сертификата в виде ASN.1-определения задана в RFC 5280, раздел 4.1. Basic Certificate Fields:

Если вы внимательно читали предыдущие разделы, то заметите, что структура аналогична CSR: блок данных типа TBSCertificate, идентификатор алгоритма и цифровая подпись. Вся содержательная часть сертификата находится внутри блока с типом TBSCertificate (напомню, что tbs расшифровывается как to be signed, то есть подлежит подписи или требует подписи). TBSCertificate определяется там же в RFC 5280 следующим образом:

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
     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     extensions      [3]  EXPLICIT Extensions OPTIONAL
                          -- If present, version MUST be v3
     }

Первые семь базовых полей являются обязательными, они всегда есть в любом сертификате (их семантика описана в RFC 5280, раздел 4.1.2 TBSCertificate):

version

версия формата сертификата, здесь может быть либо значение 0 (означает версию 1, указывается, когда в рассматриваемом блоке tbsCertificate есть только базовые поля); либо значение 2 (означает версию 3, указывается, когда есть дополнительные поля). Другие значения помимо 0 или 2 в стандарте не определены и на практике не должны использоваться.

serialNumber

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

signature

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

issuer

здесь содержится имя сертификата УЦ, которым был подписан этот сертификат. Как и в случае с CSR, здесь записывается не строка, а строго структурированное значение distinguished name (DN), я о нём подробно писал в разделе Типы данных → Distinguished Name (DN).

validity

интервал, в течение которого сертификат может быть доверенным, состоит из двух значений: notBefore и notAfter.

subject

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

subjectPublicKeyInfo

в этом поле записывается открытый ключ субъекта, он состоит из двух последовательных значений: идентификатора алгоритма (поле algorithm, см. Типы данных → AlgorithmIdentifier)) и собственно открытого ключа в бинарной форме (поле subjectPublicKey).