错误：密钥使用不允许数字签名 - Java的小程序+相互SSL [英] Error: KeyUsage does not allow digital signatures - Java-applet + mutual SSL

问题描述

我们已经开发了在Windows 2008下的IIS在Tomcat中运行的基于Web的Java应用程序的网站在IIS中启用2路（共同）SSL要求客户使用X.509证书（PKI）的SSL的一部分来验证这工作正常使用IE浏览我们的所有证书。

该网站也有一个Java小程序称为ViewOne图像浏览器。这能与2路SSL与我们的一些证书，但与别人我们得到SSL握手期间，客户机（Java 1.6）上异常的用户选择了它的认证证书后：

  

安全性：密钥使用不允许
  数字签名

证书之间最明显的区别是EKU（扩展密钥用法）不在证书失败present。该证书的工作有EKU客户身份验证 - 1.3.6.1.5.5.7.3.2。

有谁如果EKU 1.3.6.1.5.5.7.3.2是需要运行Java applet或不知道是否可以这样设置的地方？
或者，可以在错误是因为别的什么？

谢谢！

解决方案

通常用来验证证书的标准是的 RFC 5280：互联网X.509公钥基础设施证书和证书撤销列表（CRL）档案。证书可以有（至少）对他们使用两个扩展：密钥用法和扩展密钥用法。

• 键用法

密钥使用扩展不有关客户证书，具体谈。但是，如果这种扩展是present，在的DigitalSignature 标志必须设置，因为SSL / TLS握手期间， CertificateVerify TLS消息与私钥此证书签名。这是根据RFC 5280中本条规定：

  

本的DigitalSignature位被断言
  当主体公钥
        用于验证数字签名，比签名上的其他
        证书（位5）和CRL（位6），如那些在使用
        实体认证服务，数据源认证
        服务，和/或完整性服务

（大多数的密码套件将需要协议密钥了。）

• 扩展密钥用法

这一个，如果更具体的有关客户证书（若扩展名是present，其中建议，但并非总是如此）：

  ID-KP-clientAuth对象标识符:: = {ID-KP 2}
    -  TLS WWW客户端身份验证
    - 主要使用比特可能是一致的：的DigitalSignature
    - 和/或协议密钥
 

您可以在这NSS找到更多细节技术说明（这应该在其他产品适用）。

当你拿的安全性：密钥使用不允许的数字签名的，这似乎表明，（非扩展）主要用途是你想在证书中present使用作为客户端证书，但没有启用的DigitalSignature 。 （在这个时候，在CA颁发这些证书应该做的。）

这是不相关的小程序。然而，这可能是该applet本身的URL保护，客户端证书身份验证，这将失败，因为这些扩展的。

一个服务器端，因为你运行此背后IIS，它是IIS处理该TLS / SSL证书验证。 Apache Tomcat上不应该真正关心它来自何处获得认证证书。 （在Java中，你可以调整你核实配置自定义的TrustManager S中的证书的方式，但如果用Java代码（JSSE）的处理SSL，将仅适用/ TLS连接本身;当Tomcat是背后IIS，apache httpd的或不适用，即使它使用APR）
我不知道如何使用IIS配置这一点，但在的 netsh的HTTP添加的sslcert 名为 [usagecheck =]启用|禁用，这听起来像它可以帮助。这可能是过于宽松，虽然。 （应谨慎使用。）

这虽这么说，看来你的错误在客户端，甚至之前发出的证书。我必须承认我还没有尝试过，但你也许可以使用特定的的KeyManager ，将强制使用该证书。我不能完全肯定这是否会工作。

正如一个侧面说明，签约小程序则另当别论。要签署一个applet，该证书需要有扩展密钥用法的 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

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