When I try to connect Weblogic t3s protocol in Solaris Server, it shows this error:
java.lang.IllegalStateException: Not enough cryptography available to enable a cipher suite!
at com.certicom.tls.interfaceimpl.TLSSystem.resetCipherSuiteSupport(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.setCertificateSupport(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.<init>(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSSystem.<init>(Unknown Source)
at com.certicom.net.ssl.SSLContext.<init>(Unknown Source)
at com.bea.sslplus.CerticomSSLContext.<init>(Unknown Source)
at sun.reflect.GeneratedConstructorAccessor6.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at weblogic.security.utils.SSLSetup.getSSLDelegateInstance(SSLSetup.java:122)
at weblogic.security.utils.SSLContextWrapper.<init>(SSLContextWrapper.java:48)
at weblogic.security.utils.SSLContextWrapper.getInstance(SSLContextWrapper.java:43)
at weblogic.security.utils.SSLSetup.getSSLContext(SSLSetup.java:238)
at weblogic.security.SSL.SSLClientInfo.getSSLSocketFactory(SSLClientInfo.java:101)
at weblogic.socket.ChannelSSLSocketFactory.getSocketFactory(ChannelSSLSocketFactory.java:170)
at weblogic.socket.ChannelSSLSocketFactory.createSocket(ChannelSSLSocketFactory.java:77)
at weblogic.socket.ChannelSSLSocketFactory.createSocket(ChannelSSLSocketFactory.java:114)
at weblogic.socket.BaseAbstractMuxableSocket.createSocket(BaseAbstractMuxableSocket.java:133)
at weblogic.rjvm.t3.MuxableSocketT3.newSocketWithRetry(MuxableSocketT3.java:206)
at weblogic.rjvm.t3.MuxableSocketT3.connect(MuxableSocketT3.java:375)
at weblogic.rjvm.t3.ConnectionFactoryT3S.createConnection(ConnectionFactoryT3S.java:34)
at weblogic.rjvm.ConnectionManager.createConnection(ConnectionManager.java:1773)
at weblogic.rjvm.ConnectionManager.findOrCreateConnection(ConnectionManager.java:1416)
at weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:437)
at weblogic.rjvm.ConnectionManager.bootstrap(ConnectionManager.java:315)
at weblogic.rjvm.RJVMManager.findOrCreateRemoteInternal(RJVMManager.java:251)
at weblogic.rjvm.RJVMManager.findOrCreate(RJVMManager.java:194)
at weblogic.rjvm.RJVMFinder.findOrCreateRemoteServer(RJVMFinder.java:238)
at weblogic.rjvm.RJVMFinder.findOrCreateInternal(RJVMFinder.java:200)
at weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:170)
at weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:153)
at weblogic.jndi.WLInitialContextFactoryDelegate$1.run(WLInitialContextFactoryDelegate.java:344)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:339)
at weblogic.jndi.Environment.getContext(Environment.java:315)
at weblogic.jndi.Environment.getContext(Environment.java:285)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:117)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
I have define the following parameters:
-Djava.protocol.handler.pkgs=weblogic.net -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreType=JKS -Dweblogic.security.CustomTrustKeyStoreFileName=keystore -Dweblogic.security.CustomTrustKeyStorePassPhrase=passphrase -Dssl.debug=true -Dweblogic.StdoutDebugEnabled=true
How can I fix it? Same source and same parameters is working in Windows.
Thank You.
Finally, We got the solution.
Just add webserviceclient+ssl.jar to your classpath will solve the problem.
Are you using the same JVM vendor on both machines?
Most likely the CA used to generate the keystore is available on the Windows truststore but not available on Solaris, the assumption being the keystore was generated in Windows and the CA is not yet shipped with the JRE being used on Solaris. The differences are discussed here.
How to configure the truststore to add a CA
Are you sure that you
keystore
file is picked up? Maybe try to use an absolute path when specifying the-Dweblogic.security.CustomTrustKeyStoreFileName
option.Also, are the classpath of the JMS client really identical in both environments?
Try to provide
wlserver_10.3/server/lib/wlfullclient.jar
(that you create by running the commandjava -jar wljarbuilder.jar
) andwlserver_10.3/server/lib/wlcipher.jar
(yeah,wlfullclient.jar
is not that full!) on the classpath.This has been simplified for 10.3.4 and above Weblogic.
Just add the wlthint3client.jar from the /server/lib directory to your client's Classpath
I've only confirmed this works for ejb communication but the docs state
http://docs.oracle.com/cd/E17904_01/web.1111/e13717/wlthint3client.htm
This solution comes a bit late in the day, but is meant for others having the same problem.
Apparently, the accepted solution of adding webserviceclient+ssl.jar to the classpath works, since the WebLogic Full Client - wlfullclient.jar has references to other JARs in its MANIFEST.MF file. Adding the webservices client JAR resolves the issue, since it appears to have the minimum set of classes required for correct operation of the client when using SSL/TLS. The error is usually encountered when copies of the wlfullclient.jar and wlcipher.jar are made in a different directory, and added to the classpath. The JVM then fails to load other dependent classes from JARs that are referenced from within the MANIFEST file.
The actual solution would be to add the wlfullclient.jar that is generated in the WL_HOME\server\lib directory, to the CLASSPATH. All other dependent JARs would then be picked up via the appropriate classloader, since the manifest references these via relative directory paths.