Какая цепь на дубе том?

Как работает PKI: удостоверяющие центры и цепочка доверия

В предыдущей статье мы выяснили:

Сертификат = открытый ключ + сведения о владельце + подпись удостоверяющего центра

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

Допустим, сертификат Ивана подписал удостоверяющий центр «Ромашка». Тогда нужен открытый ключ «Ромашки». Он находится в сертификате самого удостоверяющего центра. Но кто подписал этот сертификат? Другой удостоверяющий центр? А кто подтвердил его?

Если идти так бесконечно, получится криптографическая версия вопроса:

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

Вся система называется PKI — инфраструктура открытых ключей.

Что такое PKI

PKI — инфраструктура открытых ключей. Это не один алгоритм и не один сервер, а совокупность:

• ключей;

• сертификатов;

• удостоверяющих центров;

• правил выдачи;

• процедур идентификации;

• реестров;

• механизмов отзыва;

• средств проверки;

• политик доверия;

• программ и организационных мер.

Можно сказать так:

Без PKI открытый ключ остаётся набором чисел. С PKI появляется возможность ответить:

• чей это ключ;

• кто подтвердил владельца;

• кому доверяет проверяющая система;

• действует ли сертификат;

• не отозван ли он;

• разрешено ли использовать ключ для нужной цели.

Доверие растёт деревом

Иерархическую PKI удобно представить как дерево.

Корневой УЦ
                      │
          ┌───────────┴───────────┐
          │                       │
 Промежуточный УЦ A      Промежуточный УЦ B
          │                       │
     ┌────┴────┐             ┌────┴────┐
     │         │             │         │
  Алиса     Борис         Компания   Сервис

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

Корень

Ветви

Цепочка

Поэтому отсылка к дубу появилась не только ради А.С. Пушкина. Хотя кот учёный, который проверяет CRL, всё ещё не входит в стандарт.

Конечный сертификат

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

• проверки электронной подписи;

• аутентификации;

• шифрования;

• другой разрешённой цели.

Упрощённо:

Владелец: Иван Иванов
Открытый ключ: Q Иван
Издатель: Промежуточный УЦ

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

Промежуточный удостоверяющий центр

Промежуточный УЦ выпускает сертификаты:

• конечным владельцам;

• иногда другим подчинённым УЦ.

Его сертификат подписан вышестоящим удостоверяющим центром.

Сертификат Ивана
Подписан: Промежуточным УЦ

Сертификат промежуточного УЦ
Подписан: Корневым УЦ

Зачем нужен промежуточный уровень? Можно было бы подписывать все сертификаты прямо корневым ключом. Но это неудобно и рискованно. Промежуточные УЦ позволяют:

• разделять направления работы;

• применять разные политики;

• ограничивать области выдачи;

• реже использовать корневой закрытый ключ;

• менять операционные ключи без полной замены корня;

• локализовать последствия компрометации.

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

Корневой удостоверяющий центр

Корневой сертификат находится на вершине иерархии. Обычно он самоподписанный:

Владелец:
Корневой УЦ

Издатель:
Тот же корневой УЦ

Это может показаться странным.

Если сертификат подписал сам себя, откуда доверие? Ответ:

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

• операционной системы;

• браузера;

• приложения;

• корпоративной инфраструктуры;

• специализированной системы проверки.

Такой заранее доверенный объект называют якорем доверия (Trust Anchor) Проверка цепочки должна дойти до якоря, которому система уже доверяет. Корень не доказывает сам себе, что он хороший. Его заранее пригласили в список доверенных.

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

Любая система доверия должна с чего-то начинаться. В PKI этим началом является якорь доверия. Проверяющая сторона заранее принимает решение:

Это решение может основываться на:

• законодательстве;

• аккредитации;

• политике организации;

• поставке доверенного списка;

• настройках операционной системы;

• ручной установке;

• договорённости между участниками.

Важно:

Один и тот же сертификат может быть доверенным на компьютере A и недоверенным на компьютере B. Если на втором компьютере нет нужного корня или соответствующего правила доверия. Математика сертификата при этом не изменилась. Изменилась политика доверия.

Как строится цепочка

Допустим, мы проверяем подпись Ивана. В его сертификате указано:

Издатель: Промежуточный УЦ A

Программа ищет сертификат этого УЦ. Находит:

Сертификат промежуточного УЦ A

Издатель: Корневой УЦ

Затем проверяет, есть ли корневой сертификат среди доверенных якорей. Получается путь:

Сертификат Ивана
        ↓
Сертификат промежуточного УЦ
        ↓
Корневой сертификат
        ↓
Доверенный якорь

Точнее, подписи проверяются снизу вверх:

Подпись сертификата Ивана
проверяется открытым ключом промежуточного УЦ

Подпись сертификата промежуточного УЦ
проверяется открытым ключом корневого УЦ

Корневой сертификат
сопоставляется с доверенным якорем

Если всё успешно, цепочка криптографически ведёт к доверенной точке.

Цепочку строят, путь проверяют

В документации иногда смешивают два процесса.

Построение пути

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

• из контейнера подписи;

• из локального хранилища;

• из системного хранилища;

• из сетевых источников;

• из приложенных данных.

Проверка пути

Задача: убедиться, что найденный путь допустим. После построения нужно проверить:

• подписи сертификатов;

• сроки действия;

• ограничения;

• назначение ключей;

• статус отзыва;

• политики;

• критические расширения;

• другие требования.

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

Что проверяется в каждом звене

1. Подпись издателя

Для каждого сертификата проверяется: действительно ли его подписал заявленный издатель? Если байты сертификата изменены или подпись поддельна, проверка не пройдёт.

2. Срок действия

Проверяется интервал: Not Before и Not After. Важно учитывать, для какого момента выполняется проверка:

• для текущего времени;

• для подтверждённого времени подписания;

• для другого момента по правилам системы.

3. Право выпускать сертификаты

Сертификат промежуточного УЦ должен иметь соответствующие признаки и назначения. Например: CA = TRUE, и допустимое использование ключа для подписания сертификатов. Обычный пользовательский сертификат не должен внезапно стать издателем. Даже если очень хочет карьерного роста.

4. Ограничение длины пути

УЦ может ограничить количество подчинённых уровней, например: После этого УЦ может быть не более одного следующего уровня УЦ. Так контролируется глубина иерархии.

5. Политики

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

6. Ограничения имён и областей

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

7. Критические расширения

Если встречается неизвестное критическое расширение, его нельзя просто проигнорировать. Иначе система могла бы пропустить важное ограничение.

Корневой сертификат тоже проверяется?

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

Самоподпись подтверждает самосогласованность. Доверие приходит извне.

Почему сертификат может быть «верным, но недоверенным»

Возможна ситуация:

Подпись документа: математически верна

Сертификат владельца: математически корректен

Цепочка: не ведёт к доверенному корню

Результат:

Это не противоречие:

• математика отвечает: подпись соответствует этому ключу?,

• а PKI отвечает: можно ли связать этот ключ с заявленным владельцем через доверенную инфраструктуру?

Ответы могут различаться.

Как цепочка попадает в файл подписи

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

• сертификат подписанта;

• промежуточные сертификаты;

• другие вспомогательные сертификаты.

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

Свой корневой сертификат

Свой промежуточный сертификат

Свой сертификат «директора»

и сказать:

Нет. Корень должен быть доверен заранее или через отдельный надёжный механизм. Цепочку можно приложить. Доверие — нельзя просто подложить в архив.

Что такое отзыв сертификата

У сертификата есть срок действия. Но иногда ждать его окончания нельзя. Представим:

• потерян токен;

• закрытый ключ скопирован;

• обнаружена компрометация;

• сведения владельца изменились;

• сертификат выпущен ошибочно.

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

• CRL;

• OCSP.

CRL: список тех, кому больше не верят

CRL (Certificate Revocation List) по-русски: Список отозванных сертификатов. Удостоверяющий центр периодически выпускает подписанный список. В нём могут находиться:

• серийные номера сертификатов;

• даты отзыва;

• причины;

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

Упрощённо:

CRL

Издатель: УЦ «Пример»
Выпущен: 01.09.2026
Следующее обновление: 02.09.2026

Отозваны:
Сертификат № 12345
Сертификат № 67890

Список подписывается удостоверяющим центром. Проверяющая программа должна убедиться:

• что подпись CRL верна;

• что список относится к нужному издателю;

• что данные достаточно актуальны;

• что проверяемый сертификат не включён в список.

Преимущество: Один файл может содержать статусы множества сертификатов

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

OCSP: спросить про один сертификат

OCSP (Online Certificate Status Protocol). Проверяющая программа отправляет запрос: каков статус сертификата с таким издателем и серийным номером? Сервис отвечает, например:

good
revoked
unknown

Упрощённо:

Проверяющая программа
        ↓
Запрос OCSP
        ↓
Сервис статуса
        ↓
Подписанный ответ

Ответ должен быть проверен. Важно понимать значение статусов аккуратно, например:

good

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

• что пользователь прочитал документ;

• что у него были полномочия;

• что компьютер не заражён;

• что подпись юридически значима в любом контексте.

OCSP отвечает на более узкий вопрос о статусе сертификата. Не стоит спрашивать у градусника, кто подписал договор.

CRL или OCSP — что лучше

У каждого механизма свои свойства.

На практике инфраструктура и формат подписи определяют, какие данные используются.

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

Об этом — в следующей статье.

Просрочен, отозван, недоверен: три разных диагноза

Эти сообщения нельзя смешивать.

Сертификат просрочен

Текущая дата
позже Not After

Период действия закончился.

Сертификат отозван

Удостоверяющий центр сообщил о досрочном прекращении доверия к сертификату.

Сертификат недоверен

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

• нет корневого сертификата;

• не хватает промежуточного;

• корень не включён в доверенные;

• нарушены ограничения;

• цепочка не соответствует политике.

Один сертификат может быть:

Не просрочен
Не отозван
Но недоверен

Например, если он выпущен неизвестной внутренней PKI.

Или:

Доверенная цепочка
Но сертификат просрочен

Или:

Срок ещё не закончился
Но сертификат уже отозван

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

Почему не хватает промежуточного сертификата

Частая ошибка:

Не удаётся построить цепочку

При этом корневой сертификат установлен, а пользовательский сертификат есть.

Может отсутствовать промежуточное звено.

Сертификат владельца
        ↓
        ?
        ↓
Корневой сертификат

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

Сертификат владельца
        ↓
Промежуточный УЦ
        ↓
Корневой УЦ

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

PKI — не блокчейн

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

Владелец
    ↓
   УЦ
    ↓
Корневой УЦ
    ↓
Доверенная политика

В распределённых реестрах используются другие модели согласования и доверия. Сертификат X.509 не становится блокчейном от того, что в нём много длинных чисел. И цепочка сертификатов — не цепочка блоков. Кот учёный подтверждает.

Может ли быть несколько правильных цепочек

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

• перекрёстные сертификаты;

• несколько промежуточных УЦ;

• разные доверенные хранилища;

• переходные схемы при обновлении инфраструктуры.

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

• был криптографически корректным;

• соблюдал ограничения;

• заканчивался доверенным якорем.

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

Что именно даёт PKI

PKI не делает закрытый ключ неуязвимым. Она не заменяет хеш-функцию. Не подписывает документ сама по себе.

Её задача — организовать управляемое доверие. Она помогает ответить:

• Кому принадлежит открытый ключ?

• Кто это подтвердил?

• На основании каких правил?

• До какого момента действует подтверждение?

• Не прекращено ли оно досрочно?

• Можно ли провести цепочку к доверенному источнику?

Вместе получается:

Документ
    ↓
Хеш
    ↓
Электронная подпись
    ↓
Открытый ключ
    ↓
Сертификат владельца
    ↓
Промежуточные УЦ
    ↓
Корневой УЦ
    ↓
Якорь доверия

Вот почему одной фразы «подпись математически верна» недостаточно для полной проверки.

Резюме

PKI — инфраструктура открытых ключей.

Она объединяет:

• сертификаты;

• удостоверяющие центры;

• доверенные корни;

• правила выдачи;

• механизмы отзыва;

• процедуры проверки.

Цепочка доверия обычно выглядит так:

Сертификат подписанта
        ↓
Промежуточный УЦ
        ↓
Корневой УЦ
        ↓
Доверенный якорь

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

• подписи сертификатов;

• сроки;

• назначения;

• ограничения;

• статус отзыва;

• политики;

• доверенный корень.

Но остаётся ещё одна проблема. Представим, что сегодня всё проверяется:

Сертификат действует
CRL доступен
OCSP отвечает
Алгоритмы поддерживаются

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

Для этого нужны доверенное время и сохранённые данные проверки.

В следующей статье: «Как сохранить электронную подпись на годы: метки времени и усовершенствованные форматы».