599

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
David Gill
  • 8,411
  • 5
  • 19
  • 21
  • I don;t know if this helps but I have had this happen in DBeaver and just had to fix it, which apparently also uses java as its nightmare of choice. There were 3 options in driver configuration: Require SSL, Verify Server Certificate, Allow Public Key retrieval. When I uncheck Verify Server Certificate the connection succeeds, prior it was giving this same error for any but a root connection to mysql 8.0. – John Sohn Sep 14 '21 at 01:46

48 Answers48

596

This bizarre message means that the trust store you specified was:

  • empty,
  • not found, or
  • couldn't be opened, due for example to:
    • wrong/missing trustStorePassword, or
    • file access permissions.

See also @AdamPlumb's answer below.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 1
    Thanks EJP, I saw your post [here](http://stackoverflow.com/questions/6633164/got-java-security-invalidalgorithmparameterexception-the-trustanchors-parameter) but I wasn't sure how to verify the truststore is there. Also I brought up my server.xml file but I wasn't sure how to verify the truststore is in place. Do I just check the keystoreFile="conf/.keystore" pref (keystoreFile wasn't present in that file)? – David Gill Jul 22 '11 at 16:58
  • @Bubbleware Technology The error will stop happening when you get it right. That's your verification. You need to understand what the current directory is when executing Tomcat if you're going to specify relative paths to the truststore. I can't make head or tail of your last sentence. – user207421 Jul 24 '11 at 10:02
  • Ok I think I follow your statement there. What I did was first search for a .jks file (which I couldn't find one). Then I created one with `keytool -genkey -alias mydomain -keyalg RSA -keystore keystore.jks -keysize 2048` . Then I added this to JAVA_OPTS variable in catalina.sh with the command `-Djavax.net.ssl.keyStore=/root/keystore.jks` Unfortunately, I still get the same trustAnchors error. – David Gill Jul 28 '11 at 00:00
  • I tried running the command `println(System.getProperty("javax.net.ssl.trustStore"));` via Jenkins Script Console and I get null. I tried setting it via the script console with `System.setProperty("javax.net.ssl.trustStore", /root/keystore.jks);`. I no longer get null when I run getProperty on the trustStore but I'm pretty sure this is not the correct way to set this as I still get that truststore error testing my e-mail. Any ideas what I'm doing wrong? – David Gill Jul 28 '11 at 00:06
  • @Bubbleware Technology the keystore is for keys, the truststore is for trusted certificates. The trust-anchors message refers to the truststore, not the keystore, so setting a keystore won't affect it. The correct way to set the truststore for Tomcat is either via the -D option as you did for the truststore, or possibly via the Connector attributes in server.xml, if it has truststore-type attributes. – user207421 Jul 28 '11 at 11:05
  • 1
    I follow what your saying and I don't know how I missed that distinction between keystore and truststore. With that in mind, I tried to generate a truststore with the command `keytool -import -file CA.cer -keystore truststore` . I dont know exactly where that generated the truststore so I ran locate and checked. I then added this truststore to my Tomcat in catalina.sh under JAVA_OPTS with the command `-Djavax.net.ssl.trustStore=/opt/downloads/jdk1.6.0_21/sample/jmx/jmx-scandir/truststore` . I restarted my servers and I still get the truststore error. Am i missing something? – David Gill Jul 30 '11 at 04:11
  • 3
    The answer was with how I was importing it. I seemed to have missed a crucial step. See [Java Error InvalidAlgorithmParameterException][1] [1]: http://jyotirbhandari.blogspot.com/2011/09/java-error-invalidalgorithmparameterexc.html – David Gill Sep 25 '11 at 17:15
  • 2
    Confirmed this answer is correct. I was getting the error under Tomcat. I had my truststore in `${CATALINA_HOME}\conf` but `CATALINA_HOME` was not getting set so Tomcat was looking under `\conf` for the truststore. – SingleShot Feb 21 '12 at 21:03
  • This error also occurs when the keystore exists but can not be accessed for some other reason, for example when the user that Tomcat runs as does not have access rights to the folder of the keystore. – László van den Hoek Jul 15 '13 at 08:41
  • 4
    @BubblewareTechnology No, the error was in the filename, not in how you imported the certificate into the file. Your blog isn't correct. You also shouldn't be recommending modifying the JRE$/ cacerts file. It will change next Java upgrade. You need a process that copies it, adds your own certificate to the copy, and uses the copy as the truststore. Repeat every Java upgrade. And you don't need to tell Java about its own truststore at all, only about your own, if it's different. – user207421 Apr 21 '14 at 01:01
  • @BubblewareTechnology thanks that `openssl s_client -connect repo1.maven.org:443 > repo1_maven_org.cert` and `$JAVA_HOME/bin/keytool -import -alias repo1.maven.org -keystore $JAVA_HOME/jre/lib/security/cacerts -file repo1_maven_org.cert` got it fixed, didn't even need `-Djavax.net.ssl.trustStore=$JAVA_HOME/jre/lib/security/cacerts` `-Djavax.net.ssl.trustStorePassword=password`. made my problem of the week go away I am happy :). I did not suspect the truststore btw (because didnt see the msg until https://ant.apache.org/ivy/ivyde/history/latest-milestone/console.html), I should have. – n611x007 Sep 25 '15 at 17:12
  • In my case, I had keystore and truststore files external to anything managed by keytool, and needed simply to initialize my java/scala environment with a classpath that included those files. So my shell init looks like `scala -classpath path/to/my.jar:path/to/cert/directory`. – Alexander Tronchin-James Aug 16 '16 at 18:07
  • @AlexanderTronchin-James These files are not located via the CLASSPATH. – user207421 Oct 13 '16 at 10:08
  • 7
    I'll add a twist: even when the truststore exists, is accessible, is in the right format, if it is COMPLETELY EMPTY, that's the error you can get with various libraries (including Apache HttpClient). – Alan Franzoni Aug 22 '17 at 10:12
  • 1
    FYI, in my case, it's the store password that was incorrect. – Nathan W May 11 '18 at 00:05
  • 12
    btw this happens e.g. when switching from OracleJDK8 to OpenJDK8 since OpenJDK comes with an empty trust store. Copying the one from OpenJDK11 fixes the problem – light_303 Nov 13 '18 at 09:38
  • 1
    Can also happen if you run Oracle JDK8 but set your JAVA_HOME to OpenJDK8. – Daryl Banttari Nov 29 '18 at 23:56
  • 1
    This can also happen when using a PKCS12 key store and no password (= `null`) is provided when the store is loaded, see [source](https://github.com/openjdk/jdk/blob/f99414c0526c44e48d6b16494cb16b50e30b6317/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#L2034) – Marcono1234 May 31 '19 at 11:23
  • I had to provide `-Djavax.net.ssl.trustStorePassword=changeit`. I thought we didn't have to provide it if it's the default password? – DLight Apr 16 '20 at 14:08
  • @DLight It has nothing to do with the default password. You don't have to provide it at all unless you want the truststore verified. – user207421 Aug 26 '20 at 11:36
  • @Marcono1234 That only applies to `PrivateKeyEntry`, which means it isn't a truststore at all but a keystore. – user207421 Aug 26 '20 at 11:37
  • For me the issue was in a different answer, the storetype must be JKS for a ca/server truststore – Kukeltje Sep 15 '20 at 21:27
  • @Kukeltje That comes under 'couldn't be opened'. – user207421 Sep 17 '20 at 01:32
  • @light_303, I am using openjdk 8 and have generated certificate using openjdk11, but still facing the same issue. – Fayaz Jun 17 '21 at 09:26
  • @Fayaz you need to copy the trust-store file of OpenJDK11 - it does not matter how your certificates were created. – light_303 Jun 28 '21 at 11:57
  • How easy would it be if they put each separate use case in the list in a clear error message. – user2209562 Nov 02 '21 at 14:58
  • @DavidGill comment helped me with empty *trustAnchors* issue : adding Djavax.net.ssl.trustStore & Djavax.net.ssl.trustStorePassword solved the problem – Francois Dec 13 '21 at 17:48
  • You can set the system property javax.net.debug=fine to find out which truststore java tries to open. – Christoph Böhme Jun 30 '22 at 13:19
  • due to wrong/missing trustStorePassword... It's really a crazy error for a bad password! Bad Java! – jambox Jul 13 '23 at 22:48
  • @GusCalca Please do not misrepresent your work as mine. – user207421 Aug 11 '23 at 01:04
  • @user207421 yes, no problem. That was a mistake from a couple years ago. – Gus Calca Aug 24 '23 at 15:41
301

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

Debian 894979: ca-certificates-java: does not work with OpenJDK 9, applications fail with InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

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.

Mikael Gueck
  • 5,511
  • 1
  • 27
  • 25
  • 5
    This answer helped me to fix same error with maven on Ubuntu 18.04. I had to change owner of /etc/ssl/certs/java/cacerts file from root to myself to be able write to it. Then I switched it back. – Yuri Gor May 08 '18 at 15:13
  • 80
    I ran **sudo rm /etc/ssl/certs/java/cacerts** and then **sudo update-ca-certificates -f** and this fixed my issue in kubuntu 18.04. – jsn May 13 '18 at 15:19
  • 1
    @jsn Your solution worked for me on Kubuntu 18.04 too. – Hrvoje T May 25 '18 at 08:30
  • 1
    @jsn, the reason why that fixed your issue was because you also took an additional step, which you neglected to mention. The reason why I didn't recommend that solution over a simpler one is that people could later notice that as a side effect, something else has broken, requiring them to spend more time tracking that down. – Mikael Gueck May 25 '18 at 12:39
  • This should actually be part of a new question because is so specific to the new ubuntu 18 users, thanks a lot ! – WhGandalf May 26 '18 at 00:30
  • This solution is gold! It does not only solved the Jenkins problem but also other problems such as maven build! – Bing Ren Jun 08 '18 at 05:38
  • 1
    Saved by @jsn on Ubuntu Mate 18.04 – Serafim Jun 27 '18 at 09:41
  • 1
    @jsn perhaps should to be separate answer and rated at the top. Worked for me 18.04 – Vadim Jul 09 '18 at 07:48
  • 1
    @jsn Thank you for the fix! For future readers: this works for openjdk-8-jdk, but not for openjdk-11-jdk. Seems like /etc/ca-certificates/update.d/jks-keystore doesn't seem to support openjdk-11 (it isn't listed there). – Dalibor Filus Jul 11 '18 at 13:52
  • 2
    @jsn , thanks for the solutions , works on linux mint 19 as well which is based on ubuntu 18.04 – Samrat Jul 16 '18 at 11:02
  • This is the only thing that worked for me on Ubuntu 16.04 with Java 11. – ipkpjersi Nov 24 '18 at 15:45
  • 2
    @jsn's solution also worked for Debian Stretch + openjdk8 – HRJ Mar 27 '19 at 14:35
  • I changed the Java version for NiFi from an Oracle version to a more modern OpenJDK and it worked – hanzo2001 Nov 27 '19 at 17:00
  • 1
    the third solution helped me a lot, but if you added how to regenerate cacerts, it would be much greater. "sudo update-ca-certificates -f" and "sudo apt install ca-certificates-java --reinstall" which i found [here](https://askubuntu.com/questions/971059/17-10-openjdk-and-oracle-jdk-8-and-9-the-trustanchors-parameter-must-be-non-empt) – Asylzat Jun 03 '20 at 14:43
  • Glad to hear that, @AsylzatAzaev. I clarified the sentence you pointed out. – Mikael Gueck Jun 03 '20 at 15:12
  • I struggled with this for days. `sudo update-ca-certificates -f` and `sudo apt install ca-certificates-java --reinstall` fixed it for me on maven Ubuntu 18 – Zadat Olayinka Jul 03 '20 at 09:09
112

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.

Archimedes Trajano
  • 35,625
  • 19
  • 175
  • 265
Michael Condouris
  • 1,191
  • 1
  • 8
  • 3
77

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
muttonUp
  • 6,351
  • 2
  • 42
  • 54
shvahabi
  • 1,218
  • 10
  • 7
  • This description is factually incorrect, and only fixes the problem in the same sense as reinstalling Windows might fix an issue. There is no need to remove all Java packages. If you want to go this way, you only need to install the `openjdk-8-jdk` package, remove the `/etc/ssl/certs/java/cacerts` file, and run `sudo update-ca-certificates -f` which is the roundabout way of switching from a `pkcs12` formatted cacerts file to a `jks` formatted one, as described elsewhere in this thread. – Mikael Gueck Jun 22 '18 at 15:43
  • 1
    @MikaelGueck While the logic seems to be on your side, I'm here to assure you I previously did exactly what's described in your comment and in the most other voted answers, and in 18.04 **this is the only answer which worked**. I think your downvote should turn into an upvote, or at least vanish, since it's highly undeserved. – Andrea Ligios Jun 25 '18 at 15:47
  • @AndreaLigios, you can read through the scripts yourself, they are pretty short. They have a hardcoded set of JAVA_HOME paths from 8 to 10, they try those one at a time, they call the Debian CA file generator which you can also read through, which uses the existing file format, because the JDK keyfile handler code, which you can read through, has a compatibility fallback mode. If your computer runs this simple software differently, you might have other problems with it. Did you modify your java alternatives, and call some other JVM, because then removing might have reset the alternatives? – Mikael Gueck Jun 25 '18 at 18:07
  • 1
    @MikaelGueck yes, in one of the previous tries I've modified my java alternatives, so it probably was that. I'm the first who likes to dig into source code and find how stuff works, but this today was not my goal, it was just one among 5-6 different unexpected obstacles I had in the way to my real goal. This answer allowed me to solve the problem in less than 2 minutes! How much time should I have put to look into scripts and find a better solution? And for what, to save some megabytes? This is drastic, but works (and no matter what the problem is), so a big thank to OP for those busy as hell – Andrea Ligios Jun 25 '18 at 19:22
  • when actually executing the 2 purges and seeing the list of packages that apt was removing this seemed a bit heavy handed to me however it did the trick for my unimportant kubuntu 18.04 install so i'm happy to save a small amount of typing i used `sudo apt-get purge openjdk* java-common default-jdk` rather than `--purge remove` – northern-bradley Jul 07 '18 at 14:52
  • Worked on Ubuntu 18.04 LTS. Also I had to make sure the $JAVA_HOME is set to /usr/lib/jvm/java-1.8.0-openjdk-amd64 – PiKey Jul 13 '18 at 06:55
  • 1
    I have been looking for a solution for 2 days, and your answer solved my issue, thanks. I just move to Kubuntu 18.04, this worked on it. – Inmer Jul 14 '18 at 04:21
  • Downloading jdk worked for me. https://www.oracle.com/technetwork/java/javase/downloads/jdk13-downloads-5672538.html – Ranjeet Singh Sep 24 '19 at 09:04
65

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.

Yuri
  • 4,254
  • 1
  • 29
  • 46
Adam Plumb
  • 3,738
  • 8
  • 35
  • 34
  • well, I help you immortalizing solution to your edge-case gotcha. that's where it gets interesting. – n611x007 Sep 25 '15 at 16:59
  • 2
    This was exactly my problem. I was using Spring Boot 1.4.2.RELEASE, and had a hardware keystore and software truststore. I specified the provider and type for the keystore, but not the truststore. As a result, the wrong provider and type were used by the truststore. Specifying those (SUN and JKS) solved the issue. – Kenco Dec 06 '16 at 09:38
  • 18
    how exactly did you do this? (windows here) – tatsu Jan 31 '18 at 15:03
  • 2
    Run into this with my Android grandle today, i almost understand what you say but you don't say how to solve it. Non helpable answer – Lothar May 24 '18 at 15:56
  • in my case I had a trusttore generated by jdk 14 keytool, defaults to pkcs format, trying to connect to kafka cluster that is using a jks keystore. I amend how I created the truststore to use switch `-storetype jks` and it resolved it – James Render Jul 02 '20 at 09:20
53

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Peter Kriens
  • 15,196
  • 1
  • 37
  • 55
  • 1
    My "ln" command (on OSX 10.6.8) doesn't have an "h" option; what is it meant to do? – Andrew Swan Jun 20 '12 at 02:09
  • 1
    Ah, I had two "ln" commands, one in /usr/bin (the default) and one in /bin; the latter had an "h" option and worked. – Andrew Swan Jun 20 '12 at 02:20
  • I fixed my broken 1.6 installation linking to cacerts from the system 1.8 installation with this ln technique. Thanks! – A21z Feb 19 '15 at 23:54
  • 1
    For future readers: it seems that you also need the other 3 files that are in the `security` folder (`blacklisted.certs`, `local_policy.jar`, and `US_export_policy.jar`) for Java to be happy. – awksp Jun 18 '15 at 16:08
  • @Peter Kriens, why linked to `cacerts` under `jre` directory? – BAE Oct 24 '18 at 15:36
  • So in the case of Java 1.6, the path where you want to create the links may be different. In my case, I've installed it manually from a compressed ZIP, so my installation point was actually this: `/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home` and the folder where I've created the symbolic links to `cacerts` and `blacklisted.certs` files was this `lib/security`. After providing these links, the issue is corrected. – RickB Jan 23 '19 at 03:01
48

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
yvesr
  • 481
  • 4
  • 3
  • 56
    I found I needed to run `update-ca-certificates -f` manually, to populate the cacerts file – Portablejim Feb 05 '15 at 06:54
  • 4
    @Portablejim Thanks. Your comment solved the first issue I hit building Apache Spark on Ubuntu 15.04beta. – Paul Mar 31 '15 at 09:21
  • 1
    Thanks you @Portablejim, your comment worked for me on Ubuntu 15.04. – David Berg Oct 05 '15 at 14:30
  • Thanks. This is fixed my problem with PhpStrom + patched JDK. I wrote this key into "phpstorm64.vmoptions" file. – Vijit Nov 04 '16 at 07:43
  • Not working for me in ubuntu 18.04 and JDK is 1.8.0_62 – Devendra Singraul Dec 27 '18 at 11:08
  • This solution worked also for me running a Bitbucket Server on a Hetzner System with debian. I used this line to force java to run with the trustStore `export ES_JAVA_OPTS=-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts` – Marcel Grolms Jun 04 '20 at 17:38
  • thank you - i had no idea and didn't even consider that ubuntu ca-certificates utils would also create a java JKS bundle – jamey graham May 04 '21 at 10:51
35

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
KiwiMartin
  • 804
  • 9
  • 15
  • I encountered this with Java 6 used by Grails on OSX. I also had Java 7 from Oracle installed and also upgraded to Mavericks. Re-installing Java 6 from Apple website also fixed the issue for me. – pm_labs Sep 09 '14 at 11:05
  • Ran into this when installing open jdk 6 onto an ubuntu cloud box. Nice to see a familiar face, BTW – Ben Hutchison Jun 17 '15 at 05:58
30

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.

razvanone
  • 1,351
  • 18
  • 27
  • 3
    This is the only answer that actually worked. Thanks @razvanone – Akshar Patel Apr 21 '18 at 06:55
  • 2
    I managed to hit one small "gotcha": The three lines in the eclipse.ini file must be on actual three separate lines. I initially put all of them on one line and eclipse did not pick that up. – SiKing Nov 14 '18 at 21:02
  • I managed to fix this error that occurred even though all there JVM args were set. When inspected the path to the cacerts.jks was not correct in my eclipse.ini file. So even wrong jks path can generate this error. Fixing to correct jks path solved the error – rinilnath Sep 17 '21 at 01:15
29

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Johnny
  • 391
  • 4
  • 3
  • When I run `sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure**` I get `sudo: /var/lib/dpkg/info/ca-certificates-java.postinst: command not found` – Magick Aug 15 '16 at 09:20
  • Just `sudo update-ca-certificates -f` is enough on Debian jessie with `openjdk-8-jre-headless` from jessie-backports, as long as `ca-certificates-java` is installed. I think order of installation matters (JRE after `ca-certificates-java` may cause this, as the latter doesn’t have any triggers for the backported Java 8). – mirabilos Feb 06 '17 at 22:14
  • 2
    `sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure` without stars ** – Yu Jiaao Sep 06 '17 at 10:27
  • `update-ca-certificates -f` is the thing that fixed it. I didn't need the 2nd command – Mark Jeronimus Jun 04 '20 at 12:53
18

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
ericek111
  • 575
  • 7
  • 15
15

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.

muttonUp
  • 6,351
  • 2
  • 42
  • 54
  • NB check baeldung tutorial with a useful Makefile as shortcut to creating keystore & truststore (spring-security-x509 project) https://www.baeldung.com/x-509-authentication-in-spring-security – hello_earth Jul 02 '19 at 11:46
14

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

Yuri
  • 4,254
  • 1
  • 29
  • 46
raisercostin
  • 8,777
  • 5
  • 67
  • 76
  • I think this was the case for me as well. In AdoptOpenJDK 202 this bug is present, and in 222 it works. So update your jdk if possible. – Marty Apr 09 '20 at 09:18
11

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

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Freddy Boucher
  • 1,387
  • 1
  • 16
  • 27
  • 7
    Ugh. Java 6 is many years past its end of public support, and is surely riddled with security holes. Apple makes it available for download so that older software that cannot be run with Java 7/8 can continue to execute, but it should not be used for making SSL connections to services on the public internet, such as 1. AWS, 2. Maven Central, 3. anything else. – Zac Thompson Mar 06 '15 at 06:46
10

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
steveoams
  • 404
  • 4
  • 6
  • 4
    Where did you get the property `javax.net.ssl.trustAnchors` from? It isn't mentioned in the JSSE documentation. – user207421 Sep 03 '15 at 21:51
8

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
dmatej
  • 1,518
  • 15
  • 24
6

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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mossroy
  • 710
  • 6
  • 11
6

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). Nothing worked for me.

cacerts file is empty

In my case, reviewing my jdk folder, the cacerts file had a little size compared with other jdk folder (servers & friends):

/../some_openjdk/jre/lib/security/cacerts size: 32 bytes

I downloaded it from:

Fix

After several attempts I found a correct jdk.tar.gz with a cacerts file with size 101 KB

I downloaded the open jdk from https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries

I found this url in this Dockerfile :

JRichardsz
  • 14,356
  • 6
  • 59
  • 94
  • for the same issue my cacert had 0 entries , so having the right cacerts resolved my issue – Mayur Sep 24 '20 at 06:42
5

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Salman
  • 1,236
  • 5
  • 30
  • 59
  • [keystore-explorer](http://www.keystore-explorer.org/index.html) did the work for me. You just have to create default keystore and examine and save the certificate file for the site/host. – Shantha Kumara Sep 22 '16 at 12:03
  • For some unknown reason on windows OpenJDK11, OracleJDK 11 i had to do the same, did it on the parameters: "-Djavax.net.ssl.trustStore=%JAVA_HOME%\lib\security\cacerts" – Kendar Sep 14 '21 at 11:15
5

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:

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Robert Hunt
  • 7,914
  • 5
  • 40
  • 43
  • This solution saved my life today, Thank you soo much. – Sami Haroon Jun 26 '20 at 16:44
  • This does not explain how having same keystore set as trust store breaks things. Links imply this might be due to empty trust store which doesn't seem to be the case. Don't see how it's all related. – miracle_the_V Jul 28 '23 at 17:22
4

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
John Deverall
  • 5,954
  • 3
  • 27
  • 37
  • The `cacerts.original` file was in the `jks` format, and was generated with Ubuntu 16.04's Java 8, which used that format as its default. The `cacerts` file was in the `pkcs12` format, generated by Ubuntu 18.04's Java 10, which uses this format as its default. As explained elsewhere in this thread, the new format requires you to pass the password to the executable. But as long as you either generate a new empty `jks` `cacerts` file or copy an old one, the next cacerts generation process will empty the existing file out, and refill it with the CA certificates from the file system. – Mikael Gueck Jun 23 '18 at 00:30
3

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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Partly Cloudy
  • 6,508
  • 3
  • 27
  • 16
  • 1
    The command here tries to copy a directory to a file; makes no sense at all. – praseodym Dec 05 '13 at 12:54
  • I concur with the assessment of using a reverse solution. I found that jdk1.6 had a broken softlink /Library/Java/JavaVirtualMachines/1.6.0_33-b03-424.jdk/Contents/Home/lib/security/cacerts -> /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts. So I rm'ed the broken soft link, then copied over the cacerts from the jdk1.7 installation. – James A Wilson Jan 13 '14 at 20:27
  • NOTE: when you are done you should be able to cat the cacerts file that you copied to validate the permissions. – Gray Aug 31 '15 at 18:56
  • Also, fixed the cp to go the right direction and added the umask for mkdir and cp. – Gray Aug 31 '15 at 19:03
3

I encountered this problem with the Android SDK sdkmanager. For me this solution worked:

  1. Go to /usr/lib/jvm/java-8-oracle/jre/lib/security/
  2. Replace cacert with cacert.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).

Yuri
  • 4,254
  • 1
  • 29
  • 46
Gabriel Cséfalvay
  • 488
  • 5
  • 12
3

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
Gus Calca
  • 113
  • 5
2

On Red Hat Linux I got this issue resolved by importing the certificates to /etc/pki/java/cacerts.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
ak1
  • 104
  • 4
2
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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Divyesh Kalbhor
  • 385
  • 3
  • 19
  • 2
    If you don't, it will use the JRE truststore, and it will certainly be able to find that. The error is caused by incorrect values in these parameters, not their absence. The file named in your code only applies to your installation, not generally. – user207421 Nov 16 '17 at 23:18
  • The proper way to set those properties are by passing them on the command line: `java -Djavax.net.ssl.trustStore=/tmp/cacerts ...` or if you want to set them globally for all programs run with a JDK, add the row to the JDK's `management.properties` file. – Mikael Gueck Jun 03 '20 at 15:15
  • I faced the same issue and this solution was right. But I start my application with vm options: `-Djavax.net.ssl.trustStore=cacerts.jks` `-Djavax.net.ssl.trustStorePassword=changeit` – Kirill Parfenov Mar 19 '23 at 13:54
2

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Stevey
  • 2,822
  • 1
  • 23
  • 30
  • ... which caused the truststore not to be found, as per other answers. – user207421 Mar 21 '17 at 22:46
  • 1
    Yeah, but knowing that the truststore can't be found is entirely unhelpful if you do can't figure out *why* it's not being found. There are many many possible ways it can go wrong, and it's frustating when none of them happen to be the particular way that it is failing for your own system. – Stevey Mar 22 '17 at 15:11
  • They all 'happen' to be the same error: the truststore specified could not be opened or was empty. There are a million ways in which this situation could arise, and there isn't enough space on SO to enumerate them all. – user207421 Mar 07 '18 at 09:18
2

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

Mike
  • 367
  • 4
  • 8
2

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"]
Christian Bartram
  • 381
  • 6
  • 13
2

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.

rdupz
  • 2,204
  • 2
  • 13
  • 21
1

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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
DPKGRG
  • 65
  • 1
  • 5
1

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).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
shw
  • 614
  • 6
  • 14
1

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

piotrek
  • 13,982
  • 13
  • 79
  • 165
1

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
Julius
  • 2,784
  • 6
  • 32
  • 54
  • A truststore that had only a private key entry and no trusted certificate entry isn't a truststore at all. It is a keystore. – user207421 Jun 08 '23 at 12:10
1

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
Yuri
  • 4,254
  • 1
  • 29
  • 46
NELSON RODRIGUEZ
  • 309
  • 3
  • 6
0

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.

Sergey Filkin
  • 475
  • 1
  • 6
  • 10
0

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)

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
marioosh
  • 27,328
  • 49
  • 143
  • 192
0

On Ubuntu:

sudo apt install ca-certificates-java

or

sudo apt-get install ca-certificates-java

sorted it for me.

The Tomahawk
  • 153
  • 1
  • 5
0

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).

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Matt Broekhuis
  • 1,985
  • 2
  • 26
  • 35
0

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Maarten
  • 808
  • 1
  • 6
  • 17
0

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
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
himanshu vyas
  • 13
  • 3
0

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.

Yuri
  • 4,254
  • 1
  • 29
  • 46
Dimitar Dimitrov
  • 29
  • 3
0

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.

Poli
  • 77
  • 1
  • 11
0

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>
Robin Mathur
  • 447
  • 5
  • 4
  • Why not add a real one? You aren't going to get anywhere with either an empty truststore or one that doesn't contain anything you actually need to trust. – user207421 Jun 08 '23 at 12:11
0

I ran into the the trustAnchors parameter must be non-empty error when I tried to run my app in IntelliJ. To fix the problem I had to make the Run Configuration point to the JDK or JRE that had the /lib/security/ folder which had the cacerts file.

jpllosa
  • 2,066
  • 1
  • 28
  • 30
0

I got the same error. But when I restarted the Tomcat service, thankfully it has gone.

sudo /usr/local/tomcat/bin/shutdown.sh
sudo /usr/local/tomcat/bin/startup.sh
Sheikh Abdul Wahid
  • 2,623
  • 2
  • 25
  • 24
0

enter image description here

I had to explicitly specify the path to the store, but I didn't need to do this before. The application connects to the remote service over https.

skyho
  • 1,438
  • 2
  • 20
  • 47
  • And how could I, for a client application, specify this via properties (application.yml) ? – skyho Aug 01 '23 at 11:20
-2

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

Prashant
  • 17
  • 1
  • 6
  • "Oops, there is a problem The page you requested cannot be found. Search by entering one or more keywords in the search field above" – HoaPhan Jun 22 '22 at 16:55
  • This command adds to the truststore, not the keystore. Don't get these things confused. They share the same format but they serve completely different purposes. – user207421 Jun 08 '23 at 12:13