I have a local environment with WebLogic 10.3.4 and and .ear app deployed on it. This app must communicate with external services via REST APIs. These external services are exposed in https and use wildcard certificates.
I receive the following exceptions when I try to connect to to one of these services.
org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://dds-service.domain.com" General SSLEngine problem; nested exception is javax.net.ssl.SSLHandshakeException: General SSLEngine problem [...]
[...] Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [...]
[...] Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
So what I tried in first instance was to open the same url the app tries to connect to in my browser, download its wildcard certificate (.cer Base64 encoded) and with key tool import it into the jvm's trust store that WebLogic loads and looks up when trying to validate a cert. I am sure is the correct one because i imported other certificates that caused the same error and also because of this log
<Loading trusted certificates from the jks keystore file C:\WEBLOG~1\wls\JROCKI~1.1-3\jre\lib\security\cacerts.>
At this point, I suppose the problem is related to the way I import the wildcard certificate in WebLogic. I tried to look for different ways to do it but, like this one, require a .pfx file that is not currently available to me at the moment.
Do I need a .pfx to solve this or is there another way?
If someone will ever have the same problem, here is the solution i found: it appears that WLS 10.3.x has issues in trusting certificates wth keys longer than 128 bits, this is what caused the problem in first instance. That said, 2 actions solved my problem
-DUseSunHttpHandler=true added as a VM argument in the setDomainEnv script
Enable JSSE SSL via WLS adminn console (Environment > Servers > server name > Configuration > SSL > Advanced > check the JSSE SSL box)
Click Save, and restart WLS server.
Related
I have a Rest web service developed in java, glassfish, running on a centos server.
We recently opted to use the https protocol and started testing through the test certificate provided by glassfish itself at deployment time (port 8181).
Using Postman for testing I just needed to disable one option in the configuration: "SSL certificate verification".
However the modules that consumed my service, service destop, in java, started to throw exceptions.
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
In test environment, windows, the lines below corrected the problem, already in production, hundreds, could not solve.
String certificatesTrustStorePath = "/etc/alternatives/jre_1.8.0/lib/security/cacerts";
System.setProperty("javax.net.ssl.trustStore", certificatesTrustStorePath); System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
The error in centos is the one presented in the post below, already read about the various reasons but could not solve.
Error - trustAnchors parameter must be non-empty
If you know how to solve in linux I appreciate it,but the question is not this ...
Do these lines I have published specify where the cacerts file is (and within my platform certificate)?
But it seems to me wrong ... I've already consumed third party https rest services and never had to specify the certificate path ... this would require me to know structurally some details of a third party server. Am I wrong?
So, I imagine there must be another way to do it ... could anyone help?
Yes, your code specifies a custom path for truststore where the ssl cert is present.
This is the public key shared corresponding to the https protocol for the handshake(either self-signed or signed by a whitelisted CA).
Default path where these get stored is
$JAVA_HOME/jre/lib/security/cacerts
Though above can be overridden.
So in your code, you have overridden the path, to point it where the public key(cert) is already present. Thus it's working for you.
Truststore is just a collection of public keys.
Alternatively, you can import the public key in the default truststore as well to make it work.
In that case, you don't have to explicitly set a different truststore.
There is many ways to do it.
copy your file to $java_home\jre\lib\security\cacerts\ than you don't have to set property manually.
you can also mention path at runtime using
-Djavax.net.ssl.trustStore=/home/user/SSL/mycacerts
-Djavax.net.ssl.keyStore=/home/user/SSL/serverkeystore.jks
I am trying to integrate MongoDB with hazelcast for distributed caching. The MongoDB has cluster servers and requires a password. When i do a get collection call in the MongoMapStore.java class following the example mentioned in
https://github.com/hazelcast/hazelcast-code-samples/blob/master/hazelcast-integration/mongodb/src/main/java/com/hazelcast/loader/MongoMapStore.java. I get errors such as
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.
etc. If it helps I could produce the entire stacktrace of the errors.
How can I solve this issue.
The error is likely due to a missing Certificate for your DB Server. Ensure your keystore has the required certificate(s). If you do have a the server's public key cert and want to load it, check,
How to import a .cer certificate into a java keystore?
I have an Apache web server fronting a Tomcat 8 web server that is running my website, and I'm switching the top-level domain from my.website.ie to my.website.com. I have some code that runs in response to a particular request that generates a PDF. That code fetches an image (using a URL) which is served from the same web server e.g.
Image.getInstance(new URL("https://my.website.com/img/myimage.png"))
In addition to the domain change, I'm also changing my SSL certificate provider to LetsEncrypt (free SSL certs). My development website at the new .com domain is running and the certificate is valid and does not expire for a number of months.
I have another development server running on a separate machine that is still using the .ie domain. The Tomcat codebase running on both of these servers are identical right now. They are both trying to fetch the image at the URL shown above in that particular piece of code.
On the .ie server, the request that generates the PDF works correctly, without any problems fetching the image. On the .com server, the request fails with this error:
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
...
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
...
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
My understanding of this error is that the certificate at the target URL is not trusted (e.g. self-signed), but that is not true in this case. Also, both of the servers are hitting the same URL for the image, so why is one server trusting the certificate and the other not?
I haven't made any additional configuration changes on the .ie server that I haven't made on the .com server (with respect to setting up the new certificate), so is there some other (mis)configuration that I haven't considered?
Not trusted means the used CA is not trusted by the software.
Self-signed certificates are never trusted.
Java has it's own trust store (only on Linux the system trust store is used AFAIR?). If the CA certificate is newer than the used Java version it may happen that Java does not trust the CA. Conclusion: Update your Java.
According to this Stackoverflow answer you need at least Java 8u101 for Let's Encrypt support:
Does Java support Let's Encrypt certificates?
The error says that the chain doesn't lead to a root certificate that is trusted. Trusted CA root certificates are stored in Java's root keystore where the root certificate issued by Let's Encrypt is obviously missing.
You can add the root certificate manually to the store or check if newer versions of Java already contain the certificate.
I have a web application using java 7 and tomcat 6 on ubuntu 12.04. It uses apache cxf to make REST calls to a web service on a different server over https. It has been working fine until about 11am today. Then for each REST call whether GET or POST, I receive
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
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 errors in catalina.out.
The certificate is in the
jdk/jre/lib/security/cacerts
and does not expire until 2018. When I restart tomcat the program runs fine.
Any idea what would trigger this?
Thanks in advance
Randy
If you are entirely certain that this is not a validity period problem with the service's certificate, here are some more situations to check for:
The certificate on the service side was changed so the one in cacerts is now not doing anything
The certificate you installed was the a system's certificate and you are now connecting to a different node due to load balancing (if so, you would need an intermediate or CA cert)
The service requires Mutual TLS (aka 2-way SSL) and the certificate on your side is now missing or invalid
A host name has changed such that the certificate(s) are no longer valid
Some software or configuration file has changed and now the client and service do not have SSL/TLS versions in common.
I have PKCS#12 keystore that I've sucessfully imported in my browser for accessing a server that needs 2-way SSL authentication. Works perfectly reaching any https URL there.
However, I'm unable to access an URL in the same server, and from the same host when using Axis 1.4. The given Axis faultString is:
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
My javax.net.ssl.{keyStore,keyStorePassword,keyStoreType} properties seem to be set up fine.
How can I resolve this?
I came across a simpler answer if all you want is for your client to be able to call the SSL web service and ignore SSL certificate errors. (Of course you would NOT do this in production!, but it sure is handy for testing.)
Just put this statement before you invoke any web services:
System.setProperty("axis.socketSecureFactory",
"org.apache.axis.components.net.SunFakeTrustSocketFactory");
I found this at the Axis wiki.
Finally, importing the certificates into my own truststore, using Andreas Sterbenz's InstallCert, and setting the trustStore properties as indicated here did the trick!