一行的用法并不完整，手册页也好不到哪儿去。
-clcerts and -cacerts真正的意思是：在输入中的证书中，仅当它们分别具有或不具有 LocalKeyID 时，才将它们包含在输出中，LocalKeyID 通常用于 EE 证书而不是 CA 证书（见下文）。这两者对私钥没有影响，私钥仅由-nokeys（以及与加密任何输出密钥相关的选项），所以-clcerts没有-nokeys将输出私钥和 with-LocalKeyID 证书，但不会输出任何 without-LocalKeyID 证书。由于这里的文件名为client-certificate这可能是不希望的；如果是的话，文件应该命名为client-key-and-cert.
（补充）详细：X.509 https://en.wikipedia.org/wiki/X.509 PKI https://en.wikipedia.org/wiki/Public_key_infrastructure架构定义了两个概念上不同的类别： 使用公钥密码学 https://en.wikipedia.org/wiki/Public-key_cryptography对于有用的东西，例如互联网通信、电子邮件或消息、程序或固件签名、护照等政府文件等，并且需要证书才能这样做；证书颁发机构 (CA)，它们共同受到信任，并且确实向 EE 及其自身颁发证书。如今，EE 证书不是由根（受信任）CA 直接颁发的，除了在有限的组织环境（或测试平台）中，EE 证书是由“中间”或“下级”CA 颁发的，这些 CA 拥有自己的证书通过根或通过更高级别的中间体，可能在到达根之前重复。 （实际上，1 中间是最常见的，2 是相当常见的，更多的是罕见但可能的。）要在此系统中安全地使用公钥，您需要 EE 证书及其上方（所有）中间 CA 的证书到，但不一定包括，根或“[信任]锚”，它形成一个“链”或“路径” https://www.rfc-editor.org/rfc/rfc5280#section-3.2那可以是已验证 https://www.rfc-editor.org/rfc/rfc5280#section-6.
EE 和 CA 证书是usually区别于基本约束扩展 https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.9和密钥使用扩展 https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3- 但不总是; PKIX 标准甚至不适用于所有 Internet 应用程序，更不用说外部应用程序了，而且即使在适用的地方，它们也并不总是得到完全遵守。 X.509 证书处理的许多实现最初是在 20 世纪 90 年代创建的，早于该标准的 v3 添加了扩展，并且在没有它们的情况下仍然可以运行。任何状况之下openssl pkcs12不使用此信息。
（EE）owner证书的证书通常需要匹配的私钥以及需要提供给依赖方（发送者、接收者、用户等）的“链”证书。 PKCS12（最初是 PFX）文件格式主要是为了处理这个问题而设计的；按照惯例PKCS12 文件包含私钥和匹配的证书，以及任何所需的链证书。然而，该规范更加灵活，并且可以存储私钥、证书以及有时其他信息的几乎任意组合。然而，一个约定是，当存在私钥和匹配的证书时，两者都由本地密钥ID属性 https://www.rfc-editor.org/rfc/rfc2985#page-18具有相同的值。放入文件中的与私钥不匹配的证书（通常但不一定是链证书）不具有此属性。
因此，在正常情况下，PKCS12 包含一个 EE 密钥和一个证书加链 (CA) 证书，或者不太常见的情况是几对 EE 密钥和所有证书加链 (CA) 证书，-clcerts选择 EE 证书（即使许多 EE 不是客户）并且-cacerts选择 CA 证书。但是，如果您有包含私钥和匹配证书的 PKCS12for a CA and its链证书（更高级别的 CA），这是完全合理的，-clcerts选择与私钥匹配的 CA 证书并-cacerts选择otherCA 证书。如果您有一个包含与私钥不匹配的“额外”证书的 PKCS12，-cacerts选择它（它们），即使它（它们）实际上是 EE 证书（并且-clcerts才不是）;例如，当您直接信任 EE 时，Java 会对信任库文件执行此操作，例如沟通同行。如果埃里克将这些选项拼写为类似的内容，可能会更清楚-owner-certs and -other-certs，但要改变这一点已经晚了 25 年。
PS：此命令不会生成任何内容。 PKCS12 已经包含私钥和证书，此命令只是将它们提取为不同的（可能更有用）的形式。无论您为生成密钥和证书所做的事情都是在此之前完成的。
