We Keep Coding

Is there a way to provide certificate information "on the fly" to a Java application?

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?

Which controls are performed before downloading a signed-applet?

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?

Java SSLHandshakeException in VeriSign signed certificate

In a Java desktop application I need to connect to a SSL URL. When I try it, I get the exception:
SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
To solve it, I go to the address with my browser, download the certificate in .cert file and import in my java cacerts keystore using keytool command. After this, the application works fine.
My question is: why java don't recognize the certificate if this is signed with VeriSign? VeriSign certificate is not installed in cacerts keystore by default?
Maybe I don't understand how SSL works. What's the difference between browser and java desktop behavior? I can connect to this URL with my browser without installing nothing.
Thanks

When we access a secure site which uses SSL for providing identity and encryption, it provides a certificates which was verified by a trusted third party sites like verisign, godaddy or thwate.
By using certificates browser or java clients knows that they talking to the correct site (who it claims to be) and not on redirected proxy site. this step is pretty transparent if you access websites using browser because if certificate is not on browser's trusted store it will ask you to add that certificate and it will be subsequently added.
But when you access a secure site using Java program, this step of certificate hand shaking is not transparent to user and certificates are verified form JRE's trustStore.
Read more: http://javarevisited.blogspot.com/2012/03/add-list-certficates-java-keystore.html#ixzz32v1wL3Gl

You did not say which certificate you imported into the keystore. Usually there are several certificates involved in the verification:
the trusted root certificate, which is stored in the keystore or browser (Java does not share the keystore with the browser)
the leaf certificate which identifies the site
and most times also intermediate certificates, which provide a signed way from the leaf certificate to the trusted root and thus establish a trusted path
If any of the intermediate certificates is missing, the verification fails.
So the server has to send not only the leaf certificate, but all intermediate certificates too. And this is where lots of sites fail, e.g. they don't provide the full certificate chain.
But why does this work in the browser?
Because enough sites fail to provide the intermediate certificates and because the browser wants to provide the best experience, they will cache the intermediate certificates. Thus, if you go to one site signed by verisign which provides the trusted chain, and then go to another site signed with the same certificate, but which does not provide the chain, then it will still work, because the chain certificates are cached from the other side.
But, if you use a fresh system (or simply a new browser profile with firefox) and visit the misconfigured site first, it will complain there too, as much as the Java application did. And if you just import the relevant intermediate certificate into the keystore and thus trust it it will work too, because it does not need the rest of the chain to get a path to a trusted certificate.

Can't access blockchain.info from java due to missing certificate

I'm trying to access https://blockchain.info/lastblock from java,
but the code throws:
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
This is usually due to self signed certificate, but this one is not self signed(you can check it in your browser). Looks like java doesn't user system CA certificates.
Isn't it a bug?
I exported the certificate and insert it dynamically into java KeyStore, but I don't like this solution(Not sure it will check revocation lists for this certificate etc).
So what's the best solution to fix the problem?
I used this code to test http://www.cs.ucsb.edu/~pconrad/cs56/examples/ldap/SimpleQuery/InstallCert.java

The list of roots of trust changes from time to time, and Java's built-in one is often a little different to that of browsers. Those trust roots are what is stored in the system keystore (well, technically in the system truststore) and you can add to them by placing the extra roots that you want to support in a per-user keystore, stored in your home directory. It's in the default location manipulated with keytool.
The certificate that you'd actually consider putting there — if it isn't already — would be the “COMODO Certification Authority” one; browsers like it (i.e., you can verify it independently of Java) but your Java doesn't. It has revokation information signed directly into it, so it should be all you need; SSL/PKI is supposed to be able to be bootstrapped from just the root CA certificates.

Downloading files over HTTPS with unverified SSL certificate

My Java program uses GitHub's raw address to access a version file to get the latest version. This address is in the format https://raw.github.com/user/repository/branch/version_file
During testing stages, I had no problems using this with the following code:
currentVersion = new Version(plugin.getDescription().getVersion());
URL url = new URL("https://raw.github.com/zonedabone/CommandSigns/master/VERSION");
URLConnection connection = url.openConnection();
BufferedReader in = new BufferedReader(new InputStreamReader(connection.getInputStream()));
newestVersion = new Version(in.readLine());
if (currentVersion.compareTo(newestVersion) < 0)
newAvailable = true;
However, some users have complained of 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
Java is complaining that it can't validate the SSL certificate. GitHub's certificate is verified by DigiCert, but apparently some Java builds won't identify this.
I have read there are two ways to overcome this: adding the certificate to the TrustStore and disabling the validation altogether.
The answers suggested on StackOverflow either make use of an allow-all TrustStore, which would be a really bad idea considering it's not within bounds of a 'test environment', or if they show how to add the certificate, they usually link to a broken web page.
Can somebody provide new information?

First the theory... As the JSSE Reference Guide says:
IMPORTANT NOTE: The JDK ships with a limited number of trusted root
certificates in the /lib/security/cacerts file. As
documented in keytool, it is your responsibility to maintain (that is,
add/remove) the certificates contained in this file if you use this
file as a truststore.
Depending on the certificate configuration of the servers you contact,
you may need to add additional root certificate(s). Obtain the needed
specific root certificate(s) from the appropriate vendor.
Users should maintain the list of CA certificates themselves. A number of people won't know how to do it, unfortunately. They could use another JRE's cacerts file (more recent) into their own installation.
You could use a trust manager that trusts any certificate and use it specifically for that connection, but that's not a good idea, since it opens the connection to potential MITM attacks. There are enough examples of code for this insecure solution around.
The best solution, if you want to trust a specific certificate, is to load it correctly using a specific truststore, as described in this answer. You could even load this trust store from an InputStream from the classloader if you want to bundle it with your application.
Alternatively, where possible, you could use the OS trust store directly. On Windows, you can load the Windows-ROOT keystore as described in this article. On OSX, you can load a KeychainStore.

You can implement an HttpsUrlConnection with "all"-TrustManager
like http://bitsandcodes.blogspot.de/2010/08/create-trust-manager-that-trust-all-ssl.html