错误:KeyUsage 不允许数字签名 - Java-applet + 相互 SSL [英] Error: KeyUsage does not allow digital signatures - Java-applet + mutual SSL

问题描述

我们开发了一个在 Tomcat 中运行的基于 Web 的 Java 应用程序，该应用程序在 Windows 2008 上的 IIS 下运行.该网站在 IIS 中启用了 2 路(相互)SSL，要求客户端使用 x.509 证书 (PKI) 作为 SSL 的一部分进行身份验证这适用于我们所有使用 IE 的证书.

该网站还有一个名为 ViewOne ImageViewer 的 java 小程序.这适用于使用我们的某些证书​​的 2-way SSL，但对于其他证书，我们在用户选择其身份验证证书后的 SSL 握手期间在客户端 (java 1.6) 上遇到异常:

<块引用>

安全性:KeyUsage 不允许数字签名

证书之间最明显的区别是 EKU(扩展密钥用法)不存在于失败的证书中.工作证书具有 EKU客户端身份验证 - 1.3.6.1.5.5.7.3.2".

有谁知道运行java小程序是否需要EKU 1.3.6.1.5.5.7.3.2或者是否可以在某处设置?或者错误可能是因为其他原因?

谢谢！

解决方案

通常用于验证证书的标准在 RFC 5280:Internet X.509 公钥基础设施证书和证书撤销列表 (CRL) 配置文件.证书可以(至少)有两个关于其用法的扩展:密钥用法 和 扩展密钥用法.

• 密钥使用

Key Usage 扩展没有专门讨论客户端证书.但是，如果此扩展存在，则必须设置 digitalSignature 标志，因为在 SSL/TLS 握手期间，CertificateVerify TLS 消息使用此证书的私钥进行签名.根据 RFC 5280 的这一部分，这是必需的:

<块引用>

digitalSignature 位被断言当主题公钥用于验证数字签名，而不是签名证书(位 5)和 CRL(位 6)，例如用于实体认证服务，一种数据源认证服务，和/或完整性服务.

(大多数密码套件也需要 keyAgreement.)

• 扩展密钥使用

如果更具体地涉及客户端证书(如果存在扩展名，建议使用但并非总是如此):

<块引用>

 id-kp-clientAuth 对象标识符 ::= { id-kp 2 }-- TLS WWW 客户端认证-- 可能一致的密钥使用位:digitalSignature-- 和/或 keyAgreement

您可以在thisNSS 技术说明(这应该适用于其他产品).

当您获得安全性:KeyUsage 不允许数字签名"时，这似乎表明您尝试使用的证书中存在(非扩展)密钥用法作为客户端证书，但未启用 digitalSignature.(这是颁发这些证书的 CA 应该做的事情.)

这与小程序无关.但是，小程序本身的 URL 可能受到客户端证书身份验证的保护，这会因为这些扩展而失败.

在服务器端，由于您在 IIS 后面运行它，因此处理 TLS/SSL 证书验证的是 IIS.Apache Tomcat 不应该真正关心它从哪里获得证书.(在 Java 中，您可以通过配置自定义 TrustManager 来调整验证证书的方式，但这仅适用于 Java (JSSE) 本身处理 SSL/TLS 连接的情况；它当 Tomcat 位于 IIS、Apache Httpd 或什至使用 APR 时，则不适用.)我不确定如何使用 IIS 进行配置，但是 netsh http add sslcert 调用 [ usagecheck= ] enable |禁用，这听起来可能有帮助.不过，这可能太宽容了.(谨慎使用.)

话虽如此，似乎您甚至在发送证书之前就在客户端收到了错误.我必须承认我还没有尝试过，但是您可以使用特定的 KeyManager 来强制使用该证书.我不完全确定这是否有效.

顺便说一句，签署小程序是另一回事.要签署小程序，证书需要具有 anyExtendedKeyUsage 或 id-kp-codeSigning 的扩展密钥用法.(否则签名会起作用，但运行小程序不会.)您可以在此处找到更多信息:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5056088

We have developed a webbased Java application running in Tomcat under IIS on Windows 2008. The website has 2-way (mutual) SSL enabled in IIS requiring the client to authenticate using a x.509 certificate (PKI) as part of SSL and this works fine with all our certificates using IE.

The website also has a java-applet called ViewOne ImageViewer. This works fine with 2-way SSL with some of our certificates but with others we get the exception on the client (java 1.6) during SSL-handshake after the user has selected its authentication certificate:

security: KeyUsage does not allow digital signatures

The most obvious difference between the certificates are that EKU (Extended Key Usage) are not present on the certificates failing. The certificate working has the EKU "Client Authentication - 1.3.6.1.5.5.7.3.2".

Does anyone know if the EKU 1.3.6.1.5.5.7.3.2 is needed to run a java applet or if this can be set somewhere? Or could the error be because of something else?

Thanks!

解决方案

The standard normally used to validate a certificate are in RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Certificates can have (at least) two extensions about their usage: Key Usage and Extended Key Usage.

• Key Usage

The Key Usage extension doesn't talk specifically about client-certificates. However, if this extension is present, the digitalSignature flag must be set, since during the SSL/TLS handshake, the CertificateVerify TLS message is signed with the private key for this certificate. This is required according to this section of RFC 5280:

The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures, other than signatures on certificates (bit 5) and CRLs (bit 6), such as those used in an entity authentication service, a data origin authentication service, and/or an integrity service.

(Most cipher suites will require keyAgreement too.)

• Extended Key Usage

This one if more specific about client-certificates (if the extension is present, which is recommended but not always the case):

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

You can find more details about this in this NSS technical note (this should apply across other products).

When you get "security: KeyUsage does not allow digital signatures", it seems to indicate that the (non-extended) Key Usage is present in the certificate you're trying to use as a client-certificate, but that digitalSignature isn't enabled. (That's something that the CA the issued these certificates should have done.)

This is not related to the applet. However, it's possible that the URL of the applet itself is protected with client-certificate authentication, which would fail because of these extensions.

One the server side, since you're running this behind IIS, it's IIS that handles the TLS/SSL certificate verification. Apache Tomcat shouldn't really care about where it got the certificate from. (In Java, you'd be able to tweak the way you verify the certificate by configuring custom TrustManagers, but that would only apply if Java (JSSE) was handling the SSL/TLS connection itself; it doesn't apply when Tomcat is behind IIS, Apache Httpd or even when it uses APR.) I'm not sure how to configure this with IIS, but there is an option in netsh http add sslcert called [ usagecheck= ] enable | disable, which sounds like it could help. It might be too lenient, though. (Use with caution.)

This being said, it seems that you get the error on the client side, before the certificate is even sent. I must admit I haven't tried, but you might be able to use a specific KeyManager that would force the use of that certificate. I'm not entirely sure whether this would work.

Just as a side note, signing applet is a different matter. To sign an applet, the certificate needs to have the Extended Key Usage for anyExtendedKeyUsage or for id-kp-codeSigning. (Signing will work otherwise, but running the applet won't.) You can find more information here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5056088

这篇关于错误:KeyUsage 不允许数字签名 - Java-applet + 相互 SSL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！