Azure 证书颁发机构详细信息

本文概述了 Azure 服务终结点使用的特定根证书颁发机构和从属证书颁发机构 (CA)。 请务必注意，此列表不同于 Azure VM 和托管服务上提供的信任定位点，后者利用了操作系统本身提供的信任定位点。 范围包括政府云和国家/地区云。 CA 详细信息表格下方提供了公钥加密和签名算法的最低要求、证书下载和吊销列表的链接，以及关键概念的相关信息。 此外，还提供了应添加到防火墙允许列表中的 URI 的主机名。

证书颁发机构详细信息

尝试通过 TLS/SSL 协议访问 Microsoft Entra 标识服务的任何实体都将获得本文中列出的 CA 提供的证书。 不同的服务可以使用不同的根或中间 CA。 以下根 CA 和从属 CA 与使用证书固定的实体相关。

如何解读证书详细信息：

• 序列号（表格顶部的字符串）包含证书序列号的十六进制值。
• 指纹（表格底部的字符串）是 SHA1 指纹。
• 以斜体格式列出的 CA 是最近添加的 CA。

公共 PKI 的客户端兼容性

Azure 使用的 CA 与以下操作系统版本兼容：

当 CA 过期或更改时，请查看以下操作步骤：

• 更新到要求的操作系统的受支持版本。
• 如果无法更改操作系统版本，则需要手动更新受信任的根存储以包含新的 CA。 请参阅制造商提供的文档。
• 如果场景包括禁用受信任的根存储或是在断开连接的环境下运行 Windows 客户端，请确保受信任的根 CA 存储中包含所有根 CA，并且中间 CA 存储中包含本文中列出的所有从属 CA。
• 许多 Linux 发行版要求将 CA 添加到 /etc/ssl/certs。 请参阅相应发行版的文档。
• 确保 Java 密钥存储包含本文中列出的 CA。 有关详细信息，请参阅本文的 Java 应用程序部分。
• 如果应用程序明确指定了可接受的 CA 列表，则请查看当 CA 更改或过期时是否需要更新已固定的证书。 有关详细信息，请参阅证书固定。

公钥加密和签名算法

需要支持以下算法、椭圆曲线和密钥大小：

签名算法：

• ES256
• ES384
• ES512
• RS256
• RS384
• RS512

椭圆曲线：

• P256
• P384
• P521

密钥大小：

• ECDSA 256
• ECDSA 384
• ECDSA 521
• RSA 2048
• RSA 3072
• RSA 4096

证书下载和吊销列表

可能需要在防火墙允许列表中包含以下域（HTTP/端口 80）以优化连接：

AIA：

• cacerts.digicert.com
• cacerts.digicert.cn
• cacerts.geotrust.com
• www.microsoft.com

CRL：

• crl3.digicert.com
• crl4.digicert.com
• crl.digicert.cn
• cdp.geotrust.com
• www.microsoft.com

OCSP：

• ocsp.digicert.com
• ocsp.digicert.cn
• oneocsp.microsoft.com
• status.geotrust.com

证书固定

证书固定是一种安全技术，实现在建立安全会话时，仅接受已授权或已固定的证书。 使用其他证书建立安全会话的任何尝试都会被拒绝。 了解证书固定的历史和含义。

如何解决证书固定问题

如果应用程序明确指定了可接受的 CA 列表，则当“证书颁发机构”更改或过期时需要定期更新已固定的证书。

建议采取以下步骤来检测证书固定：

• 如果你是应用程序开发人员，请在源代码中搜索有关此更改涉及的任何从属 CA 的证书指纹、主体可分辨名称、公用名、序列号、公钥和其他证书属性的引用。
  • 如果发现匹配项，请更新应用程序以包含缺少的 CA。
• 如果你的应用程序与 Azure API 或其他 Azure 服务集成，并且你不确定它是否使用证书固定，请向应用程序供应商核实。

Java 应用程序

若要确定 Java 应用程序是否信任 Microsoft ECC 根证书颁发机构 2017 和 Microsoft RSA 根证书颁发机构 2017 根证书，可以查看 Java 虚拟机 (JVM) 使用的受信任根证书列表。

1. 在系统中打开一个终端窗口。

2. 运行以下命令：

   keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts
   

   • $JAVA_HOME 引用 Java 主目录的路径。
   • 如果不确定路径，可以通过运行以下命令找到它：

   readlink -f $(which java) | xargs dirname | xargs dirname
   

3. 在输出中查找 Microsoft RSA 根证书颁发机构 2017。 结果应如下所示：

   • 如果 Microsoft ECC 根证书颁发机构 2017 和 Microsoft RSA 根证书颁发机构 2017 根证书受信任，则都应显示在 JVM 使用的受信任根证书列表中。
   • 如果不在列表中，则需要添加。
   • 输出应如以下示例所示：

       ...
       Microsoft ECC Root Certificate Authority 2017, 20-Aug-2022, Root CA,
       Microsoft RSA Root Certificate Authority 2017, 20-Aug-2022, Root CA,
       ...
   

4. 可以使用 keytool 实用工具向 Java 中受信任的根证书存储添加根证书。 以下示例添加的是 Microsoft RSA 根证书颁发机构 2017 根证书：

   keytool -import -file microsoft-ecc-root-ca.crt -alias microsoft-ecc-root-ca -keystore $JAVA_HOME/jre/lib/security/cacerts
   keytool -import -file microsoft-rsa-root-ca.crt -alias microsoft-rsa-root-ca -keystore $JAVA_HOME/jre/lib/security/cacerts
   

   注意

   在本示例中，microsoft-ecc-root-ca.crt 和 microsoft-rsa-root-ca.crt 分别是包含 Microsoft ECC 根证书颁发机构 2017 和 Microsoft RSA 根证书颁发机构 2017 的文件的名称。

以往的更改

CA/浏览器论坛更新了基线要求，要求公众信任的所有公钥基础结构 (PKI) 在 2022 年 5 月 31 日停止使用联机证书标准协议 (OCSP) 的 SHA-1 哈希算法。 Microsoft 已将所有使用 SHA-1 哈希算法的剩余 OCSP 响应方更新为使用 SHA-256 哈希算法。

2021 年 2 月 15 日，Microsoft 已将 Azure 服务更新为使用来自一系列不同根证书颁发机构 (CA) 的 TLS 证书，以符合 CA/浏览器论坛基线要求中规定的更改。 一些服务在 2022 年完成了这些更新。 有关托管 TLS 和 Azure 的最新信息，请参阅 托管 TLS 更改。

文章更改日志

• 2024 年 10 月 8 日：删除了以下 CA 和 CDP 终结点：crl.microsoft.com、mscrl.microsoft.com 和 ocsp.msocsp.com。

  证书颁发机构	序列号 指纹
  Baltimore CyberTrust 根	0x20000b9 D4DE20D05E66FC53FE1A50882C78DB2852CAE474
  Microsoft RSA TLS CA 01	0x0f14965f202069994fd5c7ac788941e2 703D7A8F0EBF55AAA59F98EAF4A206004EB2516A
  Microsoft RSA TLS CA 02	0x0fa74722c53d88c80f589efb1f9d4a3a B0C2D2D13CDD56CDAA6AB6E2C04440BE4A429C75
  DigiCert 云服务 CA-1	0f171a48c6f223809218cd2ed6ddc0e8 B3F6B64A07BB9611F47174407841F564FB991F29

• 2024 年 7 月 22 日：添加了来自一篇并行 Microsoft 365 文章的委托根证书颁发机构，以提供详尽的列表。

• 2024 年 6 月 27 日：删除了以下 CA，这些 CA 已由两个版本的 Microsoft Azure ECC TLS 发证 CA 03、04、07、08 取代。

  证书颁发机构	序列号 指纹
  Microsoft Azure ECC TLS 颁发 CA 01	0x09dc42a5f574ff3a389ee06d5d4de440 92503D0D74A7D3708197B6EE13082D52117A6AB0
  Microsoft Azure ECC TLS 颁发 CA 01	0x330000001aa9564f44321c54b900000000001a CDA57423EC5E7192901CA1BF6169DBE48E8D1268
  Microsoft Azure ECC TLS 颁发 CA 02	0x0e8dbe5ea610e6cbb569c736f6d7004b 1E981CCDDC69102A45C6693EE84389C3CF2329F1
  Microsoft Azure ECC TLS 颁发 CA 02	0x330000001b498d6736ed5612c200000000001b 489FF5765030EB28342477693EB183A4DED4D2A6
  Microsoft Azure ECC TLS 颁发 CA 05	x0ce59c30fd7a83532e2d0146b332f965 C6363570AF8303CDF31C1D5AD81E19DBFE172531
  Microsoft Azure ECC TLS 颁发 CA 05	0x330000001cc0d2a3cd78cf2c1000000000001c 4C15BC8D7AA5089A84F2AC4750F040D064040CD4
  Microsoft Azure ECC TLS 颁发 CA 06	0x066e79cd7624c63130c77abeb6a8bb94 7365ADAEDFEA4909C1BAADBAB68719AD0C381163
  Microsoft Azure ECC TLS 颁发 CA 06	0x330000001d0913c309da3f05a600000000001d DFEB65E575D03D0CC59FD60066C6D39421E65483
  Microsoft Azure TLS 颁发 CA 01	0x0aafa6c5ca63c45141ea3be1f7c75317 2F2877C5D778C31E0F29C7E371DF5471BD673173
  Microsoft Azure TLS 颁发 CA 01	0x1dbe9496f3db8b8de700000000001d B9ED88EB05C15C79639493016200FDAB08137AF3
  Microsoft Azure TLS 颁发 CA 02	0x0c6ae97cced599838690a00a9ea53214 E7EEA674CA718E3BEFD90858E09F8372AD0AE2AA
  Microsoft Azure TLS 颁发 CA 02	0x330000001ec6749f058517b4d000000000001e C5FB956A0E7672E9857B402008E7CCAD031F9B08
  Microsoft Azure TLS 颁发 CA 05	0x0d7bede97d8209967a52631b8bdd18bd 6C3AF02E7F269AA73AFD0EFF2A88A4A1F04ED1E5
  Microsoft Azure TLS 颁发 CA 05	0x330000001f9f1fa2043bc28db900000000001f 56F1CA470BB94E274B516A330494C792C419CF87
  Microsoft Azure TLS 颁发 CA 06	0x02e79171fb8021e93fe2d983834c50c0 30E01761AB97E59A06B41EF20AF6F2DE7EF4F7B0
  Microsoft Azure TLS 颁发 CA 06	0x3300000020a2f1491a37fbd31f000000000020 8F1FD57F27C828D7BE29743B4D02CD7E6E5F43E6

• 2023 年 7 月 17 日：添加了 16 个新的从属证书颁发机构。

• 2023 年 2 月 7 日：添加了 8 个新的从属证书颁发机构。

后续步骤

若要详细了解证书颁发机构和 PKI，请参阅：

• Microsoft PKI 存储库
• Microsoft PKI 存储库，包括 CRL 和策略信息
• Azure 防火墙高级版证书
• PKI 证书和配置管理器
• 保护 PKI