Роль и функции центра сертификации
Центр сертификации — организация, которая выдаёт цифровые сертификаты, поддерживает реестры, публикует сведения о статусе сертификатов и документирует политики сертификации. Его основные задачи включают формирование и управление инфраструктурой публичных ключей (PKI), обеспечение целостности цепочки доверия, ведение журналов операций и прохождение внешних аудитов. Центр сертификации реализует требования профиля сертификатов, описанные в RFC 5280, и предоставляет интерфейсы для проверки статуса сертификатов, в том числе OCSP (RFC 6960) и CRL. Для подробностей см. в услугах.
Типы сертификатов варьируются по назначению: сертификаты для аутентификации пользователей, для TLS/SSL, для подписи кода и для электронной почты (S/MIME). Отличаются поля расширений (keyUsage, extendedKeyUsage, subjectAltName), срок действия и требования к процедуре идентификации заявителя.
Ключевые функции и обязанности
Ключевые функции включают приём и проверку заявок (CSR, RFC 2986), выпуск подписанных сертификатов, публикацию CRL и OCSP-ответов, управление жизненным циклом ключей и ведение политики сертификации (CP/CPS). Технические параметры, типично прописываемые в политике: минимальная длина ключа RSA 2048 бит, поддержка ECC (secp256r1/P-256), алгоритмы хеширования не слабее SHA-256, период валидности сертификатов (часто 1–3 года для TLS).
Взаимодействие с регистрационными агентами и пользователями
Регистрационные агенты (RA) выполняют проверку личности и подтверждение атрибутов субъекта согласно CP/CPS. Процесс может включать личную верификацию по документам, удалённую проверку через электронные идентификаторы или комбинированные методы. Пользователь подаёт CSR или получает ключи, сгенерированные на защищённом устройстве; ответственность за сохранность закрытого ключа остаётся за владельцем при условии требований политики.
Структура сертификата и принципы PKI
PKI основана на иерархии доверия: корневой центр (self-signed), промежуточные центры и конечные сертификаты. Доверие строится через цепочку сертификатов и проверку подписи каждого звена, ограничений basicConstraints и политики сертификатов (OID).
Что содержит сертификат и как читать его поля
Стандартный X.509 сертификат включает поля: версия, серийный номер, алгоритм подписи, issuer (эмитент), validity (notBefore, notAfter), subject, subjectPublicKeyInfo (алгоритм и ключ), а также расширения: keyUsage, extendedKeyUsage, subjectAltName, CRLDistributionPoints, authorityInfoAccess. Поле serialNumber однозначно идентифицирует сертификат у эмитента; поля thisUpdate/nextUpdate важны для CRL, а OCSP-ответы содержат поля thisUpdate и nextUpdate.
Цепочка доверия и структура иерархии центров
Валидация пути выполняется путём проверки подписей каждого сертификата вверх по цепочке до доверенной точки (trust anchor). Промежуточные CA используются для разграничения обязанностей и снижения риска компрометации корня. Ограничения по длине цепочки и политики отображаются в basicConstraints и certificatePolicies.
Процедуры выдачи, продления и отзыва сертификатов
Жизненный цикл включает подачу заявки, идентификацию, генерацию/приём ключевой пары, выпуск, публикацию и последующее продление или отзыв. Продление обычно требует повторной верификации в зависимости от типа сертификата и уровня уверенности; некоторые политики запрещают автоматическое продление без повторной идентификации.
Алгоритм идентификации и проверки заявок
Алгоритм начинается с получения CSR (PKCS#10), проверки соответствия формату, верификации предъявленных документов и соответствия заявленных атрибутов политике. Для повышенных уровней уверенности применяется личная проверка документов или использование средств дистанционной идентификации с двухфакторной аутентификацией. После успешной проверки центр подписывает сертификат и фиксирует операцию в журнале аудита.
Механизмы отзыва и причины для отзыва
Отзыв производится при компрометации закрытого ключа, утрате контроля над учётной записью, смене атрибутов субъекта или при прекращении действий. Причины отзыва регламентируются кодами CRLReason (например, keyCompromise) согласно RFC 5280. После обнаружения компрометации сертификат включается в CRL и/или помечается как отозванный в OCSP с немедленным эффектом.
Механизмы проверки статуса: OCSP и CRL
Проверка статуса необходима для подтверждения, что сертификат не был отозван после выпуска. Два основных механизма — CRL и OCSP — дополняют друг друга по свойствам и требованиям к инфраструктуре.
Принцип работы OCSP и его преимущества
OCSP обеспечивает ответ в реальном времени на запрос о статусе сертификата: ответы подписываются OCSP-ответчиком и содержат статусы good, revoked или unknown. OCSP описан в RFC 6960; ответы включают поля thisUpdate и nextUpdate. Преимущества: меньшая задержка обновления статуса и экономия трафика по сравнению с полными списками CRL; поддерживается механизм stapling в TLS.
Формат, периодичность и использование CRL
CRL — файл формата X.509 (DER/PEM), содержащий список серийных номеров отозванных сертификатов с датой отзыва и кодом причины, а также поле nextUpdate. Частота публикации CRL определяется политикой: от нескольких часов до суток для критичных служб, реже — для менее чувствительных применений. Размер CRL растёт с числом отозваний, что может повлиять на производительность при массовой проверке.
Требования к безопасности и защите ключей
Защита закрытых ключей критична для целостности PKI; требования охватывают аппаратные и организационные меры, резервирование и процедуры на случай инцидентов.
Аппаратные меры: HSM, резервирование, шифрование
Аппаратный модуль безопасности (HSM) выполняет генерацию и хранение ключей, криптооперации без возможности экспорта ключей в открытом виде; обычно применяются устройства с сертификацией FIPS 140-2 уровень 3 или выше. Практики резервирования включают создание резервных копий, защищённых шифрованием и разделением ключа (например, схемы распределённого хранения), многопартийное управление (M of N) для операций экспорта и регулярную проверку целостности.
Организационные меры: доступы, логирование, управление инцидентами
Организационные меры включают разграничение ролей, многофакторную аутентификацию для операторов, ведение неизменяемых журналов аудита, регулярные внутренние и внешние проверки соответствия. Политика управления инцидентами должна предусматривать сценарии уведомления сторон, процедуру немедленного отзыва при компрометации и план восстановления доверия.
Нормативные и правовые аспекты деятельности
Деятельность центров сертификации регулируется набором стандартов и правовых норм, а также внутренними политиками, формализованными в CP/CPS и аудируемыми внешними органами.
Требования к политике сертификации и соответствию стандартам
Политика сертификации (CP) и практический свод правил (CPS) оформляются в соответствии с рекомендациями RFC 3647 и должны содержать требования к процедурам идентификации, управлению ключами, срокам хранения журналов и критериям аудита. Распространённые стандарты соответствия включают RFC 5280, ETSI, WebTrust и региональные регламенты типа eIDAS для квалифицированных сертификатов.
Юридическая значимость сертификатов и доказательная база
Юридическая сила электронной подписи зависит от соответствия процедур выдачи и защиты ключей установленным требованиям. Для квалифицированных сертификатов предусмотрены дополнительные условия (например, использование сертифицированных устройств создания подписи), что даёт подписи предположение о юридической силе. Журналы операций, записи в реестрах и доказательства прохождения идентификации формируют доказательную базу при спорах и проверках.