【问题标题】:jboss 5.1 ssl client authentificationjboss 5.1 ssl客户端认证
【发布时间】:2014-09-26 12:21:18
【问题描述】:

我在 Jboss 5.1 GA 中的客户端身份验证存在问题。我尝试做的是使用自生成和自签名证书进行客户端身份验证。因此,我有一个密钥库 my.keystore 和一个信任库 my.truststore。我使用 Java 密钥工具。要生成证书,我使用命令:

keytool -genkey -alias test -keyalg RSA -validity 365 -keystore /mirrored/certs/my.keystore

要导出这个证书,我使用命令:

keytool -export -alias test -keystore /mirrored/certs/my.keystore -rfc -file /mirrored/certs/test.cert

将证书导出到文件后,我使用以下命令将其导入到信任库:

keytool -import -alias test -file /mirrored/certs/test.cert -storetype JKS -keystore /mirrored/certs/my.truststore

作为证书的所有者,我使用 localhost。

Jboss 5.1 GA在server.xml中配置如下:

<Connector protocol="HTTP/1.1" SSLEnabled="true" 
       port="8765" address="${jboss.bind.address}"
       scheme="https" secure="true" clientAuth="true" 
       keystoreFile="/mirrored/certs/my.keystore"
       keystorePass="mypasswd" sslProtocol="TLS" 
       truststoreFile="/mirrored/certs/my.truststore"
       truststorePass="mypasswd"/>

为了测试这个配置和我使用 openssl 的证书。首先,我从上面验证了证书。证书是好的说openssl。然后我通过 openssl s_client 调用我的应用程序服务器,我使用以下命令执行此操作:

openssl s_client -showcerts -CAfile test.cert -connect localhost:8765

执行此操作后,我得到以下输出:

openssl s_client -showcerts -CAfile test.cert -connect 10.180.10.74:8765
CONNECTED(00000003)
depth=0 C = DE, ST = Bremen, L = Bremen, O = Signalis, OU = localhost, CN = localhost
verify return:1
140477019141960:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1193:SSL alert number 42
140477019141960:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
---
Certificate chain
0 s:/C=DE/ST=Bremen/L=Bremen/O=Signalis/OU=localhost/CN=localhost
i:/C=DE/ST=Bremen/L=Bremen/O=Signalis/OU=localhost/CN=localhost
-----BEGIN CERTIFICATE-----
MIICazCCAdSgAwIBAgIEVCE7CTANBgkqhkiG9w0BAQUFADB6MQswCQYDVQQGEwJE
RTEPMA0GA1UECBMGQnJlbWVuMQ8wDQYDVQQHEwZCcmVtZW4xETAPBgNVBAoTCFNp
Z25hbGlzMRowGAYDVQQLExF1Z2QtYnJicmVmLXNlcnYtNzEaMBgGA1UEAxMRdWdk
LWJyYnJlZi1zZXJ2LTcwHhcNMTQwOTIzMDkxOTA1WhcNMTUwOTIzMDkxOTA1WjB6
MQswCQYDVQQGEwJERTEPMA0GA1UECBMGQnJlbWVuMQ8wDQYDVQQHEwZCcmVtZW4x
ETAPBgNVBAoTCFNpZ25hbGlzMRowGAYDVQQLExF1Z2QtYnJicmVmLXNlcnYtNzEa
MBgGA1UEAxMRdWdkLWJyYnJlZi1zZXJ2LTcwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBAIxLY7onLN91UPIUesdwQxvbSSqFPnYXz5HnSaZx3dkqje+g6qOupqU7
4NP4dFgLbxMx6eqKkGAVVXQ7QEn/Ekp1w6Xncts2LM9FyFHUikBDZewwyvRGbIak
WW3vexpS8FMwmESPnJ+Bk1tHd2YJ0POWGt4FQfZ1u5FR4BQk72CJAgMBAAEwDQYJ
KoZIhvcNAQEFBQADgYEABk5Je4aoPuv1J06Vget40vHqs+rahSpoto39Flbp2JYz
y1UQPnp6o6alLtiOQcFI0iea0zXm8LMybkZTnvP7jj2//49KOmI0+RJx6cWj+cXi
qWJbK+C+8GcU+jJYwOwJrQgEl0Lr21ExebO5Is8kqQVdSiroT5KQsdPCCjKPqYc=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=DE/ST=Bremen/L=Bremen/O=Signalis/OU=localhost/CN=localhost
issuer=/C=DE/ST=Bremen/L=Bremen/O=Signalis/OU=localhost/CN=localhost
---
Acceptable client certificate CA names
/C=DE/ST=Bremen/L=Bremen/O=Signalis/OU=localhost/CN=localhost
/C=DE/ST=Bremen/L=Bremen/O=Signalis/OU=ugd-brbref-serv-7/CN=ugd-brbref-serv-7
---
SSL handshake has read 1420 bytes and written 170 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher    : EDH-RSA-DES-CBC3-SHA
Session-ID: 542421BD481B93286D41F5BCB96272B668500E2D35C74862189BFEAF1FC4EE4C
Session-ID-ctx:
Master-Key:    
ED17146FE586DE1A7F9E7272E1771293E964F242BF2187DF5329FFF0E3090C9B14B298CAFD13558A8F763444E6A53B5A
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1411654077
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---

所以openssl中的错误信息是

SSL alert number 42

Jboss 日志中的错误信息是:

2014-09-25 11:38:34,366 DEBUG [org.apache.tomcat.util.net.JIoEndpoint] (http-0.0.0.0-8765-1) Handshake failed
javax.net.ssl.SSLHandshakeException: null cert chain
   at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1649)
   at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
   at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:231)
   at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1369)
   at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:160)
   at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
   at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
   at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
   at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:160)
   at org.apache.tomcat.util.net.JIoEndpoint.setSocketOptions(JIoEndpoint.java:633)
   at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
   at java.lang.Thread.run(Thread.java:662)

所以Jboss中的错误信息是

null cert chain

我不知道我做错了什么。我原则上做得对吗?首先在密钥库中生成证书,然后将其导出并导入到信任库中。有人对 Jboss 5.1 GA 中的客户端身份验证有一些经验吗?也许我以错误的方式使用 openssl 来测试客户端身份验证?

【问题讨论】:

    标签: ssl openssl jboss5.x keytool authentication


    【解决方案1】:

    问题出在openssl命令中,需要导出你的私钥,然后执行命令如下:

    openssl s_client -connect localhost:8765 -CAfile test.cert -cert test.cert -key MYKEY.key 
    

    有关详细信息,请参阅 s_client(1)s_server(1) 上的文档。

    【讨论】:

    • 这个有效,非常感谢!但我现在有点困惑。为什么客户端需要私钥进行客户端身份验证?我想,我只需要将公钥提供给客户端,每个客户端一个公钥。我正在尝试做一个休息网络服务,它只能通过客户端身份验证来调用......
    • 好的,现在我明白了。我需要将私钥与 p12 格式的证书一起导出以进行客户端身份验证。非常感谢。
    • @Reckert 您可以使用此应用程序来管理密钥库http://keystore-explorer.sourceforge.net/
    猜你喜欢
    • 2013-08-04
    • 1970-01-01
    • 2016-02-03
    • 2019-07-04
    • 2010-10-16
    • 2017-04-28
    • 2012-02-15
    • 2011-03-09
    • 2015-09-06
    相关资源
    最近更新 更多