Error - trustAnchors parameter must be non-empty
JavaHudsonJakarta MailJenkinsJava Problem Overview
I'm trying to configure my e-mail on Jenkins/Hudson, and I constantly receive the error:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be
non-empty
I've seen a good amount of information online about the error, but I have not gotten any to work. I'm using Sun's JDK on Fedora Linux (not OpenJDK).
Here are a few things I've tried. I tried following the advice from this post, but copying the cacerts from Windows over to my Fedora box hosting Jenkins didn't work. I tried following this guide as I'm trying to configure Gmail as my SMTP server, but it didn't work either. I also tried to download and move those cacert files manually and move them over to my Java folder using a variation of the commands on this guide.
I am open to any suggestions as I'm currently stuck right now. I have gotten it to work from a Windows Hudson server, but I am struggling on Linux.
Java Solutions
Solution 1 - Java
This bizarre message means that the trustStore
you specified was:
- empty,
- not found, or
- couldn't be opened
- (due to wrong/missing
trustStorePassword
, or - file access permissions, for example).
- (due to wrong/missing
See also @AdamPlumb's answer below.
Solution 2 - Java
In Ubuntu 18.04, this error has a different cause (JEP 229, switch from the jks
keystore default format to the pkcs12
format, and the Debian cacerts file generation using the default for new files) and workaround:
# Ubuntu 18.04 and various Docker images such as openjdk:9-jdk throw exceptions when
# Java applications use SSL and HTTPS, because Java 9 changed a file format, if you
# create that file from scratch, like Debian / Ubuntu do.
#
# Before applying, run your application with the Java command line parameter
# java -Djavax.net.ssl.trustStorePassword=changeit ...
# to verify that this workaround is relevant to your particular issue.
#
# The parameter by itself can be used as a workaround, as well.
# 0. First make yourself root with 'sudo bash'.
# 1. Save an empty JKS file with the default 'changeit' password for Java cacerts.
# Use 'printf' instead of 'echo' for Dockerfile RUN compatibility.
/usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts
# 2. Re-add all the CA certs into the previously empty file.
/var/lib/dpkg/info/ca-certificates-java.postinst configure
Status (2018-08-07), the bug has been fixed in Ubuntu Bionic LTS 18.04.1 and Ubuntu Cosmic 18.10.
Ubuntu 1770553: [SRU] backport ca-certificates-java from cosmic (20180413ubuntu1)
Ubuntu 1769013: Please merge ca-certificates-java 20180413 (main) from Debian unstable (main)
Ubuntu 1739631: Fresh install with JDK 9 can't use the generated PKCS12 cacerts keystore file
docker-library 145: 9-jdk image has SSL issues
JDK-8044445 : JEP 229: Create PKCS12 Keystores by Default
JEP 229: Create PKCS12 Keystores by Default
If the issue continues after this workaround, you might want to make sure that you're actually running the Java distribution you just fixed.
$ which java
/usr/bin/java
You can set the Java alternatives to 'auto' with:
$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so
You can double-check the Java version you're executing:
$ java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)
There are alternative workarounds as well, but those have their own side effects which will require extra future maintenance, for no payoff whatsoever.
The next-best workaround is to add the row
javax.net.ssl.trustStorePassword=changeit
to the files
/etc/java-9-openjdk/management/management.properties
/etc/java-11-openjdk/management/management.properties
whichever exists.
The third least problematic workaround is to change the value of
keystore.type=pkcs12
to
keystore.type=jks
in the files
/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security
whichever exists, and then remove the cacerts
file and regenerate it in the manner described on the last row of the workaround script at the top of the post.
Solution 3 - Java
This fixed the problem for me on Ubuntu:
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
(found here: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760)
ca-certificates-java
is not a dependency in the Oracle JDK/JRE so this must be explicitly installed.
Solution 4 - Java
On Ubuntu 18.04 the root cause is a conflict between openjdk-11-jdk (which is default) and other packages depending on it. It has already been fixed in Debian and will be included in Ubuntu shortly. Meanwhile the simplest workaround is to demote your java to version 8. Other solutions employing ca-certificates-java
are much more complicated.
First remove conflicting packages:
sudo apt-get remove --purge openjdk* java-common default-jdk
sudo apt-get autoremove --purge
Check whether you successfully removed all related packages by:
sudo update-alternatives --config java
The system shall prompt you there is no Java available to config, otherwise this workaround fails.
Then reinstall required packages:
sudo apt-get install openjdk-8-jdk
Solution 5 - Java
EJP basically answered the question (and I realize this has an accepted answer), but I just dealt with this edge-case gotcha and wanted to immortalize my solution.
I had the InvalidAlgorithmParameterException
error on a hosted Jira server that I had previously set up for SSL-only access. The issue was that I had set up my keystore in the PKCS#12 format, but my truststore was in the JKS format.
In my case, I had edited my server.xml
file to specify the keystoreType to PKCS, but I did not specify the truststoreType, so it defaults to whatever the keystoreType is. Specifying the truststoreType explicitly as JKS solved it for me.
Solution 6 - Java
I ran into this solution from blog post Fixing the trustAnchors problem when running OpenJDK 7 on OS X:
Fixing the trustAnchors problem when running OpenJDK 7 on OS X. If you're running OpenJDK 7 on OS X and have seen this exception:
Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
There's a simple fix. Just link in the same cacerts file that Apple’s JDK 1.6 uses:
cd $(/usr/libexec/java_home -v 1.7)/jre/lib/security
ln -fsh /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts
You need to do this for every OpenJDK version you have installed. Just change -v 1.7
to the version you want to fix. Run /usr/libexec/java_home -V
to see all the JREs and JDKs you have installed.
Perhaps the OpenJDK guys could add this to their install scripts.
Solution 7 - Java
In Ubuntu 12.10 (Quantal Quetzal) or later, the certificates are held in the ca-certificates-java package. Using -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts
will pick them up regardless of what JDK you're using.
Solution 8 - Java
I ran into this exact problem on OS X, using JDK 1.7, after upgrading to OS X v10.9 (Mavericks). The fix that worked for me was to simply reinstall the Apple version of Java, available at http://support.apple.com/kb/DL1572.
Solution 9 - Java
I ran
sudo update-ca-certificates -f
to create a certificate file, and then:
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
I was back in business, thanks guys. It is a pity it's not included in the installation, but I got there in the end.
Solution 10 - Java
The error tells that the system cannot find the truststore in the path provided with the parameter javax.net.ssl.trustStore
.
Under Windows I copied the cacerts
file from jre/lib/security
into the Eclipse install directory (same place as the eclipse.ini
file) and added the following settings in eclipse.ini
:
-Djavax.net.ssl.trustStore=cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS
I had some troubles with the path to the cacerts (the %java_home% environment variable is somehow overwritten), so I used this trivial solution.
The idea is to provide a valid path to the truststore file - ideally it would be to use a relative one. You may also use an absolute path.
To make sure the store type is JKS, you would run the following command:
keytool -list -keystore cacerts
Keystore type: JKS
Keystore provider: SUN
Note: because certificates have expiration dates, or can become invalid for other reasons, do check from time to time if the certificates in cacerts are still valid. You would usually find the valid versions of the certificates in the latest builds of jdk.
Solution 11 - Java
Removing the ca-certificates-java package and installing it again worked for me (Ubuntu MATE 17.10 (Artful Aardvark)).
sudo dpkg --purge --force-depends ca-certificates-java
sudo apt-get install ca-certificates-java
Thank you, jdstrand: Comment 1 for bug 983302, Re: ca-certificates-java fails to install Java cacerts on Oneiric Ocelot.
Solution 12 - Java
For me it was caused by the lack of a trustedCertEntry in the truststore.
To test, use:
keytool -list -keystore keystore.jks
It gives me:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
cert-alias, 31-Jul-2017, PrivateKeyEntry
Even though my PrivateKeyEntry contains a CA it needed to be imported separately:
keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks
It imports the certificate, and then re-running keytool -list -keystore keystore.jks
now gives:
Your keystore contains 2 entries
cert-alias, 31-Jul-2017, PrivateKeyEntry,
Certificate fingerprint (SHA1): <fingerprint>
root-ca1, 04-Aug-2017, trustedCertEntry,
Certificate fingerprint (SHA1): <fingerprint>
Now it has a trustedCertEntry, and Tomcat will start successfully.
Solution 13 - Java
Some OpenJDK vendors releases caused this by having an empty cacerts
file distributed with the binary. The bug is explained here: https://github.com/AdoptOpenJDK/openjdk-build/issues/555
You can copy to adoptOpenJdk8\jre\lib\security\cacerts
the file from an old instalation like c:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts
.
The AdoptOpenJDK buggy version is https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip
Solution 14 - Java
I've had lot of security issues after upgrading to OS X v10.9 (Mavericks):
- SSL problem with Amazon AWS
- Peer not authenticated with Maven and Eclipse
trustAnchors
parameter must be non-empty
I applied this Java update and it fixed all my issues: http://support.apple.com/kb/DL1572?viewlocale=en_US
Solution 15 - Java
I expected things like this, being that I use an alternate JVM in my Talend Open Studio (support at the moment exists only until JDK 1.7). I use 8 for security purposes... anyway
-
Update your certificate store:
sudo update-ca-certificates -f
then
-
add a new value in your initialization parameters
sudo gedit $(path to your architecture specific ini i.e. TOS_DI...ini) Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts
For me, the second entry worked. I think, depending on the version of Talend Open Studio/TEnt + JVM, it has a different parameter name, but it looks for the same keystore file.
Solution 16 - Java
If you experience this on Ubuntu with JDK9 and Maven, you can add this JVM option - first check if the path exists:
-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts
If the file is missing, try to install the ca-certificates-java as someone noted:
sudo apt install ca-certificates-java
Solution 17 - Java
In my case the JKS file used in the client application was corrupted. I created a new one and imported the destination server SSL certificates in it. Then I used the new JKS file in the client application as a trust store, like:
System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);
Source: Java SSL and certificate keystore
I use the (KeyStore Explorer) tool to create the new JKS. You can download it from this link, KeyStore Explorer.
Solution 18 - Java
You may also encounter this error after upgrading to Spring Boot 1.4.1 (or newer) because it brings along Tomcat 8.5.5 as part of its dependencies.
The problem is due to the way that Tomcat deals with the trust store. If you happen to have specified your trust store location as the same as your keystore in the Spring Boot configuration, you'll likely get the trustAnchors parameter must be non-empty
message when starting the application.
server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks
Simply remove the server.ssl.trust-store
configuration unless you know that you need it, in which case consult the links below.
The following issues contain more details about the problem:
Solution 19 - Java
I had this error message on Java 9.0.1 on Linux. It was due to a known bug of the JDK, where the cacerts file is empty in the .tar.gz binary package (downloaded from http://jdk.java.net/9/).
See the "known issues" paragraph of JDK 9.0.1 Release Notes, saying "TLS does not work by default on OpenJDK 9".
On Debian/Ubuntu (and probably other derivaties), a simple workaround is to replace the cacerts file with the one from the "ca-certificates-java" package:
sudo apt install ca-certificates-java
cp /etc/ssl/certs/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts
On Red Hat Linux/CentOS, you can do the same from the "ca-certificates" package:
sudo yum install ca-certificates
cp /etc/pki/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts
Solution 20 - Java
I'm a fan of portability, so I don't install java, just download the tar.gz and export some values in the path and everything works.
I fought with this issue and no solution (install or update operative systems certs) worked for me.
Error in my case was: empty cacerts inside my jdk.
I don't know why, but my jdk.tar.gz had an empty cacerts file
/../some_openjdk/jre/lib/security/cacerts
size: 32 bytes
Downloaded from:
- https://download.java.net/openjdk/jdk8u41/ri/openjdk-8u41-b04-linux-x64-14_jan_2020.tar.gz
- https://download.java.net/java/GA/jdk9/9/binaries/openjdk-9_linux-x64_bin.tar.gz
Fix
After several attempts I found a correct jdk.tar.gz with a cacerts file with size 101 KB
I downloaded this open jdk from https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries
I found this url in this Dockerfile :
Solution 21 - Java
I had this issue when trying to use Maven 3, after upgrading from Ubuntu 16.04 LTS (Xenial Xerus) to Ubuntu 18.04 LTS (Bionic Beaver).
Checking /usr/lib/jvm/java-8-oracle/jre/lib/security showed that my cacerts file was a symbolic link pointing to /etc/ssl/certs/java/cacerts
.
I also had a file suspiciously named cacerts.original
.
I renamed cacerts.original
to cacerts
, and that fixed the issue.
Solution 22 - Java
I also encountered this on OS X after updating OS X v10.9 (Mavericks), when the old Java 6 was being used and tried to access an HTTPS URL. The fix was the inverse of Peter Kriens; I needed to copy the cacerts
from the 1.7 space to the location linked by the 1.6 version:
(as root)
umask 022
mkdir -p /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
cp $(/usr/libexec/java_home -v 1.7)/jre/lib/security/cacerts \
/System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
Solution 23 - Java
I encountered this problem with the Android SDK sdkmanager. For me this solution worked:
- Go to
/usr/lib/jvm/java-8-oracle/jre/lib/security/
- Replace
cacert
withcacert.original
The cacert
file was a tiny one (22B). I have installed oracle-java8-installer
from ppa:webupd8team/java
(according to this manual: https://docs.nativescript.org/start/ns-setup-linux).
Solution 24 - Java
On Red Hat Linux I got this issue resolved by importing the certificates to /etc/pki/java/cacerts
.
Solution 25 - Java
System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");
You have to add the above two lines to your code. It is not able to find the truststore.
Solution 26 - Java
For the record, none of the answers here worked for me. My Gradle build started failing mysteriously with this error, unable to fetch HEAD from Maven central for a particular POM file.
It turned out that I had JAVA_HOME set to my own personal build of OpenJDK, which I had built for debugging a javac issue. Setting it back to the JDK installed on my system fixed it.
Solution 27 - Java
On Ubuntu 18.04 I needed to use OpenJDK 1.7 for the maintenance of an old project. I downloaded the binary package. But when I executed my script on it I got the same error.
The solution was to remove the cacerts
file of the downloaded JDK in the jre/lib/security
folder and then to create it as symlink to the systems cacerts
file in /etc/ssl/certs/java/
:
sudo ln -s /etc/ssl/certs/java/cacerts /path/to/downloaded/java/jre/lib/security/cacerts
Solution 28 - Java
Slim chance this will help anyone but....for anyone running Java 8 from a Docker Image on a Raspberry Pi (using AMD CPU) I got the following Dockerfile to build and run successfully for me
FROM hypriot/rpi-java
USER root
WORKDIR /usr/build/
RUN /usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts
RUN update-ca-certificates -f
RUN /var/lib/dpkg/info/ca-certificates-java.postinst configure
EXPOSE 8080
ARG JAR_FILE=target/app-0.0.1-SNAPSHOT.jar
ADD ${JAR_FILE} app.jar
ENTRYPOINT ["java", "-Djavax.net.ssl.trustStorePassword=changeit", "-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts", "-jar", "app.jar"]
Solution 29 - Java
Marquis of Lorne's answer is accurate, I'm adding some info for debugging purposes:
To debug this issue (I wrote about it with more details in here) and understand what truststore is being used (or trying to use) you can add the property javax.net.debug=all and then filter the logs about truststore. You can also play with the property javax.net.ssl.trustStore to specify a specific truststore. For example :
java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=/Another/path/to/cacerts -jar test_get_https-0.0.1-SNAPSHOT-jar-with-dependencies.jar https://www.calca.com.py 2>&1| grep -i truststore
Solution 30 - Java
I faced this problem while running a particular suite of Android for testing on Ubuntu 14.04 (Trusty Tahr). Two things worked for me as suggested by shaheen:
sudo update-ca-certificates -f
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
Solution 31 - Java
None of solutions that I found on the Internet worked, but a modified version of Peter Kriens's answer seems to do the job.
First find your Java folder by running /usr/libexec/java_home
. For me it was the 1.6.0.jdk
version. Then go to its lib/security
subfolder (for me /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security
).
Then delete the cacerts
file if there is one already and search for one on the system with sudo find / -name "cacerts"
. It found multiple items for me, in versions of Xcode or other applications that I had installed, but also at /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts
which I chose.
Use that file and make a symbolic link to it (while inside the Java folder from before), sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts"
, and it should work.
I have both - Java from Apple's 2017-001 download (https://support.apple.com/kb/dl1572 - I assume that's where the correct certificates are from) and Oracle's one installed on Mac OS X v10.12 (Sierra).
Solution 32 - Java
on ubuntu 14.04 with openjdk 11 from ppa:openjdk-r/ppa this worked for me:
in java.security change keystore type to
keystore.type=jks
then:
sudo dpkg --purge --force-depends ca-certificates-java
sudo apt-get install ca-certificates-java
when you check if it worked, be sure you are not using any daemon with old java still running (eg. --no-daemon
option for gradle)
this bug describes everything nicely and will help you understand what's going on https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631
Solution 33 - Java
I found yet another reason for this error, which is not related to Ubuntu.
I tried setting up mutual TLS in a Spring boot 2 app and ran into this issue after using a truststore that had only a private key entry and no trusted certificate entry.
This is my Spring Boot TLS configuration
server.port=8443
server.ssl.key-alias=oba-tls
server.ssl.key-password=mypw
server.ssl.key-store-password=mypw
server.ssl.key-store=classpath:keys/tls-keystore.pfx
server.ssl.key-store-type=PKCS12
server.ssl.enabled=true
server.ssl.client-auth=need
server.ssl.trust-store=classpath:keys/truststore.pfx
server.ssl.trust-store-password=mypw
server.ssl.trust-store-type=PKCS12
server.ssl.ciphers=ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA384
server.ssl.protocol=TLS
server.ssl.enabled-protocols=TLSv1.2
For generating truststore.pfx I had to use the following commands to make it work.
openssl req -newkey rsa:2048 -nodes -keyout private.key -x509 -out cert.crt
keytool -importcert -alias oba-trust -file cert.crt -keystore truststore.jks
keytool -importkeystore -srckeystore truststore.jks -destkeystore truststore.pfx -srcstoretype JKS - deststoretype PKCS12 -deststorepass yourpassword
Solution 34 - Java
Fall into this using Amazon SDK v2, Windows 10 and JDK8.
Amazon SDK was complaining about credentials loading.
I solved this by replacing the security/cacert
file of JDK8 by the JDK11 one.
Solution 35 - Java
In my case root cause of this issue was empty truststore (it was app server truststore). When I added any dummy x.509 certificate then stopped throwing this error.
Command to add certificate in truststore vis keytool
keytool -import -alias dummy -keystore <path to keystore> -storepass <truststore password if any>
Solution 36 - Java
I have faced with the issue while importing a Gradle project in IntelliJ IDEA 14. A solution was using a local copy of Gradle instead of a wrapper from the project directory.
Solution 37 - Java
I got the same error when sending emails, but NOT always. In my case I've changed one line of code to get a new Session object every time:
MimeMessage message = new MimeMessage(Session.getDefaultInstance(props, authenticator));
to
MimeMessage message = new MimeMessage(Session.getInstance(props, authenticator));
Since then sending e-mails works every time.
The error I got:
> javax.mail.MessagingException: Could not convert socket to TLS;
> nested exception is: javax.net.ssl.SSLException:
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty at
> com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:1907) at
> com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:666)
> at javax.mail.Service.connect(Service.java:317) at
> javax.mail.Service.connect(Service.java:176) at
> javax.mail.Service.connect(Service.java:125) at
> javax.mail.Transport.send0(Transport.java:194) at
> javax.mail.Transport.send(Transport.java:124)
Solution 38 - Java
On Ubuntu:
> sudo apt install ca-certificates-java
or
> sudo apt-get install ca-certificates-java
sorted it for me.
Solution 39 - Java
Another reason for this is it's actually a valid error. Some nefarious Wi-Fi hotspots will mess with certificates and man-in-the-middle attack you to do who knows what (run away!).
Some large employers will do this same trick, especially in sensitive network zones so they can monitor all the encrypted traffic (not great from end user perspective, but there may be good reasons for this).
Solution 40 - Java
I got this error when using a truststore which was exported using a IBM Websphere JDK keytool in #PKCS12 format and trying to communicate over SSL using that file on an Oracle JRE.
My solution was to run on an IBM JRE or convert the truststore to JKS using an IBM Websphere keytool, so I was able to run it in an Oracle JRE.
Solution 41 - Java
For me it got resolved just by upgrading a Jenkins plugin, "Email Extension Plugin", to the latest version (2.61).
These two plugins are responsible for email configuration in Jenkins:
- Email Extension
- Email Extension Template
Solution 42 - Java
I had the same error, and the problem was not in configuring the JDK, but a simple wrong path to the JKS file in application.properties
file under trust-store:
parameter, double-check if the path is correct.
Solution 43 - Java
I ran
sudo update-ca-certificates -f
to create a certificate file, and then:
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure`
and then change the command line of jar execution:
sudo java -cp xx.jar:lib/* co.com.ixxx.clixxxlarxa.Main
Solution 44 - Java
For my case I didn't had specified VM Arguments fully.
(Run Configurations.. > (under Apache Tomcat) any server > (x)= Arguments > VM arguments:
)
Make sure all VM Arguments are set tup correctly.
Solution 45 - Java
You must add the cert file to your java keystore Go to chrom , open the website , save the certificate in txt format
Go to cmd> keytool -import -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -alias Root -import -file Trustedcaroot.txt
https://knowledge.digicert.com/solution/SO4085.html
This has worked like a charm