我有一个带有 HTTPS 的服务器，我注意到一个我无法理解的非常奇怪的行为。
当我在Firefox中检查链时，有这样的：
但是在Chrome中我看到了这个：
所以很明显，路径是不同的（链中的 4 对 5 项）。更详细地说，证书“受信任的根 CA SHA256 G2”似乎有一个不同的父证书。
当我使用portecle检查链条时，链条中还有 5 件物品。
我的问题是：链是基于CN/DN构建的吗？虽然这只是一个名字，但它似乎很弱......有人知道差异来自哪里吗？
编辑：感谢马尔科的问题，我意识到我没有强调的一件重要的事情，对不起。
在这两个链中，有证书“GlobalSign”，这似乎是正确的，但在 Firefox 链中，证书的序列号是，04:00:00:00:00:01:21:58:53:08:A2但在 Chrome 的链中，具有相同别名的证书有序列号04 00 00 00 00 01 25 07 1d f9 af，所以关心的是， “受信任的根 CA SHA256 G2”证书具有不同的父证书。
可能是 Firefox 和 Chrome 决定信任不同级别的证书。Chrome 信任“GlobalSign Root CA”，并将证书一直链接到 root 以检查其有效性，但 FireFox 信任“Trusted Root CA SHA256 G2”，它不需要检查所有到 root 来告诉你如果该浏览器信任它。因此，如果两个浏览器都返回该链是有效的，那应该没问题。链是建立在父证书签名子一个上的，签名验证只能判断路径是否有效。希望这可以帮助！
编辑：嗯，证书别名不是唯一的，所以一个 CA 可以为他们的许多证书使用相同的名称。例如，与我合作的一个 CA 使用多个具有相同别名的中间证书在不同时间段内颁发客户端证书。所以在这种情况下，它们将具有相同的别名，相同的根，都有效，但仍然具有不同的序列号或到期时间或其他。因此，证书使用什么别名或序列号并不重要，只是它们都链接到您选择信任的一个根证书。在这种情况下，可能有许多相同名称的链都通向 GlobalSign 根，如果您信任该根，并且该签名链是有效的，那么通往它的路径并不重要。希望这对您的担忧有所帮助。
GlobalSign 具有三个活动的根 CA，其中两个具有简单 GlobalSign 的 CommonName，尽管如果您查看详细信息，其他名称组件会有所不同。
Root-R1：CN = GlobalSign 根 CA，OU = 根 CA，O = GlobalSign nv-sa，C = BE
有效 1998/09/01 至 2028/01/28
sha1 指纹 b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d 82 9c
Root-R2：CN = GlobalSign，O = GlobalSign，OU = GlobalSign 根 CA - R2
有效 2006/12/15 至 2021/12/15
sha1 指纹 75 e0 ab b6 13 85 12 27 1c 04 f8 5f dd de 38 e4 b7 24 2e 铁
Root-R3：CN = GlobalSign，O = GlobalSign，OU = GlobalSign 根 CA - R3
有效 2009/03/18 至 2029/03/18
sha1 指纹 d6 9b 56 11 48 f0 1c 77 c5 45 78 c1 09 26 df 5b 85 69 76 广告
请注意，在 SSL 和 HTTPS 启动后不久，R1 就一直在使用，但 R2 和 R3 明显更新。（他们还发布了 R4 R5 R6 以供将来使用。）
您的服务器显然使用的（非私有）中间证书由 R3 颁发给：
CN = 可信根 CA SHA256 G2，O = GlobalSign nv-sa，OU = 可信根，C = BE
有效 2014/04/25 至 2027/04 /25
sha1 指纹 9a bb 55 a2 6f 9c 06 d5 00 c4 59 91 f0 2c 15 b5 5d 00 a7 02
您可能会检查该指纹以确保我们正在查看相同的内容。
除了自己的根证书外，每个根 CA 还可以拥有其他CA 颁发给它的证书；通常这些被称为“cross-CA”或只是“cross”证书并且可以用于多种目的。特别是当一个已建立的 CA 运营商创建或获取一个新根时，他们通常会发布一个“桥”证书，在旧根下验证新根-CA 的名称和密钥，以便已经信任的验证器（浏览器等） （在下颁发的证书）旧根也将信任在新根下颁发的证书，而无需等待验证者的信任库使用新根更新，这可能需要几个月到多年甚至永远不会。相反，新根可能会“重新验证”旧根，因此如果创建或修改验证器以仅支持具有 SHA-2 或 SHA-3 或 Super Radiant Frabjosity 等浮华特性的新根，它仍然会接受使用现有且完全可服务但无亮点的证书链的同行。
SSL/TLS客户端（包括 HTTPS 浏览器）尤其不限于在握手中发送的服务器证书链，它可以构建和使用它从服务器（叶）证书选择的任何有效信任链到它信任的根。匹配是在完整的主题/发行人名称上完成的，即“专有名称”，而不仅仅是 CommonName；即使如此，也很容易出于恶意和意外地重复名称。这不是“弱”，因为子证书上的签名必须在父密钥下进行验证，除非合法 CA 的密钥被泄露，否则无法伪造，这不应该发生，或者有人可以破解当前使用的密码学尺寸（RSA 2048）需要比太阳系中更多的物质和能量。
GlobalSign 网站，在 R2 下发布的 ExtendedSSL 中间体页面上（在我看来，它可能是在 R2 下发布的第一件事，因此是第一个面临这个问题的）描述并提供了 R1 到 R2 交叉证书。我在网站上没有看到任何关于 R1-to-R3 的信息，但是透明度日志中crt.sh有三个，而
这个有你发布的序列号；检查那个指纹和你看到的指纹。
但如果你指的是 Windows 上的 Chrome，我的两台 Windows 机器（8.1 和 Vista）确实有 R3（指纹从 d6 9b 开始）。您可能会查看您的根存储（在 Internet 选项/内容/证书/TrustedRoots 中，或在 MMC 管理单元中以方便地获得证书certmgr.msc），以查看此证书是否存在，或者只有 R1。如果您指的是另一个平台但没有说哪个平台，我相信 Chrome 总是使用平台信任库，所以它取决于平台，可能还取决于版本/更新。如果它确实有两个根，则允许选择其中一个，但我想我已经观察到它选择较短的一个。（另一方面，Firefox 在所有平台上都使用自己的信任库，我的 38esr 有 GlobalSign R1 R2 R3和R4 R5和 几个中间体。）