具有多个PrivateKeyEntries的JKS [英] JKS with multiple PrivateKeyEntries

问题描述

我正在Tomcat和Java 6中运行一个基本的Web应用程序.在我的应用程序中，我必须连接到两个不同的远程系统，并且每个系统都需要一个唯一的客户端证书.一年多以前，团队中的某人能够将两个PFX文件导入到1个JKS文件中，我们可以成功地与远程系统进行通信.不幸的是，创建此JKS文件的团队成员已不在，并且两个证书都已过期.

I'm running a basic web app within Tomcat and Java 6. In my app I have to connect to two different remote systems and each requires a unique client certificate. Over a year ago, someone on the team was able to import both PFX files into 1 JKS file, and we could successfully communicate to the remote systems. Unfortunately, the team-member that created this JKS file isn't around anymore and both of the certificates have expired.

当我尝试重新创建组合的JKS文件时，无论我们连接到哪个系统，都只使用了1个证书.这显然导致其中一个连接失败.这是密钥库条目的列表

When I tried to re-create the combined JKS file, only 1 certificate was ever used, regardless of the system we were connecting to. That obviously caused one of the connections to fail. Here's a list of the keystore entries

comodo-root, Jul 18, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 1D:35:54:04:85:78:B0:3F:42:42:4D:BF:20:73:0A:3F
comodo-intermediate, Jul 18, 2012, trustedCertEntry,
Certificate fingerprint (MD5): 2B:EE:B7:93:D7:C5:DD:65:E3:16:E9:98:EF:85:9B:F7
le-2f6efe10-57f8-4224-ba41-59940bd5422a, May 20, 2014, PrivateKeyEntry, 
Certificate fingerprint (MD5): 75:1C:60:72:4A:23:33:19:26:15:7F:27:8B:C6:65:A6
aa, May 20, 2014, PrivateKeyEntry, 
Certificate fingerprint (MD5): D2:D8:73:DA:FD:A0:09:42:12:27:B0:50:E8:98:4C:48

其中le-2f6efe10-57f8-4224-ba41-59940bd5422a和aa是我导入的两个客户端证书/存储.

Where le-2f6efe10-57f8-4224-ba41-59940bd5422a and aa are the two client certificates/stores that I imported.

如果在JKS之外使用两个证书，我已经验证了这两个证书可以独立工作.我还验证了，如果仅将一个PFX文件导入到JKS中，则可以成功连接到已导入证书的系统.

I have validated that both certificates work independently if I use them outside of the JKS. I have also verified that if I import only one of the PFX files into the JKS I'm able to successfully connect to that system that has the certificate imported.

我在JVM启动期间在运行时设置密钥库属性

I'm setting the keystore properties at runtime during JVM start

 System.setProperty("javax.net.ssl.keyStore", "path to my keystore" );
 System.setProperty("javax.net.ssl.keyStorePassword", "password" );

仅当我同时导入了两个PFX文件时才会出现问题，并且我收到的错误来自远程服务器，这表明所传递的客户端证书是错误的.

The problem only comes in when I have both PFX files imported, and the errors I'm receiving are from the remote servers indicating that the client certificate that's being passed is bad.

推荐答案

您没有说出私钥在哪里，但是我怀疑这里发生的事情是由于您的新证书已经被签名相同的CA，或者您使用相同的算法生成了两个新机密，或者两者都生成.

You don't say where you got your private keys, but I suspect that what is happening here is due to the fact that your new certificates have been signed by the same CA, or you have generated two new secrets using the same algorithm, or both.

SSL的设置方式，如果服务器需要客户端身份验证，它将发送可接受的证书类型列表，以及可能的可接受的CA列表(良好概述

The way that SSL is set up, if the server requires client authentication it will send a list of acceptable certificate types, possibly along with a list of acceptable CAs (good overview here). Your Java client then applies the following algorithm:

1. 对于服务器接受的每种证书类型(RSA，DSA，EC)，在密钥库中查找已使用指定算法生成的所有公钥/私钥对
2. 如果服务器发送了可接受的CA列表，请删除其证书链中不包含任何首选CA的所有密钥对
3. 如果至少剩余一个密钥对，请选择对应于第一个的私钥；否则，请返回第1步以获取下一个密钥类型.

因此，例如，让我们假设您希望连接到两台服务器，其中一台询问由VeriSign签名的DSA，RSA或EC密钥，其中一台询问没有首选CA的RSA或DSA密钥. (您可以通过将-Djavax.net.debug=ssl:handshake传递给客户端并查找以*** CertificateRequest开头的行来查找证书请求的内容)

So, for example, let us imagine you wish to connect to 2 servers, one of which asks for DSA, RSA or EC keys signed by VeriSign and one of which asks for RSA or DSA keys, with no preferred CAs. (You can find out the contents of the certificate requests by passing -Djavax.net.debug=ssl:handshake to your client and looking for lines starting with *** CertificateRequest)

如果您的密钥库包含两个由DSA密钥算法生成并由VeriSign签名的密钥对，则在两种情况下都会产生歧义.如果您有一个由VeriSign签名的DSA密钥对，由Go Daddy签名的一个DSA密钥对和您的内部CA签名的一个RSA密钥对，则在两种情况下都不会有歧义.

If your keystore contains two key pairs generated with the DSA key algorithm and signed by VeriSign, you will get ambiguities in both cases. If you have one DSA key pair signed by VeriSign, one DSA key pair signed by Go Daddy and one RSA key pair signed by your internal CA there will be no ambiguities in either case.

根据您的情况，最好的解决方法可能是检查旧证书链，以查看签名者和签名类型，并确保新证书集与旧证书匹配.或者，您可能需要硬着头皮写一些代码，以确保始终使用每次仅包含一个密钥的密钥存储区，如链接的问题中所示.

Concretely in your case, your best way forward may be to inspect your old certificate chains to see who signed them and what type they are and make sure that your new set of certificates match the old ones. Or you may have to bite the bullet and write some code to make sure that you are always working with a key store that only contains one key each time, as in the linked questions.

这篇关于具有多个PrivateKeyEntries的JKS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！