cxf中的https认证过程中常见的一些错误
Caused by: java.security.cert.CertificateException: No subject alternative names present
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:142)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:75)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
... 47 more
错误分析:http://blog.csdn.net/fjfdszj/article/details/5965913。
修改方案: conn.setHostnameVerifier(new HostnameVerifier()
{
public boolean verify(String hostname, SSLSession session)
{
return true;
}
});
Caused by: java.security.cert.CertificateException: No name matching localhost found
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
... 47 more
错误分析:该问题主要是没有找到匹配的主机,仔细检查webservice地址是否有误。
Caused by: java.net.s: cannot retry due to server authentication, in streaming mode
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1257)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1960)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1939)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1865)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:599)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 61 more
错误分析:该问题主要是当前为流模式,应为服务端验证不能重试,解决办法是客户端需要添加服务端的信任证书,该问题与通过httpUrlconnetion连接服务端访问401是同样的处理方式。
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1731)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
错误分析:该问题主要是由于客户端没有导入服务端证书,将服务端证书导入到客户端jdk中的证书库即可。导入命令如下:
keytool -import -v -trustcacerts -storepass changeit -alias 20 -file temip-id.cer -keystore ../jre/lib/security/cacerts。
Caused by: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Broken pipe
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1325) ~[na:1.6]
at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:65) ~[na:1.6]
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) ~[na:1.6.0_29]
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) ~[na:1.6.0_29]
at java.io.BufferedInputStream.read(BufferedInputStream.java:317) ~[na:1.6.0_29]
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:695) ~[na:1.6.0_29]
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:640) ~[na:1.6.0_29]
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195) ~[na:1.6.0_29]
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379) ~[na:1.6.0_29]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318) ~[na:1.6]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1960) ~[cxf-2.0.13.jar:2.0.13]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1939) ~[cxf-2.0.13.jar:2.0.13]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1865) ~[cxf-2.0.13.jar:2.0.13]
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) ~[cxf-2.0.13.jar:2.0.13]
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:599) ~[cxf-2.0.13.jar:2.0.13]
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) ~[cxf-2.0.13.jar:2.0.13]
... 83 common frames omitted
1.主要原因是由于双向认证证书配置的地址不正确,从而导致该错误。
2.可能的原因 :
网上查了很多资料,都说这个错误是由于Linux/Unix的连接数限制,或者多个线程对同一Socket进行读写。
但是经过我反复调试的结果,这个异常顾名思义就是Socket通道坏掉了。可能是数据发送有延迟,对方没有检测到新数据,直接把通道关了,于是你再往里添加数据时就出现这个异常,通常往Socket里面写数据的Write函数只调用一遍时,是不会出现这个问题的,经常出现在循环中。解决方法是自己加入信息交换的协议,比如第一个数据报头标明数据长度;而接收端口在无法检测到新数据时不能立即退出,等接收的数据长度达到要求后,或者一定时间没有新数据再退出。
在Unix/Linux下的网络结构和windows略有不同,至少在java的网络编程上有一些差异(没有考证,只是自己曾经遇到相同的问题!) 引起java.net.SocketException:Broken pipe这个异常的原因是你使用了多个线程同时对一个Socket通道进行读/写(windows环境没有这个问题),简单的说就是Unix/Linux下不能同时对一个Socket通道进行读和写。并且我也尝试过使用同步控制来防止对同一个Socket通道进行读和写,不过只是降低了该异常的发生概率(绝对不是同步控制有问题),发送和接收加入一段延迟后不会发生该问题,当然应用是不能容忍这样的处理效率和性能的。 最后我把整个网络通信改成用new io的非阻塞模式,在单线程中处理多路通道,没有这个问题,而且似乎系统吞吐量比先前更高了,
3:
java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) 一般出现在linux服务器上,常常由于网络不稳定或者服务器负荷过大,管道读端没有在读,而管道的写端继续有线程在写,就会造成管道中断。(由于管道是单向通信的) SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址,没有物理内存对应该地址。 以下是UNIX的信号解释: 11 / SIGSEGV: Unerlaubter Zugriff auf Hauptspeicher (Adressfehler). 12 / SIGUSER2: User-defined Signal 2 (POSIX). 把_JAVA_SR_SIGNUM改成12只是将信号至成user-defined,让它不报出来而已,不能解决问题。 建议采取的方式: 1. 资源没有完全释放,用完后要至NULL 值(JAVA的GC没那么完善) 2. 数据库连接顺序关闭!(RS,PS,CONN) 3. 优化JAVA虚拟机 加入相应的内存参数! 4. 不要在数据库中获取大段文本(即一个栏位的值不要太大) 5. JAVA 不推荐 用String 获取大量信息。(容易造成内存泄露,建议用StringBuffer) 6. 页面重复提交 7. 尽量将METHOD移到JAVA中,在JSP中所有的方法都看做全局变量,编译执行本身就有很多问题。 8. 如果是查询功能,尽可能的使用非XA(事务)。 9. 尽量用较新较稳定版本的JDK,低版本的JVM本身也有很多BUG,比如1。5的垃圾回收比起1。2,1。3一定是非常明显的进步。 10. LINUX系统本身没有这么稳定,有些问题无法避免的~~:)
主要原因是证书的制作有问题。
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:183)
at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:103)
at java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:87)
at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:55)
... 19 more
java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation
设置证书的参数有问题。
关于cxf的https认证目前介绍为止,如果需要更深入了解可以查看http://cxf.apache.org/
分享到:
相关推荐
**双向SSL**,也称为客户端和服务器之间的双向认证,比单向SSL更安全。在双向SSL中,不仅服务器验证客户端,客户端也要验证服务器的身份,同时服务器也会验证客户端的身份。这需要客户端和服务器各自拥有并提供有效...
3. **证书认证**:除了用户名和密码,也可以使用X.509证书进行双向认证,提供更高级别的安全性。 4. **安全协议**:使用HTTPS等安全协议,确保数据在传输过程中的安全。 总结,"CXF 通过用户名和密码进行验证"涉及...
5. **安全特性**:CXF支持多种安全机制,如基本认证、摘要认证、WS-Security(包括数字签名和加密)、SSL/TLS等,确保Web服务的安全通信。 6. **模块化设计**:CXF由多个模块组成,如Bus核心模块、WS-*协议模块、WS...
在CXF中,我们可以配置服务端和客户端证书,实现双向认证,即客户端验证服务器身份,服务器也验证客户端身份。 **配置CXF和WS-Security** 配置CXF以支持WS-Security通常涉及以下几个步骤: 1. **生成证书**:首先...
- CXF提供了 CXF wsdl2java 和 cxf-java2wsdl 工具,用于在WSDL和Java类之间进行双向转换。 - CXF还集成了IDE插件,如Eclipse和IntelliJ IDEA,提供代码生成、调试等便利功能。 8. **服务发现**: - CXF支持UDDI...
- **Apache CXF 与 Web Service**: Apache CXF 是 Java 平台上常用的 Web Service 开发框架之一,与 Axis 相比,它提供了更强大的功能和灵活性。CXF 支持多种开发模型,包括 Code-First 和 WSDL-First。Code-First ...
- **CA认证机构:** CA作为可信赖的第三方机构,负责验证申请者身份信息并颁发证书。常见的CA包括VeriSign、Thawte等。 #### 三、实践数字证书的生成与管理 **3.1 Java平台下的证书管理** - **keytool工具:** ...
3. **服务提供者接口(SPI)**: JAX-WS通过服务提供者接口(Service Provider Interface)允许开发者自定义服务实现,这包括处理消息、序列化和反序列化等。 4. **动态代理**: JAX-WS提供了一种动态生成客户端代理...