Office TLS 证书更改

项目
08/12/2023

Microsoft 365 正在更新为消息传送、会议、电话、语音和视频提供支持的服务，以使用来自另一组根证书颁发机构 (CA) 的 TLS 证书。之所以进行此更改，是因为当前根 CA 将于 2025 年 5 月过期。

受影响的产品包括：

Microsoft Teams
Skype
Skype for Business Online
Microsoft Dynamics 365
GroupMe
Kaizala
Azure 通信服务

受影响的终结点包括 (但不限于) ：

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

此外，Microsoft 365 美国政府版云实例中的 Teams 和 Skype for Business Online 终结点将进行相同的更改，从而影响终结点，例如：

*.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 年 10 月。

提示

如果你不是 E5 客户，请使用为期 90 天的 Microsoft Purview 解决方案试用版来探索其他 Purview 功能如何帮助组织管理数据安全性和合规性需求。立即从Microsoft Purview 合规门户试用中心开始。了解有关注册和试用条款的详细信息。

此更改何时发生？

服务于 2022 年 1 月开始过渡到新的根 CA，并将持续到 2022 年 10 月。

有何变化？

目前，Microsoft 365 服务使用的大多数 TLS 证书都链接到以下根 CA：

CA 的公用名	指纹 (SHA1)
Baltimore CyberTrust Root	d4de20d05e66fc53fe1a50882c78db2852cae474

使用以下中间 CA 之一：

CA 的公用名	指纹 (SHA1)
Microsoft RSA TLS CA 01	703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02	b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Microsoft 365 服务使用的新 TLS 证书现在将链接到以下根 CA 之一：

CA 的公用名	指纹 (SHA1)
DigiCert 全局根 G2	df3c24f9bfd666761b268073fe06d1cc8d4f82a4
Microsoft RSA 根证书颁发机构 2017	73a5e64a3bff8316ff0edccc618a906e4eae4d74
Microsoft ECC 根证书颁发机构 2017	999a64c37ff47d9fab95f14769891460eec4c3c5

使用以下中间 CA 之一：

CA 的公用名	指纹 (SHA1)
Microsoft Azure TLS 颁发 CA 01	2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS 颁发 CA 02	e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS 颁发 CA 05	6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS 颁发 CA 06	30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

例如，这是具有其中一个新证书链的有效证书：

Teams TLS 证书链

此更改会影响我吗？

根 CA“DigiCert 全局根 G2”受到 Windows、macOS、Android 和 iOS 等操作系统以及 Microsoft Edge、Chrome、Safari 和 Firefox 等浏览器的广泛信任。我们预计 大多数 Microsoft 365 客户不会受到影响。

但是， 如果应用程序显式指定可接受的 CA 列表，则应用程序可能会受到影响。这种做法称为“证书固定”。在其可接受的 CA 列表中没有新的根 CA 的客户将收到证书验证错误，这可能会影响应用程序的可用性或功能。

下面是检测应用程序是否受影响的一些方法：

在源代码中搜索此处找到的任何中间 CA 的指纹、公用名或其他属性。如果存在匹配项，则应用程序将受到影响。若要解决此问题，请更新源代码以添加新 CA 的属性。最佳做法是，确保可以在短时间内添加或编辑 CA。行业法规要求在某些情况下在七天内替换 CA 证书，因此实施证书固定的应用程序必须对这些更改做出迅速反应。
.NET 公开 System.Net.ServicePointManager.ServerCertificateValidationCallback 和 System.Net.HttpWebRequest.ServerCertificateValidationCallback 回调函数，这些函数允许开发人员使用自定义逻辑来确定证书是否有效，而不是依赖于标准 Windows 证书存储。开发人员可以添加用于检查特定公用名或指纹或仅允许特定根 CA（如“Baltimore CyberTrust Root”）的逻辑。如果应用程序使用这些回调函数，则应确保它同时接受新旧根 CA 和中间 CA。
本机应用程序可能使用 WINHTTP_CALLBACK_STATUS_SENDING_REQUEST，这允许本机应用程序实现自定义证书验证逻辑。此通知的用法很少见，需要大量的自定义代码才能实现。与上述方法类似，请确保应用程序同时接受新旧根 CA 和中间 CA。
如果你使用与 Microsoft Teams、Skype、Skype for Business Online 或 Microsoft Dynamics API 集成的应用程序，并且不确定它是否使用证书固定，检查应用程序供应商。
与 Azure 服务通信的不同操作系统和语言运行时可能需要其他步骤才能正确生成和验证新的证书链：
- Linux：许多分发版要求将 CA 添加到 /etc/ssl/certs。有关具体说明，请参阅分发的文档。
- Java：确保 Java 密钥存储包含上面列出的 CA。
- 在断开连接的环境中运行的 Windows：在断开连接的环境中运行的系统需要将新的根 CA 添加到其 Trusted Root Certification Authorities 存储区，并将新的中间 CA 添加到其 Intermediate Certification Authorities 存储区。
- Android：查看你的设备和 Android 版本的文档。
- IoT 或嵌入式设备：嵌入式设备（如电视机顶盒）通常附带有限的根颁发机构证书集，并且无法轻松更新证书存储。如果为自定义嵌入式设备或 IoT 设备编写代码或管理其部署，请确保设备信任新的根 CA。可能需要联系设备制造商。
如果防火墙规则允许仅对特定终结点进行出站调用，请允许以下证书吊销列表 (CRL) 或联机证书状态协议 (OCSP) URL：
- 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.

如果使用会话边界控制器，Microsoft 已准备了一个测试终结点，可用于验证 SBC 设备是否信任从新的根 CA 颁发的证书。此终结点应仅用于 SIP OPTIONS ping 消息，而不适用于语音流量。
```
Global FQDN: sip.mspki.pstnhub.microsoft.com 
Port: 5061
```
如果此操作无法正常运行，请联系设备制造商，以确定是否有更新可用于支持新的根 CA。

何时可以停用旧的 CA 信息？

当前根 CA、中间 CA 和叶证书不会吊销。根据现有证书的生存期，现有 CA 公用名称和/或指纹至少需要到 2023 年 10 月。

已知问题

在极少数情况下，企业用户可能会看到证书验证错误，其中根 CA“DigiCert 全局根 G2”显示为已吊销。这是由于以下两种情况下已知的 Windows bug 造成的：

根 CA 位于 CurrentUser\Root 证书存储中，缺少 NotBeforeFileTime 和 NotBeforeEKU 属性
根 CA 位于 LocalMachine\AuthRoot 证书存储中， NotBeforeFileTime 但同时具有和 NotBeforeEKU 属性
根 CA 不在 LocalMachine\Root 证书存储中

之后从此根 CA 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" 。

通过运行以下命令certutil并比较输出，可以确认存在具有不同NotBeforeFileTime属性的根 CA 的两个副本：

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

用户可通过执行以下操作删除证书存储中 CurrentUser\Root 根 CA 的副本来解决此问题：

certutil -user -delstore root DF3C24F9BFD666761B268073FE06D1CC8D4F82A4

或

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

第一种方法创建一个 Windows 对话框，用户必须单击该对话框，而第二种方法则不单击该对话框。