After upgrading to Java 7, when launching remote jnlp, I see the following exception in the Java console:
java.security.KeyStoreException: WIExplorerMy not found
at java.security.KeyStore.getInstance(Unknown Source)
at com.sun.deploy.services.WPlatformService$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.services.WPlatformService.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.applet.context.InitialJNLPExecutionContext.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.main.client.DisconnectedExecutionContext.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.applet.Applet2BrowserService.getBrowserClientAuthKeyStore(Unknown Source)
at com.sun.deploy.security.X509DeployKeyManager.<init>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler$Initializer$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.net.protocol.https.Handler$Initializer.<clinit>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler.openConnection(Unknown Source)
at java.net.URL.openConnection(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.createUrlConnection(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.NoSuchAlgorithmException: WIExplorerMy KeyStore not available
at sun.security.jca.GetInstance.getInstance(Unknown Source)
at java.security.Security.getImpl(Unknown Source)
... 26 more
In addition the error screen saying "Error. Click for details" appears for about 2 seconds and disappears afterwards.
Other then that, everything seems to function normally.
With Java 6 everything works as expected.
Ideas how to fix it?
I think some of the latest Java 7 updates have obsoleted some encryption schemes, so that would be a completely normal exception to get if you were using one of these while using Java 6.
See this list of enhancements and changes for Java 7:
Weak cipher suites deprecated
Per RFC 4346, RFC 5246, and RFC 5469, some cipher suites have been made obsolete and should not be used. These obsolete suites are all disabled by default in SunJSSE. For details, consult the cipher suite lists in the documentation about the SunJSSE provider.
That being said, that would explain the NoSuchAlgorithmException, but the error message seems to mention something about a missing keystore, so this may be unrelated and we woud need you to provide a SSCCE or anything close enough to one.
I solved this problem by adding
security.provider.11=com.sun.deploy.security.MSCryptoProvider
to C:\Program Files\Java\jre1.8.0_31\lib\security\java.security
Although the error wasn't fatal for me, it is just the javaws trying to read the local browser key store before falling back to the java keystores that are managed by the control panel. Those files are in C:\Users\USERID\AppData\LocalLow\Sun\Java\Deployment\security
Interestingly there is a security provider that comes pre-wired into the java.security file, and it is
security.provider.10=sun.security.mscapi.SunMSCAPI
This provider can also read the browser keystore, but the store type is windows-my, and not WIExplorerMy
Tarlog, do you have any resolution found yet? I have the same problem, I am suspecting that the first problem with KeyStoreException exception only happens if you are trying secure connection. And that sinister "Error. Click for details" issue happens on any Applet loaded through an jnlp.
I could not find any resolution yet.
Edit: For the KeyStoreException I have realised that the problem occured due to apache certificate files were gone somehow. I have generated ceritificate files and restarted apache. The exception no longer occurs.
The other problem with Error window still exists.
With regard to the Error Click for details issue – I resolved this by adding a class to the source that implements javax.jnlp.DownloadServiceListener (can just be a dummy class) and then specifying that class in your jnlp file (applet-desc/#progress-class="YourClass")
Related
When using Java 8 update 162 and older in Internet Explorer, the applet loads and works as expected. When removing Java 8 update 162 and install Java 8 update 171 or 172, the applet errors with ClassNotFoundException referencing the class listed in the code attribute of the applet tag. I don't see any reason for this in the 171 or 172 release notes or the 171 or 172 bug fixes. I'm using Windows 10 Pro version 1709 build 16299.371. The applet is signed with a certificate that is trusted and still valid. There aren't any exceptions in the Exception Site List and adding an exception for this site (it worked fine without one on Java 8u162) still displays the exception. Using Java 8 update 162 and older is still working on another PC.
When clearing the Application cache in the Java configuration, the applet's JAR file doesn't appear again in the cache.
Are you aware of any changes in Java 8u171 or 172 that affect applets? Do you have any suggestions to resolve this?
Update 1: I'm aware that applets are deprecated in Java 9 and that applets don't work in Firefox and Chrome, but this is in Internet Explorer.
Update 2: I'm also aware that the 3DES Cipher Suites have been disabled in the update to 171 and 172, but the current digest algorithm is SHA-256 and the signature algorithm is SHA256withRSA with a 2048-bit key, which matches the signing certificate's signature algorithm and key. I've even tried signing the applet using Java 8 Update 172 without altering java.security to remove 3DES_EDE_CBC and using that version the ClassNotFoundException still persists as expected.
Update 3: When using Fiddler 4 or Charles as a proxy for Internet Explorer and capturing traffic between the server and the browser, the applet loads and works as expected. Both the Java SE Runtime Environment 8 Update 172 and Java Plug-in 11.172.2 Add-ons are set to Allow on all sites. When I clear the applet from the Resources cache using the Java Cache Viewer in the Java Control Panel, the applet doesn't download in the cache again without the proxy, but if I use a proxy again then it does download into the cache. My guess is that the proxy traffic is being treated as local and so has different permissions. Any other ideas or what permissions it could be?
Update 4: Enabling the debugging options in the Java Control Panel causes the full stack trace to show, where CODE_ATTRIBUTE_VALUE is the value I set on the code attribute of the applet tag. The applet's JAR file doesn't seem to be downloading even though I list it in the archive attribute.
java.lang.ClassNotFoundException: CODE_ATTRIBUTE_VALUE
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The Java Console now also shows more details about the connection and I see the following which is the cause:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$900(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(Unknown Source)
... 40 more
Currently the applet is hosted on Windows Server 2003 using IIS. Moving it to Windows Server 2008 also using IIS causes that problem to go away. Mr. Laitinen was right the TLS connection was using 3DES_EDE_CBC.
JAVA_HOME\lib\security\java.security
Update 171 adds 3DES_EDE_CBC to the list of disabled algorithms (jdk.tls.disabledAlgorithms). Remove it and your applet will work again.
Faced the same issue and it comes down to Update 171 no longer supporting TLS 1.0.
Our webserver was old and only supported TLS 1.0 so the download of the Applet was failing and this could be seen in the Java Console, the connection was being closed.
Upgraded the webserver to support TLS 1.2 and it all works again.
My actual problem is a derivation of the title, but the title is the root cause of my issue:
I am developing a java web application at work. The server my application is to be deployed on, only accepts java 6 or lower (WebLogic 10.3.2)
I need to call a web service in my application. My experience in this area is limited. I have been able to make it work, but when I integrated my code into the web application, compiled and tested it, I got this error:
Exception in thread "main" java.lang.ClassCastException: sun.reflect.generics.reflectiveObjects.GenericArrayTypeImpl cannot be cast to java.lang.Class
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.createArrayInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.createArrayInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.getTypeInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.ElementInfoImpl.<init>(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RuntimeElementInfoImpl.<init>(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.createElementInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.createElementInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.RegistryInfoImpl.<init>(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.addRegistry(Unknown Source)
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.getTypeInfo(Unknown Source)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(Unknown Source)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(Unknown Source)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(Unknown Source)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(Unknown Source)
at com.sun.xml.internal.bind.api.JAXBRIContext.newInstance(Unknown Source)
at com.sun.xml.internal.ws.developer.JAXBContextFactory$1.createJAXBContext(Unknown Source)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(Unknown Source)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.createJAXBContext(Unknown Source)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.postProcess(Unknown Source)
at com.sun.xml.internal.ws.model.RuntimeModeler.buildRuntimeModel(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.createSEIPortInfo(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.addSEI(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)
at javax.xml.ws.Service.getPort(Unknown Source)
at com.example.mypackage.MyClient.invokeService(MyClient.java:64)
at Test.main(Test.java:7)
I have traced this error back to being a java version issue. It works in 7, but the Exception is thrown on method execution, if I compile in 6, which I have to do for the web app. The line where my exception is thrown, is the one with NotificationRecieverSoapInterface.class below:
NotifikationRecieverSoap service = null;
try {
service = new NotifikationRecieverSoap(new URL("[myURL].svc?wsdl"));
} catch (MalformedURLException e) {
e.printStackTrace();
}
NotificationRecieverSoapInterface notificationService = service.getPort(NotificationRecieverSoapInterface.class);
notifikationService.createNotificationRequest(logHeader, loginModule, parmV, priority, recipients);
The Service.getPort()-method seems identical in the two java versions, so I'm at a loss there. the sun.reflect.generics.reflectiveObjects.GenericArrayTypeImpl are also identical in 6 and 7.
The closest thing I found to a similar problem online, was this: http://forum.spring.io/forum/spring-projects/container/26020-classcastexception-genericarraytypeimpl-cannot-be-cast-to-class. Unfortunately, the solution here was that there is a bug in Spring, which I am not using...
Does anyone know more specifically what my problem is, and if it can be worked around, using only Java 6?
I do have a lot more code to show. I have chosen the parts I think is most relevant to the problem. I can provide jax-ws-generated classes for data structure, or sample xml's as well, on request.
Ok... I used this method to generate the web service classes: http://www.mkyong.com/webservices/jax-ws/jax-ws-wsimport-tool-example/
I realized that I had used a 1.7 JDK when calling the wsimport.exe. This was incompatible with my 1.6 project. After regenerating the classes with the wsimport.exe found in the correct JDK 1.6, the java classes were slightly different, and compatible with my project's setup.
I'm trying to run a java JNLP-based application.
It works fine from home : javac+javaws are the same v.1.8.?
Now I'm trying to run my application at work. I'm working behind a proxy and I used the Controlpanel to tell java to bypass the proxy for our local server hosting the JNLP.
On the server side, the aplication is compiled with
javac 1.7.0_60
On the client side, I'm trying to run it with:
$ javaws -version
Java(TM) Web Start 11.40.2.26-fcs
$ java -version
java version "1.8.0_40"
Nevertheless, I get the following exception in javaws
javax.net.ssl.SSLHandshakeException: com.sun.deploy.security.RevocationChecker$StatusUnknownException
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1512)
at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90)
at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1432)
at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1430)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessController.doPrivileged(AccessController.java:713)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1429)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.Launcher.updateFinalLaunchDesc(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Caused by: com.sun.deploy.security.RevocationChecker$StatusUnknownException
at com.sun.deploy.security.RevocationChecker.checkCRLs(Unknown Source)
at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
at com.sun.deploy.security.RevocationCheckHelper.checkRevocationStatus(Unknown Source)
at com.sun.deploy.security.X509TrustManagerDelegate.checkTrusted(Unknown Source)
at com.sun.deploy.security.X509Extended7DeployTrustManagerDelegate.checkServerTrusted(Unknown Source)
at com.sun.deploy.security.X509Extended7DeployTrustManager.checkServerTrusted(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
... 33 more
I read https://community.oracle.com/thread/3651870?start=15&tstart=0
But I don't really understand what I should do.
For example, I've commented out <>/lib/security/java.security
#jdk.tls.disabledAlgorithms=SSLv3
but that still doesn't work. As I see a 'getInputStream' in the stacktrace, I wonder if javaws tries to download something outside the proxy ?
Any idea ?
EDIT: the JNLP works if,in the controlPanel, I check
Perform signed code: do not check (not recommended)
Perform TLS certificatie revocation: do not check (not recommended)
is this problem linked to my proxy server ?
Java certificate revocation checking uses one or both of these methods:
Certificate Revocations Lists (CRLs)
This method needs lists to be generated and published periodically by Certificate Authority (CA) to keep the it current.
Online Certificate Status Protocol (OCSP)
This method performs a real time certificate status check with CA making it more reliable and faster.
If your server certificate is self-signed, or your company has an internal CA, your JRE may not be able to complete the revocation check properly -- hence the "Unknown" status. If you want to run with revocation checking on (and usually you do), you will need certs signed by a CA that supports one or both of these methods.
It is also important to remember that there are potentially two certificates in play here:
The cert used to sign the JARs; and
The cert used to connect to the server
Both certs must be signed and valid (that is, not revoked) in order for the handshake to succeed.
I'm trying to connect to Openshift from Eclipse Mars IDE.
I can very well login to my Openshift account on the web.... Also, going by the error message, I even created new private/public keys and retried connecting but still to no avail. Then I ran a JBossTools update, and tried again, yet no solution.
Here's the closest JBoss Tools BugTrack that I found related to my case, https://issues.jboss.org/browse/JBIDE-14760, but it turns out this is recorded as fixed since JBossTools 4.1.0, whereas I have 4.3.0 on both Mars and Luna
What's even more disturbing is the fact that I've previously been able to make this connection some time ago with Eclipse Luna, then I went back to Luna and tried again but still was unable to make the Openshift connection.
See screenshots of the error messages below;
Eclipse Mars (Error Screenshot below);
Eclipse Luna (Error Screenshot below);
And following is the StackTrace from the logs looks as follows:
!ENTRY org.jboss.tools.openshift.express.ui 4 4 2015-10-09 18:05:58.143
!MESSAGE Could not request https://openshift.redhat.com/broker/rest/api: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
!STACK 0
com.openshift.client.OpenShiftEndpointException: Could not request https://openshift.redhat.com/broker/rest/api: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at com.openshift.internal.client.RestService.request(RestService.java:120)
at com.openshift.internal.client.RestService.request(RestService.java:92)
at com.openshift.internal.client.AbstractOpenShiftConnectionFactory.getConnection(AbstractOpenShiftConnectionFactory.java:36)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:198)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:158)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:114)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:103)
at org.jboss.tools.openshift.express.internal.core.connection.Connection.createUser(Connection.java:229)
at org.jboss.tools.openshift.express.internal.core.connection.Connection.connect(Connection.java:205)
at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPageModel.connect(ConnectionWizardPageModel.java:247)
at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPage$ConnectJob.run(ConnectionWizardPage.java:479)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: com.openshift.internal.client.httpclient.HttpClientException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:201)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:161)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:140)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.get(UrlConnectionHttpClient.java:99)
at com.openshift.internal.client.RestService.request(RestService.java:160)
at com.openshift.internal.client.RestService.request(RestService.java:107)
... 11 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:184)
... 16 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker.process_record(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:157)
... 15 more
Caused by: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.security.ssl.DummyX509TrustManager.checkServerTrusted(Unknown Source)
... 29 more
Similar SO posts such as this have offered little or no concrete help either.
Thanks.
please make sure you use latest JDK version since older ones had issues with ssh after heartbleed.
if you see something else please report issue in https://jira.jboss.org/jira/browse/JBIDE
Ok here's what I did and afterwards I was able to establish the Openshift connection from Eclipse Mars
I suspect it was an outdated windows installer problem because all I did was just attempt to re-install my Eclipse Mars which i got from here
NOTE - in my previous installation, I did not notice the update option in the installer so I installed without updating. Well, I believe that copy did not contain the Bug Fixes that solved this particular problem
However, when I attempted to re-install, i noticed the update icon at the top right corner (see image below) so I first of all updated before continuing with the installation process. I guess this just downloaded and applied all the bug fixes before installing.
Afterwards, I tried to establish the OpenShift connection from within my Eclipse Mars IDE without changing anything (...when I say 'anything', I mean my public/private key pair), and Voila, the connection got established.
I hope this helps anyone who runs into this problem and bumps into this post.
is it possible to use java.util.Logging and log to a file in a java webstart application?
I have the following logging code:
Handler fh = new FileHandler("myapp.log");
Logger.getLogger(MyApp.class.getName()).addHandler(fh);
and got the following exception:
java.security.AccessControlException: access denied (java.util.logging.LoggingPermission control)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.util.logging.LogManager.checkAccess(Unknown Source)
at java.util.logging.Handler.checkAccess(Unknown Source)
at java.util.logging.FileHandler.(Unknown Source)
at whoisapiclient.WhoisAPIClientApp.main(WhoisAPIClientApp.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The access control exception says this:
"access denied (java.util.logging.LoggingPermission control)"
The javadoc for the permission class says this:
"Currently there is only one named LoggingPermission. This is "control" and it grants the ability to control the logging configuration, for example by adding or removing Handlers, by adding or removing Filters, or by changing logging levels."
What you are doing clearly falls under the "control" permission.
You will need to sign your application if it is to create/add its own log handlers.
Incidentally, if you did manage to work around the LoggingPermission("control"), you would then run into another access issue in opening the log file.
Both problems are solved by signing the application. You've then got the problem that the user has to accept / trust your signing key. But that is fair enough! As far as the Java security sandbox can tell, what you are doing could potentially damage the user's machine.
Have you tried specifying an absolute path? Perhaps the issue is that you don't have access to the current working directory of the application itself.