为什么 "openssl pkcs12 -in keystore.p12 -out client-certificate.pem -clcerts -nokeys" 需要 -nokeys
why "openssl pkcs12 -in keystore.p12 -out client-certificate.pem -clcerts -nokeys" need -nokeys
我正在使用 openssl 生成客户端证书和密钥，稍后将在与 cUrl 的相互身份验证中使用。
我正在使用以下命令生成客户端证书。
openssl pkcs12 -in keystore.p12 -out client-certificate.pem -clcerts -nokeys
根据 documentation:
-clcerts only output client certificates.
我的问题是，既然 -clcerts 是 only output client certificates，为什么我们需要再次输入 nokeys？谢谢
使用说明并不完整，手册页也好不到哪里去。
-clcerts 和 -cacerts 的真正意思是：在输入的证书中，仅当它们分别有或没有 LocalKeyID 时才将它们包含在输出中，LocalKeyID 通常存在于EE 证书而不是 CA 证书（见下文）。这两者都对私钥没有影响，私钥仅由 -nokeys 控制（以及与加密任何输出密钥相关的选项），因此没有 -nokeys 的 -clcerts 将同时输出私钥和with-LocalKeyID 证书，但不是任何 without-LocalKeyID 证书。由于这里的文件被命名为 client-certificate 这大概是不需要的；如果是，则文件应命名为 client-key-and-cert.
（已添加）详细说明：X.509 PKI architecture defines two notionally-distinct categories: End-Entities (EEs) who use public-key cryptography for something(s) useful like Internet communications, email or messages, program or firmware signing, government documents like passports, etc and need certificates to do so; and Certificate Authorities (CAs), which collectively are trusted to, and do, issue certificates to EEs and themselves. Nowadays EE certs are not issued directly by a root (trusted) CA, except maybe in a limited organizational environment (or a testbench), but rather the EE certs are issued by 'intermediate' or 'subordinate' CAs which have their own certs issued either by the root or by a higher-level intermediate, possibly repeating before reaching a root. (In practice 1 intermediate is most common, 2 is fairly common, more is rare but possible.) To securely use a public key in this system you need the EE cert and the certs of (all) the intermediate CA(s) above it to, but not necessarily including, the root or '[trust] anchor', which form a 'chain' or 'path' that can be validated.
EE 和 CA 证书通常 由 BasicConstraints extension and the KeyUsage extension 区分——但并非总是如此； PKIX 标准甚至不适用于所有 Internet 应用程序，更不用说外部应用程序了，即使在适用的地方也并不总是完全遵守。许多 X.509 证书处理的实现最初是在 1990 年代创建的，在该标准的 v3 添加扩展之前，并且在没有它们的情况下仍然可以运行。在任何情况下 openssl pkcs12 都不会使用此信息。
证书的 (EE) 所有者 通常需要匹配的私钥以及它需要提供给依赖方的 'chain' 证书（发件人、收件人、用户等）。 PKCS12（最初是 PFX）文件格式主要是为了处理这个问题而设计的； 通常 PKCS12 文件包含私钥和匹配的证书，以及任何需要的链证书。然而，规范更加灵活，几乎可以存储私钥、证书和有时其他信息的任何组合。但是，一个约定是当存在私钥和匹配的证书时，两者都由具有相同值的 LocalKeyID attribute 标记。放在文件中的与私钥不匹配的证书，通常但不一定是链证书，没有此属性。
因此，在正常情况下，PKCS12 包含一个 EE 密钥和证书加链 (CA) 证书，或者不太常见的情况是几对 EE 密钥和证书加链 (CA) 证书对于所有这些，-clcerts 选择 EE 证书（即使许多 EE 不是客户端）并且 -cacerts 选择 CA 证书。但是，如果您的 PKCS12 包含 CA 的私钥和匹配证书 和 its 链证书（更高级别的 CA( s))，这是完全合理的，-clcerts 选择与私钥匹配的 CA 证书，-cacerts 选择 other CA 证书。如果您有一个包含 'extra' 个与私钥不匹配的证书的 PKCS12，-cacerts 会选择它（它们），即使它（它们）实际上是 EE 证书（并且-clcerts 没有）；例如，当您直接信任 EE 时，Java 会为信任库文件执行此操作，例如沟通同行。如果 Eric 将这些选项拼写成 -owner-certs 和 -other-certs 之类的拼写可能会更清楚，但现在改变它已经 25 年太晚了。
PS：此命令未生成任何内容。 PKCS12 已经包含私钥和证书，此命令只是将它们提取为不同的（可能更有用的）形式。无论您为生成密钥和证书做了什么，都在此之前完成了。
我正在使用 openssl 生成客户端证书和密钥，稍后将在与 cUrl 的相互身份验证中使用。
我正在使用以下命令生成客户端证书。
openssl pkcs12 -in keystore.p12 -out client-certificate.pem -clcerts -nokeys
根据 documentation:
-clcerts only output client certificates.
我的问题是，既然 -clcerts 是 only output client certificates，为什么我们需要再次输入 nokeys？谢谢
使用说明并不完整，手册页也好不到哪里去。
-clcerts 和 -cacerts 的真正意思是：在输入的证书中，仅当它们分别有或没有 LocalKeyID 时才将它们包含在输出中，LocalKeyID 通常存在于EE 证书而不是 CA 证书（见下文）。这两者都对私钥没有影响，私钥仅由 -nokeys 控制（以及与加密任何输出密钥相关的选项），因此没有 -nokeys 的 -clcerts 将同时输出私钥和with-LocalKeyID 证书，但不是任何 without-LocalKeyID 证书。由于这里的文件被命名为 client-certificate 这大概是不需要的；如果是，则文件应命名为 client-key-and-cert.
（已添加）详细说明：X.509 PKI architecture defines two notionally-distinct categories: End-Entities (EEs) who use public-key cryptography for something(s) useful like Internet communications, email or messages, program or firmware signing, government documents like passports, etc and need certificates to do so; and Certificate Authorities (CAs), which collectively are trusted to, and do, issue certificates to EEs and themselves. Nowadays EE certs are not issued directly by a root (trusted) CA, except maybe in a limited organizational environment (or a testbench), but rather the EE certs are issued by 'intermediate' or 'subordinate' CAs which have their own certs issued either by the root or by a higher-level intermediate, possibly repeating before reaching a root. (In practice 1 intermediate is most common, 2 is fairly common, more is rare but possible.) To securely use a public key in this system you need the EE cert and the certs of (all) the intermediate CA(s) above it to, but not necessarily including, the root or '[trust] anchor', which form a 'chain' or 'path' that can be validated.
EE 和 CA 证书通常 由 BasicConstraints extension and the KeyUsage extension 区分——但并非总是如此； PKIX 标准甚至不适用于所有 Internet 应用程序，更不用说外部应用程序了，即使在适用的地方也并不总是完全遵守。许多 X.509 证书处理的实现最初是在 1990 年代创建的，在该标准的 v3 添加扩展之前，并且在没有它们的情况下仍然可以运行。在任何情况下 openssl pkcs12 都不会使用此信息。
证书的 (EE) 所有者 通常需要匹配的私钥以及它需要提供给依赖方的 'chain' 证书（发件人、收件人、用户等）。 PKCS12（最初是 PFX）文件格式主要是为了处理这个问题而设计的； 通常 PKCS12 文件包含私钥和匹配的证书，以及任何需要的链证书。然而，规范更加灵活，几乎可以存储私钥、证书和有时其他信息的任何组合。但是，一个约定是当存在私钥和匹配的证书时，两者都由具有相同值的 LocalKeyID attribute 标记。放在文件中的与私钥不匹配的证书，通常但不一定是链证书，没有此属性。
因此，在正常情况下，PKCS12 包含一个 EE 密钥和证书加链 (CA) 证书，或者不太常见的情况是几对 EE 密钥和证书加链 (CA) 证书对于所有这些，-clcerts 选择 EE 证书（即使许多 EE 不是客户端）并且 -cacerts 选择 CA 证书。但是，如果您的 PKCS12 包含 CA 的私钥和匹配证书 和 its 链证书（更高级别的 CA( s))，这是完全合理的，-clcerts 选择与私钥匹配的 CA 证书，-cacerts 选择 other CA 证书。如果您有一个包含 'extra' 个与私钥不匹配的证书的 PKCS12，-cacerts 会选择它（它们），即使它（它们）实际上是 EE 证书（并且-clcerts 没有）；例如，当您直接信任 EE 时，Java 会为信任库文件执行此操作，例如沟通同行。如果 Eric 将这些选项拼写成 -owner-certs 和 -other-certs 之类的拼写可能会更清楚，但现在改变它已经 25 年太晚了。
PS：此命令未生成任何内容。 PKCS12 已经包含私钥和证书，此命令只是将它们提取为不同的（可能更有用的）形式。无论您为生成密钥和证书做了什么，都在此之前完成了。