Изменения в проверке сертификата 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 Trusted Root Program.

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

Начиная с 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. Вместо указания пустого списка полностью опустите его.

Расширение "Политики приложений"

До Microsoft Edge 115 новое средство проверки не поддерживало поле расширения "политики приложений" только для Windows, описанное в документации по функции CertGetEnhancedKeyUsage. В Microsoft Edge 115 было внесено обновление, чтобы игнорировать расширение. Дополнительные сведения см. в Chromium 1439638 проблем.

Это расширение использует идентификатор объекта (OID). 1.3.6.1.4.1.311.21.10 Если сертификат включает это расширение и помечает его как критическое, подключение завершается сбоем с ERR_CERT_INVALID.

Для проверка, если этот сценарий относится к сертификату, можно использовать один из следующих способов:

  1. Сетевой журнал, захваченный с помощью about:net-export , включает строку ERROR: Unconsumed critical extension в со CERT_VERIFIER_TASK значением 2B060104018237150AOID .
  2. Откройте сертификат в средстве просмотра сертификатов Windows. В фильтре "Показать" выберите "Только критические расширения". Проверьте, присутствует ли поле "Политики приложений".
  3. Запустите certutil.exe с параметром -dump и просмотрите выходные данные проверка для критического поля расширения Политик приложений.

Если сертификат в настоящее время использует это расширение, убедитесь, что оно теперь работает в Microsoft Edge 115. Кроме того, можно повторно ввести сертификат и использовать только поле расширенного использования ключа (OID 2.5.29.37), чтобы указать допустимые варианты использования.

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

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

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

До Microsoft Edge 114 новый проверяющий элемент на основе Chromium применяет максимальный возраст "Базовые требования" для списков отзыва сертификатов. Для отзыва листьев текущий максимальный возраст составляет 7 дней, а для промежуточных отзывов текущий максимальный возраст составляет 366 дней. Проверка выполняется путем проверки того, что текущее время за вычетом значения "Это обновление" ("Дата вступления в силу") не превышает эти максимумы. В Microsoft Edge 114 эти требования больше не применяются для сертификатов, не являющихся общедоступными доверенными. Дополнительные сведения см. в разделе Chromium 971714 проблем.

Так как новое средство проверки загружает сведения об отзыве через сетевой стек браузера, также применяются обновления строгой транспортной безопасности HTTP (HSTS). Это обновление может создать несовместимость с требованием размещения сведений списка отзыва сертификатов по протоколу HTTP (а не HTTPS), если на узле настроен контакт HSTS. Если этот сценарий негативно сказывается на вашей среде, мы рекомендуем вам поделиться дополнительными сведениями о влиянии Chromium проблеме 1432246.

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

При возникновении ERR_CERT_UNABLE_TO_CHECK_REVOCATION ошибок следует убедиться, что издатель сертификата также является издателем списка отзыва сертификатов, поле сертификата cRLIssuer не задано, универсальный код ресурса (URI), в котором размещен список отзыва сертификатов, использует протокол HTTP и не находится на узле, настроенном для использования HSTS, и что список отзыва сертификатов был выдан достаточно недавно.

См. также