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

Промежуточный удостоверяющий центр (ПУЦ, англ. intermediate certification authority, ICA) — это компонент иерархической инфраструктуры открытых ключей (PKI), представляющий собой сертификат, подписанный корневым удостоверяющим центром (КУЦ) и используемый для выпуска сертификатов конечным пользователям (клиентам, серверам, устройствам). ПУЦ занимает промежуточное положение между корневым и конечным уровнями, обеспечивая разделение зон ответственности, повышение безопасности и масштабируемость системы управления цифровыми сертификатами.

Назначение и роль в PKI

В классической модели PKI существует строгая иерархия доверия. Корневой удостоверяющий центр является вершиной доверия: его самоподписанный сертификат (корневой сертификат) является эталоном, которому доверяют все участники системы. Выпуск сертификатов непосредственно от корневого центра сопряжён с рисками: компрометация КУЦ ставит под угрозу всю цепочку доверия. Промежуточные центры решают эту проблему, выступая в роли доверенных посредников.

Основные функции ПУЦ:

• Делегирование полномочий: корневой центр подписывает сертификат ПУЦ, тем самым разрешая ему выпускать сертификаты от своего имени. Это позволяет КУЦ оставаться офлайн (недоступным для сетевых атак) и использоваться только для подписи ограниченного числа сертификатов ПУЦ.
• Изоляция рисков: при компрометации ПУЦ его сертификат может быть отозван, не затрагивая корневой сертификат. Цепочка доверия восстанавливается выпуском нового ПУЦ.
• Масштабирование: ПУЦ могут быть организованы по географическому, организационному или функциональному принципу. Например, один ПУЦ может обслуживать серверы веб-сайтов, другой — корпоративные почтовые системы, третий — устройства Интернета вещей.
• Управление политиками: каждый ПУЦ может иметь собственные политики выпуска сертификатов (срок действия, требования к проверке личности, алгоритмы подписи), соответствующие задачам своего сегмента.

Виды промежуточных удостоверяющих центров

Классификация ПУЦ проводится по нескольким признакам.

По положению в иерархии

• Прямой ПУЦ (subordinate CA) — подписан непосредственно корневым центром. Является первым уровнем иерархии после КУЦ.
• Промежуточный ПУЦ (intermediate CA) — подписан другим ПУЦ. Такие цепочки могут достигать нескольких уровней (многоуровневая иерархия), что применяется в крупных распределённых системах, например, в государственных PKI или у коммерческих центров сертификации.

По сфере применения

• Общедоступные ПУЦ — используются публичными центрами сертификации (например, GlobalSign, Let's Encrypt, DigiCert) для выпуска сертификатов SSL/TLS для веб-сайтов. Их корневые и промежуточные сертификаты предустановлены в операционные системы и браузеры.
• Корпоративные (частные) ПУЦ — развёртываются внутри организаций для управления внутренними сертификатами (аутентификация сотрудников, шифрование электронной почты, подпись документов). Корневой сертификат в таком случае распространяется среди устройств организации через групповые политики.
• Государственные ПУЦ — используются в национальных системах электронной подписи и электронного правительства. В России примером является инфраструктура Минцифры, где ПУЦ могут выпускать сертификаты для госслужащих, порталов госуслуг и юридически значимых документов.

Устройство и технические характеристики

Сертификат ПУЦ, как и любой сертификат X.509, содержит набор полей:

• Subject (субъект) — имя центра (например, «Промежуточный УЦ для веб-серверов АО "Рога и Копыта"»).
• Issuer (издатель) — имя корневого или вышестоящего центра.
• Public Key (открытый ключ) — ключ, используемый для проверки подписей сертификатов, выпущенных данным ПУЦ.
• Validity (срок действия) — период, в течение которого сертификат считается действительным.
• Key Usage (использование ключа) — флаги, определяющие допустимые операции: подпись сертификатов (keyCertSign), подпись CRL (cRLSign), цифровая подпись (digitalSignature).
• Basic Constraints (базовые ограничения) — обязательное поле для ПУЦ, содержащее флаг CA:TRUE, указывающее, что центр может выпускать сертификаты.
• Path Length Constraint (ограничение длины пути) — необязательное поле, задающее максимальное количество промежуточных центров в цепочке ниже данного ПУЦ.

ПУЦ может иметь собственный список отозванных сертификатов (CRL) или использовать онлайн-протокол статуса сертификата (OCSP-ответчик). Для повышения отказоустойчивости ПУЦ часто развёртываются в кластерной конфигурации с балансировкой нагрузки.

Процесс выпуска и проверки сертификатов

Выпуск сертификата ПУЦ

1. Администратор корневого центра генерирует запрос на создание сертификата для ПУЦ (CSR).
2. Корневой центр проверяет параметры запроса (алгоритм, срок, политики) и подписывает его своим закрытым ключом.
3. Полученный сертификат ПУЦ устанавливается на сервер, который будет выполнять функции выпуска конечных сертификатов.
4. Корневой сертификат и сертификат ПУЦ связываются в цепочку доверия.

Выпуск конечного сертификата

1. Конечный пользователь (веб-сервер, клиент) генерирует пару ключей и отправляет CSR в ПУЦ.
2. ПУЦ проверяет личность пользователя (в зависимости от уровня проверки: доменная, организационная, расширенная).
3. ПУЦ подписывает конечный сертификат своим закрытым ключом.
4. Пользователь получает сертификат, который вместе с сертификатом ПУЦ и корневым сертификатом образует цепочку.

Проверка цепочки доверия

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

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

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

Преимущества и недостатки

Преимущества

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

Недостатки

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

Примеры использования

Веб-сертификаты SSL/TLS

Большинство публичных центров сертификации (например, GlobalSign, Sectigo, Let's Encrypt) используют двухуровневую или трёхуровневую иерархию. Корневой сертификат хранится в защищённом хранилище, а промежуточные сертификаты используются для ежедневного выпуска сертификатов для миллионов веб-сайтов. Например, Let's Encrypt использует промежуточный сертификат «R3», подписанный корневым «ISRG Root X1».

Корпоративные PKI

В крупных компаниях (например, «Сбербанк», «Росатом», «Газпром») развёрнуты собственные PKI с несколькими ПУЦ. Один ПУЦ может выпускать сертификаты для сотрудников (аутентификация в VPN, электронная почта), другой — для серверов внутренних приложений, третий — для устройств Интернета вещей. Это позволяет централизованно управлять политиками безопасности.

Государственные информационные системы

В России в рамках инфраструктуры электронного правительства действуют удостоверяющие центры, аккредитованные Минцифры. Промежуточные центры используются для выпуска сертификатов квалифицированной электронной подписи (КЭП) для юридических лиц и индивидуальных предпринимателей. Цепочка доверия восходит к головному удостоверяющему центру (ГУЦ), сертификат которого включён в единый реестр.

Критика и уязвимости

Основная критика применения ПУЦ связана с возможностью злоупотреблений со стороны администраторов центров. Если злоумышленник получает контроль над ПУЦ, он может выпускать поддельные сертификаты для любых доменов, что позволяет проводить атаки «человек посередине» (MITM). Для снижения риска применяются:

• Жёсткие политики (Certificate Policy, CPS) — регламентируют процедуры выпуска и отзыва.
• Аудит — регулярные проверки соответствия стандартам (например, WebTrust, CA/Browser Forum).
• Технические ограничения — использование аппаратных модулей безопасности (HSM) для хранения закрытых ключей ПУЦ.
• Прозрачность сертификатов (Certificate Transparency) — публикация всех выпущенных сертификатов в общедоступных логах для обнаружения подозрительных сертификатов.

См. также

• Инфраструктура открытых ключей
• Удостоверяющий центр
• Корневой сертификат
• Сертификат X.509
• Цепочка доверия

Источники

• Адамс К., Ллойд С. «Инфраструктуры открытых ключей: концепции, стандарты и развёртывание». — М.: Вильямс, 2004.
• Стин Д. «Безопасность сетей на основе PKI». — СПб.: Питер, 2005.
• Рекомендации CA/Browser Forum по базовым требованиям к сертификатам (Baseline Requirements).
• Документация Let's Encrypt по архитектуре цепочек сертификатов.
• Федеральный закон РФ «Об электронной подписи» № 63-ФЗ (в действующей редакции).