您已经发展到基本正确，但是要添加几点并扩展@CoverosGene'的答案，这比我在编辑中感到自在的要多：
X.509在 ASN.1 中定义了一个证书（以及其他一些与此处不相关的内容），这是一种（非常！）通用的数据结构化方法，它具有多种定义的编码，其中
DER可分辨编码表示非常常见，并在此处使用。
PEM格式——对于证书只是其中一种的几种类型的数据——就像你所说的那样，只是以 base64 编码的二进制（DER）数据（编辑）通常每 64 个字符分成几行（但有变化），加上由破折号 + BEGIN 或 END + 数据类型组成的标题和尾行，在本例中为 CERTIFICATE + 破折号。这些行对人类来说看起来是多余的，但它们是预期的，并且主要是软件所需要的。PEM（隐私增强邮件）实际上是一个完整的安全电子邮件标准，除了它的编码格式之外，它现在几乎被遗忘了（见下文）。
（编辑）截至 2015 年，RFC 7468详细描述了现代加密数据中“PEM”格式的大多数使用。
PKCS#7由 RSA（公司，而不是算法）定义为加密和/或签名数据的多用途格式。它被移交给 IETF 并演变为
RFC 2630中的CMS 加密消息语法，然后是RFC 3369，然后是RFC 3852，然后是RFC 5652，因此是 Windows (inetopt) 提示符的措辞。“PKCS#7”通常用于表示原始
RSA PKCS#7 和 IETF 后继 CMS，就像“SSL”通常用于原始 Netscape 协议和 IETF 后继 TLS 传输级别安全性一样。
.p7b 或 .p7c格式是 PKCS#7/CMS 的一种特殊情况：SignedData 结构不包含“内容”和零个 SignerInfo，但包含一个或多个证书（通常）和/或 CRL（很少）。早在这提供了一种标准方法来处理（编辑）组成链所需的证书集（不一定按顺序）。
PKCS#7/CMS 也是（是？）ASN.1 并且根据情况可以是 DER 或BER，这是一种密切相关的编码，具有大多数 DER 解码器处理的一些非常小的差异。
虽然像任何 DER 或 BER 对象一样的 PKCS#7/CMS都可以是 PEM 格式的，但除了 openssl （编辑）之外，我还没有看到任何实现，证书很少见。（JavaCertificateFactory只能从 DER 或 PEM 读取 PKCS7/CMS-certs，但CertPath.getEncoded只能将其写入 DER。）相比之下，单个证书的 DER 和 PEM 格式都很常见。
PKCS#7/CMS 也用作S/MIME安全电子邮件的基础（从 5751 开始的多个 rfcs）。基本上，PEM 将 PKCS#7 编码为 1980 年代电子邮件系统可以轻松处理的 ASCII 文本，而 S/MIME 将 CMS 表示为 MIME 实体，这些实体以现代电子邮件系统可以处理的多种方式编码。
OpenSSL通过按顺序实现来混淆问题：处理 certs-CRLs-only 情况而不是完整 PKCS#7的pkcs7命令；实际处理 CRL 和证书的crl2pkcs7命令，但同样不是 PKCS#7 的其余部分；一个smime命令，它实际上处理 S/MIME 和 PKCS#7/CMS 对于大多数加密和/或签名消息的情况；和一个cms命令，它实际上处理 S/MIME 和 PKCS#7/CMS 以获得更完整的案例集。
因此，我将选项描述为：PEM 或 DER 格式的证书；PKCS#7 容器中的（单个）证书或简称为 p7，仅在适用的极少数情况下提及 PEM；或 PKCS#7 或 p7 中的证书链。单个证书和证书链之间的语义差异至少与证书本身或容器中的格式差异一样重要。
这甚至没有达到证书本身（对于某些其他实体，通常是 CA 根或锚）与您用来证明自己的私钥 PLUS 证书（或通常是链）的组合之间的广泛混淆身份，例如作为 SSL/TLS 服务器或在签署 S/MIME 电子邮件时。它使用最初的 Microsoft PFX 个人信息交换格式，或其标准化形式 PKCS#12 或“p12”。