Изменения сертификата Office TLS

Microsoft 365 обновляет службы обмена сообщениями, собраний, телефонии, голосовой связи и видео, чтобы использовать сертификаты TLS из другого набора корневых центров сертификации (ЦС). Это изменение внесено, так как срок действия текущего корневого ЦС истекает в мае 2025 г.

Затронутые продукты:

  • Microsoft Teams
  • Skype
  • Skype для бизнеса Online
  • Microsoft Dynamics 365
  • Groupme
  • Kaizala
  • Службы коммуникации Azure

Затронутые конечные точки включают (но не ограничиваются ими):

  • *.teams.microsoft.com
  • *.skype.com
  • *.skypeforbusiness.com
  • *.groupme.com
  • *.communication.azure.com
  • *.operatorconnect.microsoft.com

Кроме того, Teams и Skype для бизнеса сетевые конечные точки в национальных облачных экземплярах Microsoft 365 для государственных организаций США внесет те же изменения, затрагивающие такие конечные точки, как:

  • *.gcc.teams.microsoft.com
  • *.dod.teams.microsoft.us
  • *.gov.teams.microsoft.us
  • *.online.dod.skypeforbusiness.us
  • *.online.gov.skypeforbusiness.us
  • *.um-dod.office365.us
  • *.um.office365.us

Это изменение не повлияет на сертификаты, домены или службы, используемые в национальных облачных экземплярах Microsoft 365 для Китая или Германии.

Все сведения о сертификатах, приведенные в этой статье, ранее были предоставлены в цепочках шифрования Microsoft 365 не позднее октября 2020 г.

Совет

Если вы не являетесь клиентом E5, используйте 90-дневную пробную версию решений Microsoft Purview, чтобы узнать, как дополнительные возможности Purview могут помочь вашей организации управлять безопасностью данных и соответствием требованиям. Начните сейчас, перейдя в центр пробных версий на портале соответствия требованиям Microsoft Purview. Сведения о регистрации и условиях пробной версии.

Когда произойдет это изменение?

Службы начали переход на новые корневые ЦС в январе 2022 г. и будут продолжаться до октября 2022 г.

Что меняется?

Сегодня большинство сертификатов TLS, используемых службами Microsoft 365, связаны со следующим корневым ЦС:

Общее имя ЦС Отпечаток (SHA1)
Baltimore CyberTrust Root d4de20d05e66fc53fe1a50882c78db2852cae474

с одним из следующих промежуточных ЦС:

Общее имя ЦС Отпечаток (SHA1)
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cd56cdaa6ab6e2c04440be4a429c75

Новые сертификаты TLS, используемые службами Microsoft 365, теперь будут связаны с одним из следующих корневых ЦС:

Общее имя ЦС Отпечаток (SHA1)
DigiCert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4
Корневой центр сертификации Microsoft RSA 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Корневой центр сертификации Microsoft ECC 2017 999a64c37ff47d9fab95f14769891460eec4c3c5

с одним из следующих промежуточных ЦС:

Общее имя ЦС Отпечаток (SHA1)
Microsoft Azure TLS, выдающий ЦС 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS, выдающий ЦС 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS, выдающий CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS, выдающий CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Например, это действительный сертификат с одной из новых цепочек сертификатов:

Цепочка сертификатов TLS Teams

Это изменение повлияет на меня?

Корневому ЦС DigiCert Global Root G2 доверяют операционные системы, включая Windows, macOS, Android и iOS, а также браузеры, такие как Microsoft Edge, Chrome, Safari и Firefox. Мы ожидаем, что большинство клиентов Microsoft 365 не будут затронуты.

Однако приложение может быть затронуто, если оно явно указывает список допустимых ЦС. Эта практика называется закреплением сертификата. Клиенты, у которых нет новых корневых ЦС в списке допустимых ЦС, получат ошибки проверки сертификатов, которые могут повлиять на доступность или функцию приложения.

Вот несколько способов определить, может ли это повлиять на ваше приложение:

  • Выполните поиск в исходном коде отпечатка, общего имени или других свойств любого из промежуточных ЦС, найденных здесь. Если совпадение имеется, это повлияет на ваше приложение. Чтобы устранить эту проблему, обновите исходный код, добавив свойства новых ЦС. Рекомендуется убедиться, что ЦС могут быть добавлены или изменены в кратчайшие сроки. Отраслевые правила требуют замены сертификатов ЦС в течение семи дней в некоторых случаях, поэтому приложения, реализующие закрепление сертификатов, должны быстро реагировать на эти изменения.

  • .NET предоставляет функции обратного System.Net.ServicePointManager.ServerCertificateValidationCallbackSystem.Net.HttpWebRequest.ServerCertificateValidationCallback вызова и , которые позволяют разработчикам использовать пользовательскую логику для определения допустимости сертификатов, а не полагаться на стандартное хранилище сертификатов Windows. Разработчик может добавить логику, которая проверяет наличие определенного общего имени или отпечатка, или разрешает только определенный корневой ЦС, например "Baltimore CyberTrust Root". Если приложение использует эти функции обратного вызова, убедитесь, что оно принимает старые и новые корневые и промежуточные ЦС.

  • Собственные приложения могут использовать WINHTTP_CALLBACK_STATUS_SENDING_REQUEST, что позволяет собственным приложениям реализовывать настраиваемую логику проверки сертификатов. Это уведомление используется редко, и для реализации требуется значительный объем пользовательского кода. Как и в описании выше, убедитесь, что приложение принимает как старые, так и новые корневые и промежуточные ЦС.

  • Если вы используете приложение, которое интегрируется с Microsoft Teams, Skype, Skype для бизнеса Online или API Microsoft Dynamics, и не знаете, используете ли оно закрепление сертификатов, проверка с поставщиком приложения.

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

    • Linux: для многих дистрибутивов требуется добавить ЦС в /etc/ssl/certs. Конкретные инструкции см. в документации по дистрибутиву.
    • Java: убедитесь, что хранилище ключей Java содержит перечисленные выше ЦС.
    • Windows, работающих в отключенных средах. В системах, работающих в отключенных средах, в хранилище Trusted Root Certification Authorities должны быть добавлены новые корневые ЦС, а в хранилище Intermediate Certification Authorities — новые промежуточные ЦС.
    • Android: ознакомьтесь с документацией по устройству и версии Android.
    • IoT или встроенные устройства. Встроенные устройства, такие как телевизоры, часто поставляются с ограниченным набором сертификатов корневого центра и не имеют простого способа обновить хранилище сертификатов. Если вы пишете код для пользовательских внедренных устройств или устройств Интернета вещей или управляете ими, убедитесь, что устройства доверяют новым корневым ЦС. Возможно, потребуется связаться с производителем устройства.
  • Если у вас есть среда, в которой правила брандмауэра разрешают исходящие вызовы только к определенным конечным точкам, разрешите следующие URL-адреса списка отзыва сертификатов (CRL) или протокола OCSP:

    • http://crl3.digicert.com
    • http://crl4.digicert.com
    • http://ocsp.digicert.com
    • http://crl.microsoft.com
    • http://oneocsp.microsoft.com
    • http://ocsp.msocsp.com
    • http://www.microsoft.com/pkiops
  • Если на вас повлияло это изменение, могут отображаться сообщения об ошибках в зависимости от типа среды, в которой вы работаете, и сценария, на который вы влияете. Проверьте журналы событий приложений Windows, журналы событий CAPI2 и пользовательские журналы приложений на наличие сообщений, которые выглядят следующим образом:

    An operation failed because the following certificate has validation errors:
    
    Subject Name: CN=teams.microsoft.com
    Issuer Name: CN=Microsoft Azure TLS Issuing CA 01, O=Microsoft Corporation, C=US
    
    Errors:
    
    The root of the certificate chain is not a trusted root authority.
    
  • Если вы используете пограничный контроллер сеансов, корпорация Майкрософт подготовила тестовую конечную точку, которую можно использовать для проверки того, что устройства SBC доверяют сертификатам, выданным из нового корневого ЦС. Эту конечную точку следует использовать только для сообщений связи SIP OPTIONS, но не для голосового трафика.

    Global FQDN: sip.mspki.pstnhub.microsoft.com 
    Port: 5061
    

    Если это не работает нормально, обратитесь к производителю устройства, чтобы определить, доступны ли обновления для поддержки нового корневого ЦС.

Когда можно снять с учета старые сведения о ЦС?

Текущий корневой ЦС, промежуточный ЦС и конечные сертификаты не будут отзываться. Существующие общие имена ЦС и (или) отпечатки потребуются по крайней мере до октября 2023 г. в зависимости от времени существования существующих сертификатов.

Известные проблемы

В очень редких случаях корпоративные пользователи могут столкнуться с ошибками проверки сертификатов, когда корневой ЦС "DigiCert Global Root G2" отображается как отозванный. Это связано с известной ошибкой Windows при обоих следующих условиях:

Все конечные сертификаты, выданные из этого корневого ЦС после, NotBeforeFileTime будут отображаться отозванными.

Администраторы могут определить и устранить проблему, проверив журнал CAPI2 на наличие этой ошибки:

Log Name:      Microsoft-Windows-CAPI2/Operational
Source:        Microsoft-Windows-CAPI2
Date:          6/23/2022 8:36:39 AM
Event ID:      11
Task Category: Build Chain
Level:         Error
[...]
        <ChainElement>
          <Certificate fileRef="DF3C24F9BFD666761B268073FE06D1CC8D4F82A4.cer" subjectName="DigiCert Global Root G2" />
          [...]
          <TrustStatus>
            <ErrorStatus value="4000024" CERT_TRUST_IS_REVOKED="true" CERT_TRUST_IS_UNTRUSTED_ROOT="true" CERT_TRUST_IS_EXPLICIT_DISTRUST="true" />
            <InfoStatus value="10C" CERT_TRUST_HAS_NAME_MATCH_ISSUER="true" CERT_TRUST_IS_SELF_SIGNED="true" CERT_TRUST_HAS_PREFERRED_ISSUER="true" />
          </TrustStatus>
          [...]
          <RevocationInfo freshnessTime="PT0S">
            <RevocationResult value="80092010">The certificate is revoked.</RevocationResult>
          </RevocationInfo>
        </ChainElement>
      </CertificateChain>
      <EventAuxInfo ProcessName="Teams.exe" />
      <Result value="80092010">The certificate is revoked.</Result>

Обратите внимание на наличие CERT_TRUST_IS_EXPLICIT_DISTRUST="true" элемента.

Вы можете проверить наличие двух копий корневого ЦС с разными NotBeforeFileTime свойствами, выполнив следующие certutil команды и сравнив выходные данные:

certutil -store -v authroot DF3C24F9BFD666761B268073FE06D1CC8D4F82A4
certutil -user -store -v root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

Пользователь может устранить проблему, удалив копию корневого ЦС в CurrentUser\Root хранилище сертификатов, выполнив следующие действия:

certutil -user -delstore root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

или

reg delete HKCU\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 /f

Первый подход создает диалоговое окно Windows, которое пользователь должен щелкнуть, а второй — нет.