“最终实体”在X.509（以及，RFC 5280）中定义为：

 end entity: user of PKI certificates and/or end user system that is
             the subject of a certificate;

但是该表达式在路径验证的上下文中确实有意义：“EE”证书之所以这么称呼，是因为当它出现在证书路径中时，它必然位于路径的末尾。从这个意义上说，“EE 证书”是不包含Basic Constraints extension或包含cA标志等于的扩展的证书FALSE。

现在，您可以通过将 CA 证书放在路径的末尾来验证它，在这种情况下，该证书虽然属于证书颁发机构，但可以暂时成为“最终实体证书”，具体取决于您如何解释该表达式。关系走向另一个方向：根据路径验证算法（特别是第6.1.4节，步骤 (k)），为了使证书能够出现在除末端以外的任何位置的有效路径中，它必须是“CA 证书”（这里的意思是“带有基本约束扩展且cA标志设置为的证书TRUE）。

这回答了您的问题：如果证书不是“CA 证书”（如“证书标记为 'CA'”，而不是“由也是证书颁发机构的组织拥有的证书”），那么它可能是仅用作验证路径中的“最终实体”。

（或者，换一种说法：不要试图在一些定义不明确的术语中阅读太多。在实践中，重要的是实现做什么，即路径验证算法。）

所有非 CA 证书都必须是最终实体证书吗？

是的。根据RFC 5280，第 3.2 节，这是一个非此即彼的事情：

X.509 v3 also includes an extension that identifies the subject of a
certificate as being either a CA or an end entity, reducing the
reliance on out-of-band information demanded in PEM.

This specification covers two classes of certificates: CA
certificates and end entity certificates.  CA certificates may be
further divided into three classes: cross-certificates, self-issued
certificates, and self-signed certificates. 

另外：这里有类似的问题：接收证书的组织是否在 PKI 中被视为“最终实体”？

X.509 证书是旨在保存信息的文档，这些信息被证明是关键安全信息的准确、未更改的副本。验证者通常是相互信任的第三方。该信息包含几个重要的值，但现在您只需要了解一些：证书所属组织的名称、该组织的公钥、指示允许使用该公钥的操作的字段、签名者/签名者的身份/身份，以及签名本身。

认证由签名机构的某人完成，评估信息是否真实地来自证书上指定的组织，然后通过散列证书的位（使用 SHA、MD5 或其他散列算法）来证明它，然后加密该散列 -使用签名机构的超级秘密私钥摘要值。这会产生签名。任何拥有签名机构公钥的人都可以使用它来验证文档的其余部分没有被更改。

操作系统和浏览器制造商信任签名机构提供“自签名”证书 - 由机构本身签名的证书。这些证书具有签名机构的名称、它们的公钥和一个表明它只能用于验证签名的字段。这些称为受信任的根证书，颁发它们的组织称为证书颁发机构 (CA)。

当组织想要让用户加密他们的流量时，他们会创建一个证书签名请求 (CSR)。CSR 有他们的名字、他们的公钥和一个标志，表明这个公钥仅用于加密加密密钥。他们将 CSR 发送给他们的 CA，CA（收费）验证它来自合法来源，然后签署他们的请求，生成证书。

有时 CA 不会使用其根密钥直接签署每个证书。这在企业级安装中很常见。相反，根证书签署了一个不同的证书，该证书的标志设置为“验证签名”。此辅助证书是“工作”证书，用于创建日常操作中使用的数千个其他证书（电子邮件用户证书、Web 服务器场证书、客户端证书等）。这些证书称为从属证书当局（CSA）。对于一个非常大的组织来说，拥有一个专门用于签署电子邮件证书的 CSA、一个不同的 CSA 签署内部 Web 服务器证书以及一个不同的签署客户端计算机证书的情况并不少见。这种整体架构被称为公钥基础设施 (PKI)。

答案是否定的。我们确实拥有既不是根 CA 也不是最终实体的中间证书颁发机构。

使用中间 CA 的目的主要是为了安全。出于安全原因，通常根 CA 保存在同一位置。根 CA 签署中间 CA，中间 CA 签署最终实体。

可以有多个中间 CA。

根CA | | 中级 CA | | 最终实体证书。