Java SSL 选择了错误的证书，忽略了 key 的使用

Question

我有一个使用 SSL 进行通信的客户端/服务器。

客户端中的 keystore JKS 包含两个 具有不同 key 用法的证书。证书 1 用于 SSL 通信，证书 2 用于签名数据:

1. 一个证书有 KU=keyEncipherment,digitalSignature, EKU=clientAuth
2. 一个证书有 KU=nonRepudiation,digitalSignature

当我用它运行时，它会选择第一个(正确!)。如果我从 JKS 中删除第一个证书，它会在连接到服务器时选择带有 nonRepudiation 的证书(错误!？)。

这对我来说毫无意义，因为 nonRep 永远不应该像 afaik 那样使用。

那么，我能做些什么来解决这个问题，我怎样才能让 Java SSL 只选择使用合理 key 的证书？

顺便说一下，Windows 上的 JDK1.70_21。我使用的代码是标准的东西。只需获取默认 key 管理器等

Answer 1

首先，您的第二个证书可能具有 nonRepudiation key 使用扩展，但据我所知，这不会使其对客户端证书使用无效。 TLS 规范并没有真正说明客户端的 key 使用，尽管从技术上讲，它使用数字签名(因此您的两个证书都可能有效)。假设 digitalSignature 确实是必需的(据我所知，它正在实践中)，你的两个证书都有它，所以你的两个证书都是合适的。一个人也有其他关键用法的事实是另一回事。

此外，clientAuth 不是 key 使用扩展，而是extended key 使用扩展(或Netscape 扩展)。您的第二个证书缺少任何扩展 key 使用扩展，因此可以使用任何扩展 key 。

其次，JSSE 中默认的 X509KeyManager 实现的作者选择在缺少完美匹配时返回不完美匹配。参见 code comments :

/*
* Return the best alias that fits the given parameters.
* The algorithm we use is:
* . scan through all the aliases in all builders in order
* . as soon as we find a perfect match, return
* (i.e. a match with a cert that has appropriate key usage
* and is not expired).
* . if we do not find a perfect match, keep looping and remember
* the imperfect matches
* . at the end, sort the imperfect matches. we prefer expired certs
* with appropriate key usage to certs with the wrong key usage.
* return the first one of them.
*/
private String chooseAlias(List<KeyType> keyTypeList, Principal[] issuers,

因此，当带有keyEncipherment,digitalSignature,clientAuth 的证书丢失时，它将回退到另一个。

这是一个有争议的选择，但不一定是坏的选择。有些实现和部署不一定 100% 符合标准，并且无论您的 CA 给您什么，都可以方便地发送一些东西。归根结底，这并不是一个巨大的风险，因为 (a) 真正由您来选择要放入 keystore 中的内容，以及 (b) 在所有情况下都由服务器检查 key 使用情况。

将您不想用于 SSL/TLS 使用的证书放在您使用 javax.net.ssl.keyStore 属性设置的 keystore 中，或者构建一个 SSLContext 。

我不确定为什么要将它放在这个 keystore 中，但如果您需要其他证书可用于应用程序中的其他内容，通常将它放在不同的 keystore 中会更容易。

或者，您可以实现自己的 X509KeyManager 并根据需要覆盖其 chooseClientAlias 方法。在这种情况下，我将创建一个类，将所有调用委托(delegate)给默认的 X509KeyManager(使用默认算法从 KeyManagerFactory 获取并使用您的 keystore 进行初始化)，除了 chooseClientAlias 在返回别名之前，您将在其中检查 key 使用类型。这当然可行，但比使用两个 keystore 要多一些工作。

供引用:

• https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3
• https://developer.mozilla.org/en/docs/NSS/nss_tech_notes/nss_tech_note3 (请注意，据我所知，没有任何标准要求必须有任何 Nescape 证书类型或扩展 key 使用扩展才能使客户端证书有效)。