`

cxf之https双向认证之三

    博客分类:
  • cxf
阅读更多
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/
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics