The problem:
I'm working on a legacy project (with unreliable documentation) featuring some signed-applets, compiled with a specific jdk (1.6.0_45) that's been handed down from dev to dev along with the project.
Recently, I've had to make a minor modification on those applets, and while the newly compiled and signed version works like a charm on our company's computers, they refuse to load on the users' machines, which have stricter security rules.
The error message we're getting is the following:
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
It's worth noting that, on an other server, an unmodified version of those applets runs perfectly fine, so the error is definitely on my side, not on the users'.
What could be the security rules that are blocking those applets on the users' machine? What can I do to give those applets proper clearance?
Additional info
the server that hosts the project runs an Apache and a Tomcat instance, Tomcat serving most of the website, but Apache being apparently required to serve the applets.
I've checked the Tomcat's TrustKeystore, which appears up to date with the user's private certificates. I don't know where I can perform a similar check on the Apache side of the server.
I also don't know where the users' specific security rules are defined. I checked their java "security" folder, but everything in it is default.
Edit:
I've used the jarsigner utility to check the signatures on the jar, and while the ones I've updated, the ones that don't work, have valid current certificates, the ones I've left alone, that still function, have expired certificates.
Would it be possible that the user is working with outdated certificates, getting an OK on the expired signatures of the old applets, but blocking on the up-to-date ones? How can I check that?
Related
I'll start out by saying that security certificates in general are still pretty much a black box to me.
I'm writing a simple Spring Boot Java application that is attempting to access a REST service. I believe I have the plumbing set up correctly, but am running into a security issue related to certificates (or maybe lack thereof). When I execute my call, I get an exception that boils down to the following:
Caused by: 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 have searched the web, including SO and found tons of posts and responses. From what I can tell, the predominant solution is that I need to add the cert of the site I'm attempting to access to the Java keystore via the keytool utility that is part of the JRE. The exact process to follow (up to date for any changes in the tool and the cert data files themselves) is a little unclear. (If anyone can point to an up-to-date process that would be great.)
What I really would like to know is: Is there an alternative to the solution mentioned? Is there a way to provide the certificate information to the Java application "on the fly" without having to store it in the Java keystore?
We have recently needed to change our SSL certificate on our server. Our consuming application has suddenly stopped working. I had presumed this was to do with Java's cacerts, and modified the program to import the new certificate to each client, the problem was not resolved.
When the application attempts to load the remote view (shown below) on the server, it simply loads a white page. I have tried loading the page through http:// and it seems to function, however the rest of the application (including the API) requires https, and subsequent calls to the API fail (images loaded through https are showing as broken within the app).
The website is functional, and when I access URL's being provided to the app, through my desktop browser they load without issue. The app is also functional when I run it in Debug mode, these issues only occur when I use the "Run" build mode.
I have tried creating a blank MAF application, hoping it was some caching issue, however this new app also cannot load the remote URI. I have done a clean build and have tested other remote URI's (they work). I feel as if there is an issue with Java somehow not accepting the new certificate. The first time I tried to load the website within Eclipse's browser, an error displayed along the lines of "certificate revocation information". I didn't pay much attention to this error and it provided the option to install the new certificate, after which the page loaded within eclipse's browser.
In Jdeveloper there is an option of Disabling the Application Transport Security as shown in the image.
Could you try disabling in your eclipse too, Kindly refer this doc https://wiki.eclipse.org/Jetty/Howto/Configure_SSL, this might do a little help :)
The issue seems to be due to the changed SSL certificate on your server.
Short answer:
There was no chain installed, I installed the provided ca-bundle file and updated the httpd.conf file to reflect the chain location and the app now works.
Long answer:
When our server dev installed the new certificate, he neglected to install the ca-bundle (certificate chain) provided by the CA. The site was working in a browser, I can only assume, because it has a more complete list of trusted CA's built in. My best guess is that MAF requires the chain to be installed and was failing some security test, or the chrome webview it uses did not have this CA on the trusted list.
I am building an application in Java which I would like to make rest calls to https services. The application is written in Java Standard Edition.
I am using If This Then That as a test but I want the application to connect to any https site that the user types in.
For IFTTT I use the following URL:
https://maker.ifttt.com/trigger/{my_event} /with/key/{my_app_key}
I get the following error:
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I think this error means that the root certificate used for IFTTT is not in my cacerts truststore. I understand a solution to this problem may be to add it. According to chrome the certificate path terminates at a root certificate names “Go Daddy Root Certificate Authority – G2”.
I guess if I add this to my cacerts using keytool it will work. However I expect users of my application to type in various URL’s. I don’t want to only allow a particular subset of the internet. I also don’t want to disable certificate checking.
Chrome, IE and firefox all recognise the IFTTT site without a problem.
Why doesn’t the standard cacerts file in Java recognise this?
Can I get Java to use a system cacerts file which includes all these sites? (This would have to work on Java on Windows, Max and various Linux flavours.)
For my education I often have to program math exercises for our site, which will be used in schools.
I had to port a .swf file to java applet, mainly because the .swf ran really slow.
The game/excercise worked fine in both Eclipse and my localhost, but when we put it on the site it always got blocked by Java.
I have read that you need a certificate, but that self signed certificates dont work.
I have tried to do it (Not sure if I was succesful), and the applet was still blocked.
What am I supposed to do to make it work?
Why don't you try Java Web Start instead of applets?
You chan check it at http://www.oracle.com/technetwork/java/javase/applet-migration-139512.html
From https://www.java.com/en/download/help/java_blocked.xml
Java has further enhanced security to make the user system less
vulnerable to external exploits. Starting with Java 7 Update 51, Java
does not allow users to run applications that are not signed
(unsigned), self-signed (not signed by trusted authority) or that are
missing permission attributes.
So, from Java 7 Update 51, users cannot run unsigned application (without a certificate), self-signed application (applications signed with a certificate that doesn't come from trusted authority), or applications missing Permission Attribute.
As the documentation says about self signed applications,
Applications of this type present the highest level of risk because
publisher is not identified and the application may be granted access
to personal data on your computer.
Also, as stated in the documentation, if you can still use self signed applications you need to add it to the exception site list,
As a workaround, you can use the Exception Site list feature to run
the applications blocked by security settings. Adding the URL of the
blocked application to the Exception Site list allows it to run with
some warnings.
I've made a Java applet and I self signed it before, but due to security changes in recent Java updates, self signing no longer gives the applet the necessary permissions.
I need the applet to be able to read the local file system to use images and to be able to connect to a MYSQL database.
The applet used to work with the database when I self signed it, but not anymore.
In addition, many unknown users will be using the applet, so I won't have control over their machines.
Where can I get my applet professionally signed and if possible, is there another way to self sign that will make the applet work?
Purchase a certificate from any reputable certificate authority. Use that to sign your code. List of CAs
Or, some companies also do this: Sign the jars themselves, but pre-populate the JDK trust store with your (self created) CA cert. If you have control over the JRE that is installed on all user machines, you can place your certificate in JRE/lib/security/cacerts so that is trusted ahead of time.
update: This page (Java Control Panel Documentation) describes what type of signature is required for various client side security level settings:
As long as the applet 'phones home' to the DB & this demo. of the JNLP API file services1 works for the problem machines you should be set to go for a Plug-In 2 JRE (1.6.0_10+) JRE. And if the client has less than that, they should seriously look to update. The Deployment Toolkit Script can assist with that.
It is relevant in that:
It uses a self signed certificate
It allows a sand-boxed app. to read/write to the local file system.
An applet launched using JWS has access to the API.
This should only be considered a work-around. The correct way to solve the problem is to heed the advice offered to get a certified code certificate. Oracle seems to be heading towards making it so that unsigned or self-signed code will not just be sand-boxed, but entirely forbidden (& that is for the best).
As an aside re. DB access: For the protection of the DB. The applet should be forced to go through a 'public interface' (via the site that hosts the applet). Do not give the applet direct access to the DB. Otherwise hackers also have direct DB access.