任何 CA都可以是“中间 CA”。因为“中间人”是由验证者如何看待它来定义的。

当您验证证书时，您将验证颁发该证书的 CA 在该证书上生成的签名。此签名根据 CA 公钥进行验证。如果您“固有地”知道 CA 公钥（例如，它是随操作系统分发的 CA 公钥之一），那么 CA 就是一个信任锚，也称为根CA。另一方面，如果您仅通过验证 CA 证书（由另一个CA 颁发给该 CA 的证书）知道 CA 公钥，则该 CA 被视为“中间”。可以将“中间”这个名称视为描述 CA 在信任链中的位置：信任锚在开头，最终实体在结尾（呃！），中间的任何内容都是“

我可以为任何 CA 颁发证书，即使没有他们的同意或意识，只需获取证书内容并使用我自己的密钥对其进行签名即可。这意味着这个星球上的每一个 CA 都可能是一个中间 CA。

CA 可以将签名权限委托给另一个“中间”CA，并且根据依赖方使用的路径验证规则，这可能与原始 CA 一样受到信任。

这可能是个问题，尤其是因为您信任的根存储中可能有很多 CA。请参阅以下参考中的成绩单的第 20 页左右：

“……世界各国政府能够合法地强制其国家 SSL 证书颁发机构颁发中间 CA 证书，这些证书允许这些政府的机构秘密拦截、解密和监控安全的 SSL 连接……”——
Steve Gibson，Security Now 第 243 集“State Subversion” SSL”。

这仍然需要访问实际流量，但是有多种方法可以让一个坚定的对手经常实现这一点。

与 DNSSEC 的情况形成对比，DNSSEC 有一个单一的根，与子域关联的密钥只能保证关联的子域。

有关该问题的一些复杂性和可能的​​未来解决方案，请参阅例如ImperialViolet - DNSSEC 和 TLS，以允许排除 CA 错误或恶意颁发的证书，并避免在没有 CA 证书的情况下对站点进行 MITM .