Жизненный цикл и отзыв сертификатов

Каждый цифровой сертификат проходит определённый жизненный цикл — от создания до вывода из эксплуатации. Этапы таковы: Request and Enrollment (создание пары ключей, формирование CSR), Issuance (CA проверяет данные и подписывает сертификат), Deployment (установка на сервер или устройство), Use (период активной эксплуатации), Renewal (до окончания срока действия) и Revocation or Expiry (завершение жизненного цикла). Управление этим жизненным циклом в большом масштабе — особенно в организациях с тысячами сертификатов — требует автоматизации и инструментов управления жизненным циклом сертификатов (CLM), поскольку ручное отслеживание неизбежно приводит к просроченным сертификатам и сбоям в работе.

Жизненный цикл сертификата начинается с Certificate Signing Request (CSR). Запрашивающая сторона создаёт пару ключей, затем формирует CSR, содержащий открытый ключ и сведения о Subject (CN, O, C), и подписывает его закрытым ключом, доказывая владение закрытым ключом без его раскрытия. CSR передаётся в CA, который проверяет личность запрашивающей стороны и, если запрос одобрен, подписывает сертификат. Закрытый ключ никогда не покидает владение запрашивающей стороны. Создание CSR — критически важный этап, на котором определяется стойкость ключа: следует использовать RSA длиной не менее 2048 бит или ECC длиной 256 бит.

Сертификаты необходимо продлевать до истечения даты notAfter. Рекомендуется начинать процесс продления как минимум за 30 дней до окончания срока действия (многие организации ориентируются на 60–90 дней). Обычно продление включает создание нового CSR и закрытого ключа, отправку запроса в CA и замену старого сертификата и ключа на всех серверах, где они развёрнуты. Let's Encrypt автоматизирует этот процесс с помощью протокола ACME: инструмент certbot автоматически продлевает сертификаты, когда до окончания их срока действия остаётся менее 30 дней. Просроченные сертификаты вызывают ошибки браузера, из-за которых пользователи не могут получить доступ к службам.

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

Certificate Revocation List (CRL) — это подписанный список, публикуемый CA и содержащий серийные номера всех отозванных им сертификатов, срок действия которых ещё не истёк. Клиенты загружают CRL, сохраняют его в кэше и проверяют, присутствует ли серийный номер предъявленного сертификата в списке. У CRL есть существенные ограничения: списки могут быть очень большими (у крупных CA — миллионы отозванных сертификатов), клиенты часто хранят их в кэше часами или днями, что приводит к задержкам, а загрузка полного CRL для каждого соединения неэффективна. CRL по-прежнему используются, но всё чаще дополняются или заменяются OCSP.

OCSP (Online Certificate Status Protocol) обеспечивает проверку отзыва сертификата в реальном времени, не требуя от клиентов загружать целиком CRL. Клиент отправляет запрос обработчику OCSP CA, указывая серийный номер сертификата. Обработчик отвечает подписанным ответом, сообщающим, что сертификат действителен, отозван (с датой и причиной отзыва) или имеет статус неизвестен. OCSP работает быстрее и предоставляет более актуальные сведения, чем CRL, но для каждого TLS-соединения требуется дополнительный обмен данными по HTTP с обработчиком OCSP, что увеличивает задержку. Ответы OCSP подписываются CA для предотвращения подделки.

OCSP Stapling решает проблему задержки при проверке OCSP в реальном времени. Вместо того чтобы при каждом рукопожатии TLS запрашивать ответчик OCSP у CA, сервер заранее получает собственный ответ OCSP от CA и «прикрепляет» его к рукопожатию TLS. Клиент получает свежий ответ OCSP, подписанный CA, непосредственно от сервера — дополнительный обмен данными не требуется. Сервер периодически обновляет прикреплённый ответ OCSP, обычно раз в час. OCSP Stapling ускоряет установление соединения и снижает нагрузку на ответчики OCSP центра сертификации, сохраняя возможность проверки отзыва сертификата.

OCSP Must-Staple — это расширение X.509, которое сообщает браузерам, что сервер обязан предоставить прикреплённый ответ OCSP. Без него браузеры используют режим «мягкого отказа», если проверка OCSP завершается ошибкой: они всё равно разрешают соединение, чтобы сбой ответчика OCSP не блокировал все соединения TLS. Злоумышленник может воспользоваться таким поведением, блокируя запрос OCSP клиента и создавая впечатление, что certificate всё ещё действительно даже после отзыва. OCSP Must-Staple предотвращает это, требуя корректный прикреплённый ответ; без него браузер отклоняет соединение. Распространение этого механизма остаётся ограниченным из-за сложности внедрения.

Отзыв сертификата и закрепление сертификата решают одну и ту же проблему — доверие к поддельным сертификатам, — но делают это по-разному. Отзыв (CRL/OCSP) — реактивный механизм: CA аннулирует certificate после обнаружения проблемы. Закрепление — проактивный механизм: приложение отклоняет любой сертификат, кроме предварительно одобренного. Закрепление обеспечивает более сильную защиту, чем отзыв, поскольку работает даже в том случае, если CA не отозвал certificate своевременно, но делает развёртывание менее гибким. Для экзамена Security+ необходимо знать оба механизма и понимать, что отзыв — стандартный механизм PKI, а закрепление — необязательная мера эшелонированной защиты.

Когда certificate отзывается, CA назначает ему код причины отзыва, который помогает клиентам и администраторам понять причину. Распространённые коды причин, определённые в RFC 5280, включают: keyCompromise (закрытый key был скомпрометирован), cACompromise (выдавший сертификат CA был скомпрометирован), affiliationChanged (организация субъекта изменилась), superseded (выдан новый сертификат взамен прежнего), cessationOfOperation (домен больше не используется) и privilegeWithdrawn (полномочие отозвано). Код причины указывается и в записях CRL, и в ответах OCSP, предоставляя контекст командам реагирования на инциденты, расследующим события отзыва.

Протокол ACME (Automatic управление сертификатами Environment), используемый Let's Encrypt, автоматизирует весь жизненный цикл сертификатов. Клиенты ACME, такие как certbot, автоматически запрашивают, обновляют и развёртывают сертификаты без участия человека. CA использует проверочные задания владения доменом, чтобы подтвердить право владения доменом: задание HTTP-01 требует разместить определённый файл по известному URL, а задание DNS-01 — создать запись DNS TXT. ACME преобразовал управление сертификатами: 90-дневные сертификаты Let's Encrypt теперь обеспечивают значительную долю HTTPS-трафика в интернете и автоматически обновляются.

Проверьте своё понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.

В этом уроке Вы узнали, что жизненный цикл certificate проходит этапы от создания CSR до выпуска, развёртывания и обновления или отзыва; CRL предоставляет списки отозванных сертификатов пакетами, а OCSP — сведения о статусе каждого сертификата в реальном времени; OCSP Stapling устраняет задержку при использовании OCSP в реальном времени; а ACME (Let's Encrypt) автоматизирует весь жизненный цикл обновления. Далее мы рассмотрим варианты применения PKI.