为什么“openssl pkcs12 -in keystore.p12 -out client-certificate.pem -clcerts -nokeys”需要 -nokeys

Question

我正在使用 openssl 生成客户端证书和密钥，稍后将在与 cUrl 的相互身份验证中使用这些证书和密钥。

我正在使用以下命令生成客户端证书。

openssl pkcs12 -in keystore.p12 -out client-certificate.pem -clcerts -nokeys

根据文档：

-clcerts 只输出客户端证书。

我的问题是，因为-clcerts是only output client certificates为什么我们需要把nokeys一次吗？谢谢

Answer 1

单行用法并不完整，手册页也好不到哪里去。

-clcerts和-cacerts真正的意思：在输入中的证书中，它们包括在仅当它们分别或不具有LocalKeyID，这通常是本用于EE证书而不是一个CA证书（见下文）的输出。这两者都对私钥没有影响，私钥仅由-nokeys（以及与加密任何输出密钥相关的选项）控制，因此-clcertswithout-nokeys将同时输出私钥和 with-LocalKeyID 证书，但不会输出任何 without-LocalKeyID 证书. 由于此处的文件已命名，client-certificate因此可能不需要；如果是这样，文件应该命名为client-key-and-cert.

（已添加）详细说明：X.509 PKI体系结构定义了两个概念上不同的类别：使用公钥加密的终端实体 (EE)对于互联网通信、电子邮件或消息、程序或固件签名、护照等政府文件等有用的东西，需要证书才能这样做；和证书颁发机构 (CA)，共同信任并确实向 EE 和他们自己颁发证书。如今，EE 证书不是由根（受信任的）CA 直接颁发，除非在有限的组织环境（或测试平台）中，而是由“中间”或“从属”CA 颁发的 EE 证书拥有自己的证书通过根或更高级别的中间体，可能在到达根之前重复。（在实践中，1 中间是最常见的，2 是相当常见的，更多是罕见但可能的。可以验证的“链”或“路径”。

EE 和 CA 证书通常由BasicConstraints 扩展和KeyUsage 扩展来区分——但并非总是如此；PKIX 标准甚至不适用于所有 Internet 应用程序，更不用说外部应用程序了，即使在它们适用的情况下，它们也不总是完全遵守。X.509 证书处理的许多实现最初是在 1990 年代创建的，在该标准的 v3 添加扩展之前，并且在没有它们的情况下仍然可以运行。在任何情况下openssl pkcs12都不会使用这些信息。

证书的 (EE)所有者通常需要匹配的私钥和需要提供给依赖方（发送者、接收者、用户等）的“链”证书。PKCS12（最初是 PFX）文件格式主要是为了处理这个问题而设计的；通常，PKCS12 文件包含一个私钥和匹配的证书，以及任何需要的链证书。但是，该规范更加灵活，并且可以存储私钥、证书以及有时其他信息的几乎任何组合。但是，一种约定是当私钥和匹配的证书存在时，两者都由LocalKeyID 属性标记具有相同的值。放入与私钥不匹配的文件中的证书，通常但不一定是链式证书，不具有此属性。

因此，在正常情况下，PKCS12 包含一个 EE 密钥和证书加链 (CA) 证书，或者不太常见的情况下，所有这些证书都包含几对 EE 密钥和证书加链 (CA) 证书，-clcerts选择 EE 证书（即使许多 EE 不是客户端）并-cacerts选择 CA 证书。但是，如果有一个包含专用密钥和匹配证书一个PKCS12为CA和其链证书（S）（上一级CA（S）），这是完全合理的，-clcerts选择该专用密钥和相匹配的CA证书-cacerts选择其他CA 证书。如果您有一个包含与私钥不匹配的“额外”证书的 PKCS12，则-cacerts选择它（它们），即使它（它们）实际上是 EE 证书（和-clcerts才不是）; 例如，当您直接信任 EE（例如通信对等点）时，Java 会为信任库文件执行此操作。如果 Eric 将这些选项拼写为-owner-certs和 之类的内容可能会更清楚-other-certs，但要改变它已经晚了 25 年。

PS：此命令不会生成任何内容。PKCS12 已经包含私钥和证书，此命令只是将它们提取为不同的（可能更有用）形式。无论您为生成密钥和证书做了什么，都在此之前完成。