Java 密钥库中的中间 CA 证书
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/19453523/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Intermediate CA certificate in Java keystore
提问by Jay
My Dev OPs team would like to make use of an Intermediate CA certificate in our Java keystore. I believe adding an intermediate certificate into the keystore is the same process as as adding a "regular cert", correct? Are there any "gotchas" I need to be aware of? Also, how do I verify in testing that Java is using the intermediate cert as opposed to checking back with the CA?
我的 Dev OP 团队希望在我们的 Java 密钥库中使用中间 CA 证书。我相信将中间证书添加到密钥库与添加“常规证书”的过程相同，对吗？有什么我需要注意的“陷阱”吗？另外，我如何在测试中验证 Java 是否使用中间证书，而不是向 CA 核对？
回答by Paul Wagland
To answer your questions in order:
要按顺序回答您的问题：
I believe adding an intermediate certificate into the keystore is the same process as as adding a "regular cert", correct?
我相信将中间证书添加到密钥库与添加“常规证书”的过程相同，对吗？
Yes. For example, see this VMWare documentation on installing intermediate CA's.
是的。例如，请参阅有关安装中间 CA 的 VMWare 文档。
Are there any "gotchas" I need to be aware of?
有什么我需要注意的“陷阱”吗？
Only that every intermediate CA needs it's own alias.
只是每个中间 CA 都需要它自己的别名。
Also, how do I verify in testing that Java is using the intermediate cert as opposed to checking back with the CA?
另外，我如何在测试中验证 Java 是否使用中间证书，而不是向 CA 核对？
If you just want to verify that it does not check the root CA, then just don't install it, and you know that it can't be used.
如果你只是想验证它不检查根CA，那么就不要安装它，你知道它不能使用。
Update: In response to the comment from @Bruno, it is fair to point out that this answer only addresses the issues raised in the question. I am assuming here that the issues around trust and certificate distribution, the normal reasons for having intermediate CA's in the first place, have been dealt with, and that this is the desired solution. For more information on those issues, you should look at Bruno's answer.
更新：为了回应@Bruno 的评论，公平地指出这个答案只解决了问题中提出的问题。我在这里假设围绕信任和证书分发的问题，首先拥有中间 CA 的正常原因，已经得到处理，并且这是所需的解决方案。有关这些问题的更多信息，您应该查看布鲁诺的回答。
回答by Bruno
You need to reason in terms of certificate chain. The goal of intermediate CA certificates is to let the remote party build a chain between the End-Entity Certificate (e.g. the server or the client certificate itself) and another CA certificate further up the chain.
您需要根据证书链进行推理。中间 CA 证书的目标是让远程方在终端实体证书（例如服务器或客户端证书本身）和链上的另一个 CA 证书之间建立一个链。
If you're talking about importing this intermediate CA certificate into a keystore that will be used as a truststore, whether that CA certificate is an intermediate one or a "root" CA certificate doesn't really matter: it will become a trusted anchor like another for the application using that truststore.
如果您正在谈论将此中间 CA 证书导入将用作信任库的密钥库，那么该 CA 证书是中间证书还是“根”CA 证书并不重要：它将成为一个可信的锚，例如另一个用于使用该信任库的应用程序。
If you're talking about a keystore used as a keystore, you need to make sure your EEC will be presented along with the correct chain.
如果您正在谈论用作密钥库的密钥库，您需要确保您的 EEC 将与正确的链一起显示。
For example, let's assume CA_1 issues the cert for CA_2, which issues the cert for server S. Your clients have cert CA_1 in their trusted anchors (but not necessarily CA_2): you'll need to present a chain "S, CA_2", so that they can verify the chain via CA_2 (otherwise, they wouldn't know how to link CA_1 to S).
例如，让我们假设 CA_1 为 CA_2 颁发证书，它为服务器 S 颁发证书。您的客户端在其受信任的锚点（但不一定是 CA_2）中有证书 CA_1：您需要提供一个链“S，CA_2”，以便他们可以通过 CA_2 验证链（否则，他们将不知道如何将 CA_1 链接到 S）。
To do so, you need to make sure the entry for S and its private key contains the chain it needs to send (S, CA_2), not just certificate S. Importing CA_2 in a separate entry in your keystore will not make the JSSE build the chain for you when presenting certificate S.
为此，您需要确保 S 的条目及其私钥包含它需要发送的链 (S, CA_2)，而不仅仅是证书 S。在您的密钥库中的单独条目中导入 CA_2 不会使 JSSE 构建出示证书 S 时的链条。
How to do so is described in this answer(although this was from a client-cert point of view).
