Введение
HTTPS (через SSL /TLS) использует шифрование с открытым ключом для защиты сообщений браузера от чтения или изменения при передаче через Интернет. Серверы предоставляют посетителям браузера открытый ключ, который используется для установления зашифрованного соединения для всех последующих обменов данными.
Тем не менее, просто получая работает один только открытый ключ не гарантирует, что он (и, соответственно, сервер) действительно принадлежит правильному удаленному предмет (т. е. лицо, компания или организация). Человек-в-середине злоумышленники могут манипулировать сетями для обслуживания своих собственных ключей, тем самым подвергая риску любую связь
Браузеры предотвращают это аутентификации HTTPS-серверы, использующие сертификаты, которые являются цифровыми документами, которые связывать открытый ключ к отдельному субъекту. Привязка подтверждается наличием доверенного сертификата.орган по выдаче сертификатов (CA), такие как SSL.com проверять личность потенциальных владельцев сертификатов с помощью автоматических и ручных проверок соответствующих баз данных.
Эти доверительные отношения означают, что безопасность веб-пользователей не является абсолютной; скорее, она требует от пользователей доверия к браузерам и центрам сертификации для защиты своей безопасности. Поэтому в интересах каждого пользователя иметь базовое представление о том, как работает проверка сертификатов.
Обратите внимание, что процесс проверки сертификата (подробно описанный в стандартном документе) RFC 5280) довольно запутанный. В этой статье мы попытаемся провести вас по одному пути (браузер, проверяющий SSL хоста /TLS сертификат) и перемещаться мимо сложных деталей, которые несущественны для большинства пользователей.
Примечание: По состоянию на август 2024 года RFC 9618, документ IETFобновил алгоритм проверки ограничений политики в цифровых сертификатах X.509 из RFC 5280.
Сертификаты и формат X.509
Сертификаты — это цифровые файлы во всех отношениях, а это значит, что для хранения информации (например, подписей, ключей, эмитентов и т. д.) они должны соответствовать определённому формату. В то время как частные PKI конфигурации могут реализовывать любой формат для своих сертификатов, пользующихся всеобщим доверием PKI(т.е. те, которым доверяют браузеры) должны соответствовать RFC 5280, который требует использования Х.509 v3 формат.
X.509 v3 позволяет сертификатам включать дополнительные данные, такие как ограничения использования или информацию о политике, как линийс каждым расширением либо критической or не критичный. Если клиент сталкивается с нераспознанным некритическим расширением, он может его проигнорировать. Если расширение критическое и нераспознанное или не может быть обработано, сертификат должен быть отклонён.
Пути сертификации и обработка пути
Центры сертификации используют закрытый ключ для криптографической подписи всех выданных сертификатов. Такие подписи могут криптографически доказать, что сертификат был выдан определенным центром сертификации и что он не был изменен после подписания.
Центры сертификации устанавливают права собственности на свой подписывающий ключ, имея сертификат, выданный самостоятельно (называемый корень) для соответствующего открытого ключа. Центры сертификации должны соблюдать строго контролируемые и проверяемые процедуры для создания, управления и использования корня, и чтобы минимизировать риск, они обычно используют корень для выдачи промежуточный сертификаты. Эти посредники затем могут быть использованы для выдачи сертификатов своим клиентам. Сертификат корневого центра сертификации является самоподписанным, а его закрытый ключ защищен строгими процедурами. Выдача сертификатов обычно осуществляется через посредников, а не напрямую от корневых центров.
Браузеры поставляются со встроенным списком доверенных корней. (Это корни из центров сертификации, которые прошли строгие критерии включения браузера.) Чтобы проверить сертификат, браузер получит последовательность сертификатов, каждый из которых подписал следующий сертификат в последовательности, соединяя корень подписывающего CA с сервером. сертификат.
Эта последовательность сертификатов называется путь сертификации. Корень пути называется доверять якорь а сертификат сервера называется лист or конечный объект сертификат.
Путь Строительство
Веб-браузеры и программные клиенты в целом часто могут создавать несколько потенциальных якорей доверия (например, из-за перекрёстных подписей) и часто извлекать недостающие промежуточные элементы через AIA для завершения цепочки. Даже если путь может содержать сертификаты, которые правильно «цепляются» к известному якорю, сам путь может быть отклонён из-за ограничений по длине пути, доменному имени, использованию сертификатов или политике.
Создание и оценка всех возможных путей - это дорогостоящий процесс, выполняемый для каждого нового сертификата, с которым сталкивается браузер. Браузеры реализовали различные оптимизации, чтобы минимизировать количество отклоненных возможных путей, но углубление в такие детали выходит далеко за рамки этой статьи.
Проверка пути
После создания пути сертификации кандидата браузеры проверяют его, используя информацию, содержащуюся в сертификатах. Путь действителен, если браузеры могут криптографически доказать, что, начиная с сертификата, непосредственно подписанного якорем доверия, соответствующий закрытый ключ каждого сертификата использовался для выдачи следующего в пути, вплоть до конечного сертификата.
Базовые требования требуют, чтобы имена субъекта и эмитента были все возможные пути be байт в байт идентичны, что упрощает надежное построение пути.
Алгоритм валидации пути сертификации
Как отмечалось ранее, по состоянию на август 2024 г. RFC 9618, документ IETFобновил алгоритм проверки ограничений политики в цифровых сертификатах X.509 из RFC 5280. По сути, браузеры перебирают все сертификаты на пути, начиная с якоря доверия (т. е. корневого сертификата), проверяя основную информацию каждого сертификата и критические расширения.
Если процедура завершается с последним сертификатом в пути без ошибок, то путь считается допустимым. Если возникают ошибки, путь помечается как неверный.
Основная обработка сертификата
Независимо от каких-либо расширений, браузеры должны всегда проверять основную информацию о сертификате, такую как подпись или издатель. В следующих разделах показана последовательность проверок, выполняемых браузерами.
1. Браузер проверяет целостность сертификата.
подпись На сертификате можно проверить с помощью обычной криптографии с открытым ключом. Если подпись недействительна, то сертификат считается измененным после его выдачи и поэтому отклоняется.
2. Браузер проверяет действительность сертификата.
Сертификат срок годности это интервал времени, в течение которого подписывающий центр сертификации гарантирует, что он будет хранить информацию о своем статусе. Браузеры отклоняют любые сертификаты с периодом действия, заканчивающимся до или начинающимся после даты и времени проверки.
3. Браузер проверяет статус отзыва сертификата.
Ожидается, что после выдачи сертификата он будет использоваться в течение всего срока его действия. Конечно, различные обстоятельства могут привести к тому, что сертификат станет недействительным до истечения срока его действия.
Такие обстоятельства могут включать изменение имени субъекта или предполагаемую компрометацию его закрытого ключа. В таких случаях ЦС должен отозвать соответствующий сертификат, и пользователи также доверяют ЦС, чтобы уведомить браузеры о статусе отзыва своих сертификатов.
Списки отзыва сертификатов (CRL)
Списки отозванных сертификатов (CRL) стали отраслевым стандартом для проверки отзыва сертификатов с 2024 года. Центры сертификации периодически выпускают подписанные списки отозванных сертификатов с отметкой времени, которые браузеры могут загружать и кэшировать локально.
Хотя ранее списки отзыва сертификатов считались менее эффективными, чем методы проверки в режиме реального времени, отрасль признала значительные преимущества, которые делают их предпочтительным подходом:
- Улучшенная конфиденциальность: CRL защищают конфиденциальность пользователей, устраняя необходимость запрашивать у внешних серверов информацию о конкретных сертификатах, что может раскрыть шаблоны просмотра.
- Операционная эффективность: Центры сертификации могут эффективнее управлять отзывом сертификатов без необходимости поддерживать высокодоступные службы реагирования в режиме реального времени
- Снижение затрат на инфраструктуру: Устранение необходимости в круглосуточных специалистах OCSP значительно снижает эксплуатационные расходы
- Лучшее кэширование: Современные браузеры могут эффективно кэшировать и обновлять списки отзыва сертификатов, сводя к минимуму проблемы с задержками, которые ранее были обусловлены методами реального времени.
По состоянию на март 2024, Форум CA/Browser требует от всех публично доверенных центров сертификации предоставлять списки отзыва сертификатов, при этом другие методы отзыва являются необязательнымиНекоторые крупные центры сертификации прекратили предоставление альтернативных услуг по отзыву сертификатов, перейдя на подходы, основанные исключительно на CRL.
Протокол статуса сертификата онлайн (OCSP)
Протокол статуса онлайн-сертификата (OCSP), описанный в RFC 6960, Был разработан для обеспечения проверки отзыва сертификатов в режиме реального времени, позволяя браузерам запрашивать серверы OCSP (ответчики) о конкретных сертификатах. Хотя OCSP получил широкое распространение в 2010-х годах как усовершенствование по сравнению с периодической загрузкой списков отзыва сертификатов, отрасль в значительной степени отказалась от этого подхода.
- OCSP теперь не является обязательным для публично доверенных центров сертификации (с марта 2024 года). Важность OCSP заключается в следующем: отказ; например, Давайте зашифровать удалил URL-адреса OCSP в мае 2025 года и закрыл службы реагирования Август 2025.
- В некоторых браузерах отключена проверка OCSP или она реализована способами, обеспечивающими минимальные преимущества в плане безопасности.
OCSP Stapling: Вариант, называемый OCSP Stapling остается полезным в некоторых сценариях, где серверы включают ответы OCSP непосредственно в TLS Рукопожатие, позволяющее избежать отдельных клиентских запросов к серверам-ответчикам OCSP. Однако это требует особой настройки сервера. Сшивание поддерживается большинством серверов/CDN, но его эффективность снижается по мере того, как крупные центры сертификации отказываются от поддержки OCSP.
Как это на самом деле работает сегодня в браузерах: С 15 марта 2024 года форум CA/B требует от публично доверенных центров сертификации (CA) публиковать списки отзыва сертификатов (CRL), в то время как OCSP является необязательным. Современные браузеры, как правило, не запрашивают OCSP и не загружают CRL для каждого сайта. Вместо этого они используют агрегированные механизмы, построенные на основе опубликованных CA списков отзыва сертификатов: CRLSets в Chrome и CRLite в Firefox предоставляют клиентам быстрые и конфиденциальные данные об отзыве. В результате роль OCSP в общедоступном интернете снижается; например, Let's Encrypt удалил URL-адреса OCSP в мае 2025 года и отключил службы OCSP Responders в августе 2025 года.
4. Браузер проверяет эмитента
Сертификаты обычно связаны с двумя объектами:
- эмитент, который является лицом, владеющим ключом подписи и
- предмет, который ссылается на владельца открытого ключа, который подтверждает подлинность сертификата.
Клиенты проверяют, что каждый сертификат на пути подписан открытым ключом предыдущего сертификата и что имена эмитента/субъекта точно совпадают на всем пути. Для дополнительной безопасности большинство PKI Реализации также проверяют, совпадает ли ключ издателя с ключом, подписавшим текущий сертификат. (Обратите внимание, что это не относится к якорю доверия, поскольку корни выдаются самостоятельно, т. е. у них один и тот же издатель и субъект.)
Обработка ограничений
Формат X.509 v3 позволяет ЦС определять ограничения или ограничения на проверку каждого сертификата и его использование в качестве критических расширений. Каждый сертификат в пути может налагать дополнительные ограничения, которым должны подчиняться все последующие сертификаты.
Ограничения сертификатов редко влияют на обычного пользователя Интернета, хотя они довольно часто встречаются в корпоративных решениях SSL. Функциональные ограничения могут служить нескольким рабочим целям, но их наиболее важное использование - смягчение известных проблем безопасности.
5. Браузер проверяет ограничения имени
Частный (но пользующийся всеобщим доверием) промежуточный ЦС с соответствующим ограничения имени Может предоставить организации детальный контроль над управлением и выдачей сертификатов. Сертификаты могут быть ограничены определенным доменом или деревом доменов (включая поддомены) для доменного имени компании или организации. Ограничения по имени часто используются для сертификатов промежуточных центров сертификации, приобретаемых у публично доверенного центра сертификации, чтобы предотвратить выдачу промежуточным центром сертификации абсолютно действительных сертификатов для сторонних доменов (например, google.com).
6. Браузер проверяет ограничения политики
Политика сертификатов - это юридический документ, опубликованный центром сертификации, в котором подробно описываются процедуры, которым они следуют при выдаче и управлении своими сертификатами. Центры сертификации могут выдавать сертификат в соответствии с одной или несколькими политиками, и ссылки на них включены в каждый выпущенный сертификат, чтобы проверяющие стороны могли оценить эти политики, прежде чем принять решение о доверии этому сертификату.
По юридическим и эксплуатационным причинам сертификаты могут накладывать ограничения на политику, которой они могут подвергаться. Если сертификат содержит критические ограничения политики, браузеры должны проверить их, прежде чем продолжить. (Однако критические политические ограничения редко встречаются в реальном мире и поэтому будут игнорироваться до конца этой статьи.)
7. Браузер проверяет основные ограничения (длина пути)
Формат X.509 v3 позволяет издателям определять максимальную длину пути, которую может поддерживать сертификат. Это обеспечивает контроль над тем, как далеко каждый сертификат может быть помещен в путь сертификации. Это действительно важно - браузеры игнорировали длину пути сертификации, пока исследователь не продемонстрировал в 2009 г. presentation, как он использовал листовой сертификат своего веб-сайта, чтобы подделать действительный сертификат для крупного веб-сайта электронной коммерции.
8. Браузер проверяет использование ключа
Расширение «использование ключа» указывает назначение ключа, содержащегося в сертификате. Примеры таких целей включают шифрование, подписи, подписание сертификата и так далее. Браузеры отклоняют сертификаты, нарушая ограничения их использования ключа, например обнаруживая сертификат сервера с ключом, предназначенным только для подписи CRL.
9. Браузер продолжает обрабатывать все оставшиеся критические расширения
После обработки упомянутых выше расширений браузеры приступают к проверке всех оставшихся расширений, которые текущий сертификат определяет как критические, прежде чем перейти к следующему. Если браузер достигает конечного сертификата пути без ошибок, то путь считается действительным. Если возникают какие-либо ошибки, путь помечается как недопустимый и безопасное соединение не устанавливается.
Современное управление сертификатами: сокращение срока действия и автоматизация
SSL /TLS За последние годы отрасль претерпела ряд изменений, кардинально изменивших порядок выдачи и управления сертификатами. Понимание этих изменений крайне важно для PKI менеджеры, ИТ-специалисты и/или любые другие лица, работающие с цифровыми сертификатами.
Сокращенные сроки действия сертификатов
В апреле 2025 года Форум CA/Browser принял знаменательное решение (Бюллетень SC-081v3) для значительного сокращения сроков действия сертификатов поэтапно:
- Текущий (до марта 2026 г.): Максимум 398 дней (приблизительно 13 месяцев)
- 15 марта 2026: Максимум 200 дней
- 15 марта 2027: Максимум 100 дней
- 15 марта 2029: Максимум 47 дней
Изменения в проверке контроля домена (DCV)
Наряду со сроком действия сертификатов сокращается и период повторного использования информации о проверке домена:
- Март 2026: максимальное повторное использование в течение 200 дней
- Март 2027: максимальное повторное использование в течение 100 дней
- Март 2029: максимальное повторное использование в течение 10 дней
Это означает, что организациям придется гораздо чаще подтверждать право собственности на домен, что делает автоматизацию необходимым условием практического управления сертификатами.
Почему эти изменения важны
Преимущества безопасности:
- Более короткий срок действия сертификата уменьшает окно риска в случае компрометации ключей.
- Более частая проверка гарантирует, что право собственности на домен остается актуальным
- Более быстрое внедрение улучшений безопасности в Интернете
Операционное воздействие:
- Ручное управление сертификатами становится практически невозможным
- Организации должны внедрить автоматизированное управление жизненным циклом сертификатов
- Требуются более частые процедуры проверки домена
Требования к автоматизации
Эти изменения делают автоматизацию сертификации не просто полезной, а необходимой. Организациям следует серьезно рассмотреть следующие вопросы:
- Осуществлять ACME (среда автоматического управления сертификатами) или аналогичные протоколы
- Развертывание решения по управлению жизненным циклом сертификатов
- Подготовьте инфраструктуру к частым обновлениям и проверкам
- Подготовьтесь к переходу на более короткие сроки действия сертификатов
Интеграция прозрачности сертификатов
Современные браузеры всё чаще требуют или проверяют журналы прозрачности сертификатов (Certificate Transparency, CT), которые предоставляют общедоступные и проверяемые записи обо всех выданных сертификатах. Это помогает обнаружить:
- Неправильно выданные сертификаты
- Несанкционированная выдача сертификатов
- Проблемы соответствия требованиям CA
Заключение
Цифровой ландшафт остается сложной системой взаимосвязанных компонентов, и безопасность браузеров продолжает оставаться активной областью разработки, которая включает в себя:
- Более короткий срок действия сертификатов: К 47 году отрасль стремится к 2029-дневному сроку действия сертификатов, что делает автоматизацию необходимым условием для практического управления сертификатами.
- Изменения в методе отзыва: Переход от OCSP к CRL отражает приоритеты отрасли в области конфиденциальности пользователей и эффективности работы.
- Более строгий надзор со стороны CA: Браузеры стали более агрессивно требовать соответствия требованиям и лишать доверия неэффективные центры сертификации.
Эти изменения представляют собой фундаментальный переход к более автоматизированному, конфиденциальному и ориентированному на безопасность управлению сертификатами. Организациям следует уже сейчас начать готовиться к сокращению срока действия сертификатов и автоматизированным процессам продления.
Доверие продолжает играть важную роль в обеспечении безопасности пользователей в Интернете. Мы рекомендуем вам быть в курсе этих меняющихся стандартов и проверять политики и историю соответствия вашего центра сертификации. Как показывают эти изменения, экосистема сертификации активно адаптируется для повышения безопасности и защиты конфиденциальности.
Для получения самой актуальной информации о передовых методах управления сертификатами и подходе SSL.com к этим изменениям в отрасли посетите наш страница сравнения сертификатов.
Спасибо за выбор SSL.com, где, как мы полагаем, безопаснее Интернет это better Интернет.
