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
Related
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.
I need to deploy my app in azure platform with eclipse; When I sign in, this error occurs:
Does anyone know how to solve this?
Thank you.
I think this is related to your certificate issue. Whenever Java attempts to connect to another application over SSL (e.g.: HTTPS, IMAPS, LDAPS), it will only be able to connect to that application if it can trust it. The way trust is handled in the Java world is that you have a keystore (typically $JAVA_HOME/lib/security/cacerts), also known as the truststore. This contains a list of all known Certificate Authority (CA) certificates, and Java will only trust certificates that are signed by one of those CAs or public certificates that exist within that keystore.
You could try below solutions:
1.Make sure you have imported the public certificate of the target instance into the truststore according to the Connecting to SSL Services instructions.
2.Make sure any certificates have been imported into the correct truststore.
3.Check to see that the correct truststore is in use. If -Djavax.net.ssl.trustStore has been configured, it will override the location of the default truststore, which will need to be checked.
In addition, you could refer to the related threads:
1.PKIX path building failed in Eclipse
2."PKIX path building failed" and "unable to find valid certification path to requested target"
Hope it helps you.
Just for summary, it's related to the build path in the eclipse. Please make sure it's JDK/JRE path, not JRE path.
when my app is published, it's a RESTful web service called "RESTfulExample2"
when I access the default url I get this:
error http 404
I don't know what's wrong
here are the screenshots of the variables:
environment variables
I am using mailgun to send email but from last day it shows error during POST request on email send api as below.I am using java/spring/AWS to my web app.I tried to restart app and to check if certificate is already in the trust store but we never had generate trust store keys.
com.mashape.unirest.http.exceptions.UnirestException: 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
at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:143)
at com.mashape.unirest.request.BaseRequest.asJson(BaseRequest.java:68)
On 1/22, we updated our SSL certificates due to Symantec's PKI infrastructure set to become untrusted. Some older versions of Java do not have the "DigiCert Global Root G2" CA.
There are several options:
Import the "DigiCert Global Root G2" CA into your "cacerts" file.
Upgrade your JRE to 8u91 (or higher), which includes this root.
To import the "DigiCert Global Root G2" You can download the root from https://www.digicert.com/digicert-root-certificates.htm. Ensure you are downloading the correct root certificate.
Once the certificate is downloaded, you'll need to import it into with a command like the following:
keytool -import -trustcacerts -keystore /path/to/cacerts -storepass changeit -noprompt -alias digicert-global-root-g2 -file /path/to/digicert.crt
You will need to set the path to your Java Keystore and the location of the root certificate you downloaded.
Same issue for us (java).
Here is what Mailgun support said:
Hello,
Thank you for reaching out to us in regards to our SSL certification renewal, >which are now fully completed. This update was pushed out to correct numerous >certificates that did not comply with the industry-developed CA/Browser Forum >Baseline Requirements by Symantec’s PKI business. You can read more about this >here.
Now that the updates have been completed, if you’re still having difficulties >sending, we can provide some suggestions to get your application back up and >running.
If you’re utilizing PHP-
1) Download the latest CA certificates from (https://curl.haxx.se/docs/caextract.html) This is an extract of a list of certificates vetted by Mozilla.
2) Set the path to the CA certificates in the .htaccess file with a directive like the following:
php_value curl.cainfo "/path/to/cacert.pem"
If you have access to your php.ini file, you can modify this value globally by setting curl.cainfo = "/path/to/cacert.pem"
If you’re utilizing cURL-
_Ubuntu users:_https://askubuntu.com/questions/646594/how-to-fix-ca-cert-issues-with-curl-in-ubuntu-14-04
RedHat users: https://serverfault.com/questions/394815/how-to-update-curl-ca-bundle-on-redhat
Be sure to restart your sending application after updating.
If a restart of your application does not clear the issue, the certificate cache may need to be cleared. Here is some additional information as to how this might be accomplished for you:
http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/
http://stackoverflow.com/questions/7219989/java-and-ssl-certificates
Because every sending application is be different, the exact method for updating the certifications/restarting your sending application may vary for you. If none of these options worked, some independent research might be needed for the update/restart method applicable to you.
While these suggestions are meant to help resolve the issues you are experiencing, making certain changes to your environment can always cause further issues with your application. We highly recommend making these changes in a non-production environment prior to releasing into production. These are only intended as suggested fixes and in no-way guarantee that this will fix the issue, further steps may need to be taken depending on your specific environment. As always Mailgun will always do our best to answer any questions that you may have, but there are limitations in the support we can provide.
Thanks,
Keith#MG
Restarting the application did not fix the issue. I'm trying to find which CA they are using to see if we can import it in the trustore.
I just downloaded the sample java code from the Yodlee site and I incorporated that into my web application. When I try to run, I error out on the Cobrand login:
Validating Cobrand by Connecting to URL https://rest.developer.yodlee.com/services/srest/restserver/v1.0/authenticate/coblogin
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 believe the issue is that my development environment (JDeveloper) doesn't have Yodlee's SSL certificate. I've searched the Yodlee site but I don't see any mention of test SSL certificates that I can import/reference.
I created similar code for an OFX connection, and had the same issue. That solution was to create an EventListener and then ignore SSL:
public void SSLServerAuthentication(InvstatementSSLServerAuthenticationEvent invstatementSSLServerAuthenticationEvent) {
invstatementSSLServerAuthenticationEvent.accept = true;
}
I also can't find any information on a Yodlee event listener base class.
How is everyone else getting around this issue?
I assume that once I deploy this to my production environment, I'll have to import the Yodlee SSL certificate into my WebLogic cert store... but one problem at a time for now :)
[EDIT] ANSWERED
I fixed this issue by changing the location that JDeveloper is using for it's keystore.
It was ..../DemoTrust.jks and I changed it to:
C:\Oracle\Middleware11116\jdk160_24\jre\lib\security\cacerts
This is under Tools / Preferences / Credentials
I was told that DemoTrust.jks doesn't have many signing authorities in it and cacerts does.
I will also need to make sure my production WebLogic server is using cacerts and not DemoTrust. Apparently in the start up of WebLogic, you'll get a big warning if you're pointing to DemoTrust.
ANSWER
[Sorry for the duplication, but I should have "Answered" my question and not edited the answer into the question]
I fixed this issue by changing the location that JDeveloper is using for it's keystore. It was ..../DemoTrust.jks and I changed it to: C:\Oracle\Middleware11116\jdk160_24\jre\lib\security\cacerts This is under Tools / Preferences / Credentials
I was told that DemoTrust.jks doesn't have many signing authorities in it and cacerts does. I will also need to make sure my production WebLogic server is using cacerts and not DemoTrust. Apparently in the start up of WebLogic, you'll get a big warning if you're pointing to DemoTrust.
Chris
In my project,I have integrated Spring Security with CAS server authentication. Now my project is an http application where as the CAS server is an Https application. I was getting following exception after Spring Security and CAS integration: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
In order to solve this error ,I replaced CAS server usr\java\jre\lib\security\cacerts file with my local usr\java\jre\lib\security\cacerts file. After this step the error was gone.
Now I want to deploy my application to some other server. In this new server some other applications are also deployed which may be using different CAS authentication. I cannot directly replace my CAS server cacerts file with this new server cacerts file as in that other application deployed may fail.Right? Can anyone suggest what should I do so that cacerts can be merged,or what should be done? i got to know a command called as keytool but unable to understand how it could be used to merge cacerts file. I dont know how to get my CAS server .cer file,I got to know this could be used in merging,please suggest solution
There is a missunderstanding here.
cacerts is Java's default truststore containing all the trusted certificates for known CA's (Verisign etc). So java can by default trust these certificates same way that your browser does.
This truststore should be used when you want to connect to servers that are signed by these CAs.
In all other cases you are expected to use your own custom truststore so that you can trust specific servers.Actually this is the norm.
So what you should be doing is to load in your code your own truststore and provide that to Java's JSSE to use for authentication during handshake