I am writing a Java client (on weblogic 10.3) to invoke a secure web service.
I have been provided with a client certificate which I have installed in cacerts, DemoIdentity.jks and DemoTrust,jks
In my weblogic I have set up keystore as DemoIdentity and DemoTrust.
In weblogic console I have set
"Two Way Client Cert Behavior:" as "Client Certs requested but not enforced".
and for "SSL Listen Port enabled:" I have checked the checkbox.
I get the below exception while trying to access the web service:
] FaultActor [null] Detail [<detail><bea_fault:stacktrace xmlns:bea_fault="http:
//www.bea.com/servers/wls70/webservice/fault/1.0.0">javax.net.ssl.SSLHandshakeEx
ception: [Security:090497]HANDSHAKE_FAILURE alert received from ************** Check both sides of the SSL configuration for mismatches in supported ciphers, supported protocol versions, trusted CAs, and hos
tname verification settings.
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireException(Unknow
n Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertReceived(Un
known Source)
at com.certicom.tls.record.alert.AlertHandler.handle(Unknown Source)
at com.certicom.tls.record.alert.AlertHandler.handleAlertMessages(Unknow
n Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown S
ource)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Sou
rce)
at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknow
n Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Un
known Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.io.OutputSSLIOStreamWrapper.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65
)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at java.io.FilterOutputStream.flush(FilterOutputStream.java:123)
at weblogic.net.http.HttpURLConnection.writeRequests(HttpURLConnection.j
ava:158)
at weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.
java:363)
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLC
onnection.java:37)
at weblogic.wsee.connection.transport.TransportUtil.getInputStream(Trans
portUtil.java:85)
at weblogic.wsee.connection.transport.http.HTTPClientTransport.receive(H
TTPClientTransport.java:271)
at weblogic.wsee.connection.soap.SoapConnection.receive(SoapConnection.j
ava:485)
at weblogic.wsee.ws.dispatch.client.ConnectionHandler.handleResponse(Con
nectionHandler.java:179)
at weblogic.wsee.handler.HandlerIterator.handleResponse(HandlerIterator.
java:287)
at weblogic.wsee.handler.HandlerIterator.handleResponse(HandlerIterator.
java:271)
at weblogic.wsee.ws.dispatch.client.ClientDispatcher.handleResponse(Clie
ntDispatcher.java:213)
at weblogic.wsee.ws.dispatch.client.ClientDispatcher.dispatch(ClientDisp
atcher.java:150)
at weblogic.wsee.ws.WsStub.invoke(WsStub.java:87)
at weblogic.wsee.jaxrpc.StubImpl._invoke(StubImpl.java:339)
at sips_cn_contract.PaymentService_Stub.processPaymentWebInit(Unknown So
urce)
at uk.gov.gateway.payments.SipsStartupController.handleRequest(SipsStart
upController.java:73)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.ha
ndle(SimpleControllerHandlerAdapter.java:45)
at org.springframework.web.servlet.DispatcherServlet.doService(Dispatche
rServlet.java:485)
at org.springframework.web.servlet.FrameworkServlet.serviceWrapper(Frame
workServlet.java:342)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServl
et.java:318)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run
(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecuri
tyHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:300)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.jav
a:183)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.doIt(WebAppServletContext.java:3686)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationActio
n.run(WebAppServletContext.java:3650)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authenticate
dSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:
121)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppS
ervletContext.java:2268)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletC
ontext.java:2174)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.j
ava:1446)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
</bea_fault:stacktrace></detail>]; nested exception is:
However in firefox, i have added the certificate, and when i view the wsdl of the web service.It prompts me with the certificate and after i click ok, it renders the wsdl file for secure web service.
Anybody has idea what should I do to make the client working using Java?
I think that the real problem is that Weblogic is not using standard Sun HTTPS implementation provided by JDK, but rather uses its own, as apparent on this line:
at weblogic.net.http.SOAPHttpsURLConnection.getInputStream(SOAPHttpsURLConnection.java:37)
The standard Sun implementation class is called javax.net.ssl.HttpsURLConnection.
As a result, the certificate policy is different inside Weblogic than in a standalone Java program. I just discovered this debugging a similar problem.
This page advises to use a Sun implementation instead of Weblogic:
http://webtech-kapil.blogspot.com/2010/06/javalangclasscastexception.html
They advice to start WL with the following flag:
-DUseSunHttpHandler=true
which will use standard Sun's implementation of SSL. However, I personally have not tried this yet.
Thanks,
Igor
You have likely not imported your certificate and key correctly. You can test your keystore by adding the following to a JUnit or something similar:
static {
System.setProperty("javax.net.ssl.keyStoreType", "pkcs12"); // or whatever
System.setProperty("javax.net.ssl.keyStore", "c:/folder/mycert.p12");
System.setProperty("javax.net.ssl.keyStorePassword", "mypassword");
System.setProperty("javax.net.debug", "ssl");
}
The javax.net.debug property set to ssl will print your certificate chain and all other SSL logging, which can be helpful. You'll want to add the certificate, etc. to your application container like you already have in production.
Try debugging with SSL and see what comes of that. More than likely you just need to configure weblogic correctly. Check to see if there are custom SSL endpoint configurations (i.e. when URI is /test/test use keyStore XYZ).
Related
I am working on a Java alternative to libimobiledevice (not a wrapped or binding over the native libs).
I decided it makes sense to use Netty (v4.1.12) as the communication layer, due to the nature of multiple protocol layers involved with communicating with services on the device, which Netty can easily handle using pipeline configurations.
After implementing a few simple queries from Usbmux and Lockdown, I am trying to perform TLS handshake to request specific services on the device.
First, I've tried the simple approach - adding an SslHandler to the pipeline:
SslContext context = SslContextBuilder.forClient().build();
channel.pipeline().addFirst(context.newHandler(channel.alloc()));
But it seems the certificate sent from the device is not valid, in the eyes of the JDK x509 certificate parser:
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLProtocolException: Empty issuer DN not allowed in X509Certificates
...
Caused by: java.security.cert.CertificateParsingException: Empty issuer DN not allowed in X509Certificates
Next thing I tried, was using bouncycastle as ssl handler.
bouncycastle successfully parsed the certificate, but failed during the handshake with a different error:
Caused by: org.bouncycastle.crypto.tls.TlsFatalAlert: illegal_parameter(47)
at org.bouncycastle.crypto.tls.TlsClientProtocol.receiveServerHelloMessage(Unknown Source)
at org.bouncycastle.crypto.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)
at org.bouncycastle.crypto.tls.TlsProtocol.processHandshakeQueue(Unknown Source)
at org.bouncycastle.crypto.tls.TlsProtocol.processRecord(Unknown Source)
at org.bouncycastle.crypto.tls.RecordStream.readRecord(Unknown Source)
at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown Source)
at org.bouncycastle.crypto.tls.TlsProtocol.blockForHandshake(Unknown Source)
at org.bouncycastle.crypto.tls.TlsClientProtocol.connect(Unknown Source)
I have tried to debug into bouncycastle and understand what was the illegal parameter, and it seems to me that there's a mismatch in the protocol version requested by the device (TLSv1.0) vs the one requested by the client (TLSv1.2).
I would paste a sample working code here, but getting to the part of the SSL session requires pretty large set of tools and parsing libraries.
I will try to create a sample git repo for this purpose (maybe even make the whole project open source later), but I was hoping someone can point me in the right direction in the meanwhile.
Feel free to ask for other materials, such as hex dump of the handshake, or the certificates involved.
The company I work for creates software that crawls and indexes various sources for use in search, in this case we're completely stuck on attempting to connect to Lotus Notes over SSL. This is a classic case of "it worked in dev, but failed in prod".
The problem is further compounded by the fact that we're devs and techies, not Lotus Notes experts.
Basically we have a piece of Java software that connects to Lotus to grab the DIIOP IOR text file using this command:
String ior = NotesFactory.getIOR(host, userIOR, pwdIOR);
Now, this is a non-SSL connection and requires username and password to connect. This works perfectly every time.
Then we attempt to create a session using this:
session = NotesFactory.createSessionWithIOR(ior, args, this.user, this.pwd);
where:
args[0] = "-ORBEnableSSLSecurity";
When connecting we consistently receive this stack trace:
NotesException: Session closed due to communications failure
at lotus.domino.cso.ORBCallback.make_error(Unknown Source)
at lotus.priv.CORBA.iiop.Generic.make_error(Unknown Source)
at lotus.priv.CORBA.portable.ObjectImpl._invoke(Unknown Source)
at lotus.domino.corba._IObjectServerStub.createSession(Unknown Source)
at lotus.domino.cso.Session.initSession(Unknown Source)
at lotus.domino.cso.Session.<init>(Unknown Source)
at lotus.domino.cso.Session.createSession(Unknown Source)
at lotus.domino.NotesFactory.createSessionUP(Unknown Source)
at lotus.domino.NotesFactory.createSessionWithIOR(Unknown Source)
[ ... ]
Caused by: org.omg.CORBA.COMM_FAILURE: java.net.SocketException: Connection reset: Connection closed: Host: <redacted> Port: 63149 vmcid: 0x0 minor code: 1 completed: Maybe
at lotus.priv.CORBA.iiop.IIOPConnection.purge_calls(Unknown Source)
at lotus.priv.CORBA.iiop.ReaderThread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:154)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at lotus.priv.CORBA.iiop.Message.readFully(Unknown Source)
at lotus.priv.CORBA.iiop.Message.createFromStream(Unknown Source)
at lotus.priv.CORBA.iiop.IIOPInputStream.prefill(Unknown Source)
at lotus.priv.CORBA.iiop.IIOPConnection.createInputStream(Unknown Source)
... 1 more
I understand the most common reason for this is because we're not correctly importing the TrustedCerts.class file, however after double and triple checking it's in the class path just fine (and the fact it works in dev environment) we're confident that it's being loaded in.
We know if we disable SSL (aka remove the aforementioned arg) our code will connect to the non-SSL DIIOP port 63148 and work just fine however it is a project requirement that all data must be passed through SSL.
Which finally brings me to my actual question: How do we get Lotus to report why this connection is failing?
I've tried upping the DIIOP log level to 4 which apparently should show all transmissions but the logs show nothing when I attempt to connect. Also it's worth noting the DIIOP service is definitely running and on the correct ports as well.
I've also checked that we're making it through the firewall to the remote box and TCPDUMP on our RedHat machine clearly shows that we establish a connection with the remote Lotus Notes host before it responds closing the connection.
[Pertinent Information]
Application: Java
Library: NCSO.jar
Lotus Version: Domino 8.5.3 FP6
Lotus Server: Windows Server 2008 Standard
Ports: 63148 (non-SSL), and 63149 (SSL)
Alright, the answer was clear as crystal but not something I was actively looking for.
The reason this doesn't work is that the third party certificate is not a SHA-1 certificate and Lotus Notes 8.5.x only supports SHA-1 (as per this documentation).
So basically that certificate of theirs can never be used for SSL authentication programatically or otherwise.
You mentioned DIIOP logging, but if the connection is failing in the SSL handshake, then the guts of the diiop task probably don't know what's wrong since that's occurring at a lower level in the stack. There are, however, additional debug variables that can be set on the server.
DEBUG_SSL_HANDSHAKE=1
DEBUG_SSL_CIPHERS=1
DEBUG_SSL_ALL=1
The last setting can be pushed up to 2 or 3 for more detailed information.
Restart of the server (or possibly of the server's diiop task) may be required to get the settings to take effect.
I have https certificate signed by Geo Trust. All browsers opens my site very well. My app authorizing through https, and most time everything OK. But sometimes users can't connect and have error:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
at org.greencubes.downloader.Downloader.downloadFile(Unknown Source)
at org.greencubes.lil.Launcher.<init>(Unknown Source)
at org.greencubes.lil.Launcher.main(Unknown Source)
Last user had windows 7 x86 and java 1.7_45u. It happens on random OSs and random java updates, i don't know the reason. Sometimes it's not happening, but usually if user have such error nothing can help.
I can not add certificate to user's keysore as this is user application.
Target url is auth.greencubes.org (empty response must return 403), you can check it.
So, i found a problem with help of one of my users. The problem in that Kaspersky Antivirus (or may be some other antiviruses/firewalls too, ESET NOD may be) inspecting encrypted connections by replacing SSL certificates, and default java keystore has no certificate of Kaspersky CA (cause it is generated on installation of antivirus).
First solution is to disable inspecting encrypted connections or inspection connections at all (web-antivirus functionality) or disabling antivirus.
The right solution is try to use Windows's KeyStore, where Antiviruses's CA Certificate was added by antivirus itself. It can be done by setting JVM parameter:
-Djavax.net.ssl.trustStoreType=Windows-ROOT
(It must be "Windows-ROOT", not "Windows-MY"!)
Or by executing this code when app starts (in main() function preferable):
System.setProperty("javax.net.ssl.trustStoreType", "Windows-ROOT");
You just need to be sure that it's windows system, so command-line argument is not general-purpose solution.
This code can be used to be sure that windows key store is present and valid:
if(System.getProperty("os.name").toLowerCase().contains("windows")) {
try {
KeyStore ks = KeyStore.getInstance("Windows-ROOT");
ks.load(null, null);
System.setProperty("javax.net.ssl.trustStoreType", "Windows-ROOT");
} catch(Exception e) {
// Ignore: windows keystore is bad, left default
}
}
I need to be able to point JMeter at a test server which has an expired SSL certificate (it will be some time before we are able to renew it). JMeter is quite rightly throwing an exception when it tries to connect:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:284)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1075)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1064)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:426)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:255)
at java.lang.Thread.run(Unknown Source)
Does anybody know of any way that I can import said certificate into the keystore and in the process change the expiry date (and would this even help or would the fact that the server certificate has expired still cause this exception to be thrown)?
I've tried to set the validity as part of the import but this is ignored:
keytool -import ... -validity 100
P.S - I know I could implement my own TrustManager which ignores these checks but my fingers won't allow me to write such evil code and I'd much rather get to a solution that I can install on the server without having to modify JMeter!
Thanks for your time.
JMeter does not validate certificate so this is not the cause of your issue.
Which implementation do you use, java, HC3 or HC4 ?
Your issue could come from error in Socket version negotation.
Try setting this in user.properties:
https.socket.protocols=SSLv2Hello SSLv3 TLSv1
You may have to play with them depending on your server configuration, for example only set this:
https.socket.protocols=SSLv3
I have successfully built a working web service, client, and .jsp-driven UI. I did this with Eclipse, Axis2, Tomcat 7, and Java 7.
The basic flow is that the user visits the .jsp and submits a form with input data. The JSP forwards the "request" object to the Java client. The Java client consumes the web service and submits the user input. The service connects to a SQL Server database via JDBC to retrieve information, which is displayed back to the user.
This all works perfectly over HTTP, but now I want to secure the process, and this is where I'm running into problems. I'm able to create a cert and get Tomcat to use it. I can connect to the web UI via HTTPS and submit the form and get data back just fine. The problem is that this is only securing the front-end. The web service client code is still connecting to the service via HTTP in the background.
According to this page, all I really need to do to enable my service for connections via SSL is to update the axis2.xml file and include a new "transportReceiver" node for HTTPS. I did that and regenerated my client code to use the secure endpoint. It doesn't work.
I have configured Tomcat to listen on ports 8081 for http and 8443 for https. But after changing axis2.xml to match, and starting up Tomcat, I get the following:
[INFO] Listening on port 8443 [ERROR] Terminating connection
listener
org.apache.axis2.transport.http.server.DefaultConnectionListener#16d60567
after 10retries in 0 seconds. java.net.BindException: Address already
in use: JVM_Bind at java.net.DualStackPlainSocketImpl.bind0(Native
Method) at java.net.DualStackPlainSocketImpl.socketBind(Unknown
Source) at java.net.AbstractPlainSocketImpl.bind(Unknown Source) at
java.net.PlainSocketImpl.bind(Unknown Source) at
java.net.ServerSocket.bind(Unknown Source) at
java.net.ServerSocket.(Unknown Source) at
java.net.ServerSocket.(Unknown Source) at
org.apache.axis2.transport.http.server.DefaultConnectionListener.run(DefaultConnectionListener.java:80)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I have tried changing the port number in axis2.xml (for example, to 8445), and that sort of works. The server is able to start cleanly, but eventually, the same errors start showing up. For example, when I retrieve the WSDL, I see the error via the console (though the WSDL does show up). Also, if I try to actually use the service when on port 8445, I get the following error:
org.apache.axis2.AxisFault: Connection has been shutdown:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
I can only assume this is because Tomcat is configured to handle HTTPS on 8443, not 8445, but I honestly don't know.
If I leave the port as 8443 and ignore the errors at startup, I get the following message when I connect to the service:
org.apache.axis2.AxisFault: Connection has been shutdown:
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
I followed these steps to try to get it to recognize my certificate, but when importing it into my JRE7 keystore, I get the following:
keytool error: java.lang.Exception: Certificate reply and certificate
in keystore are identical
Basically, that cert is already there. Which makes sense, because it's the one that Tomcat is already using successfully.
So, I'm pretty clueless at this point. I'm really not sure what I'm supposed to be doing. Any general guidance, or a link to a step-by-step how-to would be really helpful.
But for a specific question... What, exactly, am I doing when I set the transportReceiver nodes in axis2.xml? Am I telling it what ports Tomcat is running on and that it should use, or does Axis2 have its own servers that will start on those ports? It seems to be the latter, but that doesn't make a whole lot of sense to me.
The correct way to configure the servlet transport is described in the Axis2 documentation. The symptoms you are describing suggest that you have a transportReceiver that refers to org.apache.axis2.transport.http.SimpleHTTPServer. Please also make sure that you use a recent version of Axis2 (1.5.6 or 1.6.1).
See Andreas's response for the port issue. As for the certificate issue, it was a misunderstanding on my part over the distinction between a keystore and truststore. The JVM defaults to using JAVA_HOME\lib\security\cacerts as its trust store, rather than the USER_HOME\.keystore file. Once I imported my certificate there, the errors went away.
I was also able to resolve the certificate problems by explicity setting the trust store to be the key store file, via code. I did this before importing the certificate into the cacerts store. It goes in the client code, right before invoking the service:
System.setProperty("javax.net.ssl.trustStore","C:\\path\\to\\.keystore");
System.setProperty("javax.net.ssl.trustStorePassword","password");
One of the way to connect to HTTPS is using jax-ws
E:\WSDL>wsimport -keep -p com.mypack.webservice https://domain:port/ws/MyService?wsdl
This will generate package structure under the wsdl folder. Use it.
Now all you have to do is put trust store in run.bat or use System class to set property.
It will work fine.