cxf之https双向认证之三
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/
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/