java数据签名错误,错误:密钥使用不允许数字签名 - Java的小程序+相互SSL

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!

解决方案

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值