Поделиться через

Изменения в проверке сертификата TLS-сервера в браузере Microsoft Edge

  • Статья

Примечание.

Microsoft Edge для бизнеса теперь доступен в стабильной версии 116 Edge! Узнайте больше о новом специализированном интерфейсе работы со встроенными встроенными средствами безопасности корпоративного уровня, производительностью, управляемостью и искусственным интеллектом.

Когда Microsoft Edge устанавливает подключения к HTTPS-серверу, Edge проверяет, что сервер предоставил сертификат, выданный сущностью, которой доверяет браузер. Это отношение доверия устанавливается через список доверия сертификатов , а компонент, отвечающий за выполнение проверок, называется проверяющим сертификатом.

В предыдущих версиях Microsoft Edge как список доверия сертификатов по умолчанию, так и логика проверки сертификатов предоставлялись базовой платформой операционной системы (ОС).

Для управляемых устройств, начиная с Microsoft Edge 112 в Windows и macOS, список доверия сертификатов по умолчанию и средство проверки сертификатов предоставляются браузером и поставляются вместе с ним. Этот подход отделяет список и проверятель от корневого хранилища операционной системы узла для поведения проверки по умолчанию. Дополнительные сведения о сроках изменения см. в разделе Временная шкала развертывания и руководство по тестированию .

Даже после изменения, в дополнение к доверию встроенным корням, которые поставляются с Microsoft Edge, браузер запрашивает базовую платформу (и доверяет) локально установленным корням, установленным пользователями и (или) предприятиями. В результате сценарии, в которых пользователь или предприятие установили больше корней в корневое хранилище операционной системы узла, должны продолжать работать.

Это изменение означает, что логика проверки сертификатов работает согласованно в Microsoft Edge в Windows и macOS. В будущем выпуске, который будет определен, развертывание также будет применяться к Linux и Android. Из-за политик Apple App Store предоставленное Apple корневое хранилище и средство проверки сертификатов по-прежнему используются в iOS и iPadOS.

Источник списка доверия сертификатов по умолчанию

Корневое хранилище, которое поставляется с Microsoft Edge в Windows и macOS, поступает из списка доверия сертификатов (CTL), определенного программой доверенных корневых сертификатов Майкрософт. Эта программа корневого сертификата определяет список, поставляемый с Microsoft Windows. В результате клиенты должны ожидать, что не будут отображаться изменения, видимые пользователем.

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

Обновления выпускаются по частоте, описанной в заметках о выпуске для доверенной корневой программы Майкрософт.

Руководство по временной шкале развертывания и тестированию

Начиная с Microsoft Edge 109, корпоративная политика (MicrosoftRootStoreEnabled) и флаг в edge://flags ("Microsoft Root Store") доступны для управления использованием встроенного корневого хранилища и средства проверки сертификатов.

Устройства, которые не управляются предприятием, начали получать эту функцию через управляемое развертывание компонентов (CFR) в Microsoft Edge 109 и достигли 100 % неуправляемых устройств в Edge 111. Дополнительные сведения см. в статье Конфигурации и эксперименты Microsoft Edge, в которой объясняется, как работают cfr в Microsoft Edge. Для устройств, управляемых предприятием, существующая реализация, предоставляемая платформой, использовалась через Microsoft Edge 111.

Начиная с Microsoft Edge 112, по умолчанию для всех устройств с Windows и macOS, включая управляемые предприятием, по умолчанию использовались реализация средства проверки и CTL, поставляемые вместе с браузером. Политика MicrosoftRootStoreEnabled по-прежнему доступна в этом выпуске, чтобы позволить предприятиям вернуться к предыдущему поведению при обнаружении непредвиденных проблем и сообщить о них корпорации Майкрософт.

Корпорация Майкрософт рекомендует предприятиям, у которых есть прокси-серверы безубыточности и проверки, или другие сценарии, включающие сертификаты tls-сервера, выданные корневителями, не в microsoft CTL, заблаговременно выявлять проблемы совместимости и сообщать корпорации Майкрософт о любых проблемах совместимости.

В Microsoft Edge 115 поддержка политики MicrosoftRootStoreEnabled удалена .

Известные различия в поведении локально доверенных сертификатов в Windows

Более строгое соответствие ТРЕБОВАНИЯМ RFC 5280

Новое встроенное средство проверки сертификатов более строго применяет требования RFC 5280 , чем старое средство проверки на основе платформы.

Примеры более строгого соответствия RFC 5280:

  1. Параметры алгоритма для алгоритмов ECDSA должны отсутствовать. Старое средство проверки будет игнорировать параметры, в то время как новый отклоняет сертификат. Дополнительные сведения см. в 1453441 проблем с Chromium .
  2. Ограничения имен, указывающие IP-адрес, должны содержать восемь октетов для IPv4-адресов и 32 октета для IPv6-адресов. Если в сертификате указан пустой IP-адрес, следует перевыпустить сертификат и полностью опустить ограничение имени IP-адреса.
  3. Ограничения имен с пустым списком "исключен" недопустимы. В средстве просмотра сертификатов Windows этот список отображается в Excluded=None виде сведений Name Constraints . Дополнительные сведения см. в 1457348 проблем с Chromium . Вместо указания пустого списка полностью опустите его.

Известные различия в поведении проверки отзыва в Windows

Помимо более строгих требований RFC 5280, новое средство проверки не поддерживает URI списка отзыва сертификатов на основе LDAP (CRL).

Если ваше предприятие включает политику RequireOnlineRevocationChecksForLocalAnchors , а списки отзыва сертификатов недопустимы для RFC 5280, в вашей среде могут появиться ERR_CERT_NO_REVOCATION_MECHANISM ошибки и (или ERR_CERT_UNABLE_TO_CHECK_REVOCATION ) ошибки.

При обнаружении ERR_CERT_NO_REVOCATION_MECHANISMнеобходимо убедиться, что список отзыва сертификатов по URI, указанному сертификатом, возвращает ответ в кодировке DER (не в кодировке PEM).

См. также