Hopefully this simple, but undocumented fix helps save you some time if you run across a similar Java error when trying to run your Cisco ASDM or Cisco UCS Manager console.
I spent hours last night, and a few more this morning trying to figure out why I could no longer launch my Cisco UCS Manager console. It was working fine yesterday…
Even after a reboot, no luck… On top of that, my ASDM console was now broken as well. Time to put on the troubleshooting cap!
com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://x.x.x.x/ucsm/unpacked/ccore.jar
Looking into the Java console for more detail showed a bit more detail:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://x.x.x.x/ucsm/unpacked/ccore.jar
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)javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Java couldn’t trust Server
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.https.HttpsURLConnectionImpl.connect(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequest(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.cert.CertificateException: Java couldn’t trust Server
at com.sun.deploy.security.X509Extended7DeployTrustManager.checkServerTrusted(Unknown Source)
… 24 mo
In the interest of your time, I’ll post the solution to the issue first and then go through the troubleshooting steps I used. You can stop reading if the fix works for you, or read on if you’ve got too much free time.
Solution for Windows 7/8 OS users:
Delete the following three folders:
- C:\Users\username\AppData\Local\Sun
- C:\Users\username\AppData\LocalLow\Sun
- C:\Users\username\AppData\Roaming\Oracle
That’s it! Once I deleted those three folders, I was able to launch both the Cisco UCS Manager and the ASDM consoles without any issues. Where was this info before I spent hours uninstalling and re-installing other versions of Java? If you’re ready for some ZZZZZs, here are the rest of the troubleshooting steps I took based on various KB articles and forum posts I found while searching for an answer:
- Installed Java 6 Update 45 alongside my running instance of Java 7 update 25… fail!
- Uninstalled Java 6u45 and Java 7u25 completely and performed a clean install of Java 6u45… fail!
- Uninstalled Java 6u45 and performed a clean install of Java 7u21… fail!
- Uninstalled Java 7u21 and performed a clean install of Java 7u25 32-bit and 64-bit… fail!
- From the Java Control Panel, I emptied any Temporary Internet Files and deleted any cached security certificates… fail!
- Created a new Java keypass file… fail!
- Attempted to install Java in a directory with no spaces (c:\jre7) and launch the jnlp file from there… fail!
- Ran JavaRA, a commonly used Java cleanup utility to try to remove all traces of Java… fail!
- Searched the registry, but didn’t find any traces of Java left, so I looked to the file system. The three folders I mentioned above remained after every full uninstall I performed… hmmmm!
I had read a few forum posts from users who were only able to fix their problem by re-imaging their computers, or deleting and re-creating their Windows profile. This led me to search for the remaining orphaned files and find the root cause of the issue. I would have thought that these files would have been deleted by the Java uninstaller or even the JavaRA removal tool. In any case, I hope this post helps save some time in the future if you come across a similar situation.
Thanks for the tip. Didn’t quite work for me as it did for you. I ended up having to re-launch & reinstall the ASDM from the SSH browser page. It was the same version as I already had, but it somehow worked after the reinstall. I think it had to do with a recent Java update. Anyway, thanks for the suggestions.
I found another solution. It appears that certificate for the console isn’t being trusted anymore. If you go to the ip address of your firewall in Internet Explorer and add the certificate to both the Trusted Root Certificate Authorities and Trusted Publishers stores it will again be trusted and allow you to log into the console.
To do this:
View the certificate
Click the Install Certificate button
Hit Next
Select ‘Place all certificates in the following store’ and then click Browse.
You’ll have to run through the certificate import wizard twice to get both stores, but that should resolve the trust issue.
Holy shit dude.. I just spend hrs trying to get UCS Manager to open… Installed / Reinstalled Java 20 times diffrent versions 6,7,8 Beta etc.. Deleted the folders you listed and it just worked!!
I got the same issue and the solution is import SSL certificate of the ASA to Certificate Snap-in:
– Open https:\\asaipaddress
– Export certificate to ABC.cer (up to browsers)
– Start\Run => mmc
– File => Add\Remove Snapin
– Select Certificate \ Computer Account \ Local Computer
– Import ABC.cer to:
– Personal
– Trusted root certification authorities
– Intermediate certification authorities
– Done
Thanks…!
Andrew, thanks for posting this. I was having a similar problem trying to run two different versions of UCS manager for two different systems. I was able to run the older UCS manager 2.2(1c) fine from both my Mac (El Captian 10.11.1) and my Windows 7 VM running on Fusion on my Mac. I was working on a new system running 2.2(6c) but I could not launch UCS Manager on either of my machines. Your fix above to delete the directories fixed my Windows 7 VM. Interestingly after logging back into the older UCSM, it breaks again and I have to delete those folders again to be able to run the newer UCSM. I still couldn’t get my Mac to work so I started looking for the same set of folders to delete. I found them in this directory:
/Users/myusername/Library/Application Support/Oracle/
Deleting the sub directories here on my Mac worked like a charm. Thanks!