trustAnchors parameter must be non-empty

[Peter Horlock]

Hi,

"out of the blue"
we are getting tons of "java.security.InvalidAlgorithmParameterException:
the trustAnchors parameter must be non-empty" Exceptions thrown on our
webserver (https).

The error occurrs (at least) in two situations:
a) We have a scropt that periodically calls an url on our webserver
b) When the server is in a certain state it contects to another https url
of an external resource. They say their certificate was still valid
(however we never exchanged any certificates, as far as I know)

http://forums.sun.com/thread.jspa?threadID=580496
to solve this error I've generate a certificate :
keytool -genkey -alias tomcat -keyalg RSA
I've moved the file .keystore generated to
/opt/sun-jdk1.5/jre/lib/security/ and rename it cacerts. (replace
/opt/sun-jdk1.5 by the directory where you have installed java)

However, I don't understand - why would I have to do that -
When I visit the website I can see with Firefox that the website has a
valid certificate from veri sign. I haven't set it up personally, and the
guy(s) who have are not in the company anymore, so I am cautious of
touching anything (wrong).
The certificate still seems to be valid and our admins say no one has
touched anything whatsoever on the webserver, so why should I have to
touch the certificates??

Also, as far as I know the certificates created by the key tool are self
signed, so that would be less then what we already got.


Can you help me solving this very strange issue?

Thanks in advance,

Peter

 

[EJP]

we are getting tons of "java.security.InvalidAlgorithmParameterException:
the trustAnchors parameter must be non-empty" Exceptions thrown on our
webserver (https).

This strange message means among other things that the defined
truststore could not be opened. Your server won't normally be using a
truststore unless it is requesting client authentication or connecting
to other SSL servers, which would explain why it only happens
intermittently.

 

[Peter Horlock]

Hi EJP,

could you be more concrete - how should I fix this issue then and how
comes the exception happened without any changes on our server???


Thanks in advance,

Peter

 

[Lew]

could you be more concrete - how should I fix this issue then and how
comes the exception happened without any changes on our server???

Behaviors don't change by themselves; something in the environment
must have changed. Re-examine your assumptions.

EJP's answer gives you a lead or two into what might have changed.
Without being there personally, I doubt anyone here could do better
than that.

 

[Roedy Green]

"out of the blue"
we are getting tons of "java.security.InvalidAlgorithmParameterException:
the trustAnchors parameter must be non-empty" Exceptions thrown on our
webserver (https).

Can you get a stack trace to see just where it is happening? Seeing
your code that triggered the exception would be a plausible next step.

Also try scanning the JDK for the string "trustAnchors parameter must
be non-empty". The surrounding code might give you a clue.

 

[Lothar Kimmeringer]

Also try scanning the JDK for the string "trustAnchors parameter must
be non-empty". The surrounding code might give you a clue.

If he is not using OpenJDK, the JSSE is not part of the available
sources of the JDK, so happy searching ;-)


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Peter Horlock]

Here comes the entire stack trace:

25 Mrz 2010 00:02:49 ERROR [de.company.mypackage.util.MyKeepAliveHandler]
- Error reading URL: https://www.company.com/mypackage/login
java.lang.IllegalStateException: Error reading URL:
https://www.company.com/mypackage/login
at de.company.util.http.MyURLReader.getUrlHtml(MyURLReader.java:174)
at de.company.util.http.MyURLReader.getUrlHtml(MyURLReader.java:120)
at
de.company.mypackage.util.MyKeepAliveHandler.checkGUI(MyKeepAliveHandler.java:164)
at
de.company.mypackage.util.MyKeepAliveHandler.ping(MyKeepAliveHandler.java:249)
at
org.apache.cocoon.www.blocks.company.mypackage.xsp.static_.aliveCheck_xsp.ping(org.apache.cocoon.www.blocks.company.mypackage.xsp.static_.aliveCheck_xsp:90)
at
org.apache.cocoon.www.blocks.company.mypackage.xsp.static_.aliveCheck_xsp.generate(org.apache.cocoon.www.blocks.company.mypackage.xsp.static_.aliveCheck_xsp:134)
at
org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:228)
at
org.apache.cocoon.components.pipeline.company.ractProcessingPipeline.processXMLPipeline.company.ractProcessingPipeline.java:579)
at
org.apache.cocoon.components.pipeline.company.ractProcessingPipeline.process.company.ractProcessingPipeline.java:481)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:144)
at
org.apache.cocoon.components.treeprocessor.company.ractParentProcessingNode.invokeNodes.company.ractParentProcessingNode.java:47)
at
org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
at
org.apache.cocoon.components.treeprocessor.company.ractParentProcessingNode.invokeNodes.company.ractParentProcessingNode.java:69)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
at
org.apache.cocoon.components.treeprocessor.company.ractParentProcessingNode.invokeNodes.company.ractParentProcessingNode.java:69)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:254)
at
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118)
at
org.apache.cocoon.components.treeprocessor.company.ractParentProcessingNode.invokeNodes.company.ractParentProcessingNode.java:47)
at
org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
at
org.apache.cocoon.components.treeprocessor.company.ractParentProcessingNode.invokeNodes.company.ractParentProcessingNode.java:69)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
at
org.apache.cocoon.components.treeprocessor.company.ractParentProcessingNode.invokeNodes.company.ractParentProcessingNode.java:69)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:254)
at org.apache.cocoon.Cocoon.process(Cocoon.java:699)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154)
at
de.company.serverPackage.cocoon.ServerPackageServerCocoon.service(ServerPackageServerCocoon.java:187)
at
de.company.otherpackage.cocoon.otherpackage.ocoon.service.otherpackage.ocoon.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
de.company.serverPackage.cocoon.ServerPackageServerCocoon.service(ServerPackageServerCocoon.java:207)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException:
Unexpected error: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1554)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1537)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1130)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1107)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:405)
at
sun.net.www.protocol.https.company.ractDelegateHttpsURLConnection.connect.company.ractDelegateHttpsURLConnection.java:166)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:977)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
at de.company.util.http.MyURLReader.getUrlHtml(MyURLReader.java:139)
.... 50 more
Caused by: java.lang.RuntimeException: Unexpected error:
java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:59)
at sun.security.validator.Validator.getInstance(Validator.java:161)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:108)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:204)
at
com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:249)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:954)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:123)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:454)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:884)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1096)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123)
.... 56 more
Caused by: java.security.InvalidAlgorithmParameterException: the
trustAnchors parameter must be non-empty
at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:183)
at java.security.cert.PKIXParameters.<init>(PKIXParameters.java:103)
at
java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:87)
at sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:57)
.... 67 more

Thanks in advance,

Peter

 

[EJP]

could you be more concrete - how should I fix this issue then

Make sure the truststore is correctly specified so it can be opened.
Surely that was obvious?

and how comes the exception happened without any changes on our server???

For the reason I have already given you.

 

[Peter Horlock]

Make sure the truststore is correctly specified so it can be opened.
Surely that was obvious?


For the reason I have already given you.

Hi EJP,

in the meantime, I've read a lot abotu SSL, I turned on ssl debug
and tried many other things...

I found a tomcat server on our system, where the application runs smoothly
without the "trustanchors parameter must be non-empty" error.
However, even if I completly copy the entire tomcat folder (even with the
-a archive flag), and I only changed the server's ports in the server.xml,
On the copied tomcat, the error occurs. This starts to get mystically,
neither me nor my colleagues have any other option now...

Maybe you have another idea?

Thanks in advance,

Peter

 

[EJP]

Maybe you have another idea?

No, I have the *same* idea. The truststore you specified couldn't be
opened. Nothing you have done specifically addresses that problem.

 

[Peter Horlock]

No, I have the *same* idea. The truststore you specified couldn't be
opened. Nothing you have done specifically addresses that problem.

The application (as far as I know) does not specify the truststore
location.
In the meantime, I've fixed the problem - I had to add the trustore
(cacerts file)
to the tomcat logs folder - this was missing on the server it was
working already,
as I said I had a complete copy. However, when I added the store to
the logs folder, it was working on the other server, too. I am really
confused now. How can it be that the trustore must be in the logs
folder??? Where does Java look for the store if no location is
specified?

Thanks in advance,

Peter

 

[Peter Horlock]

P.s.: This behaviour is reproducable - if I remove the cacerts file /
trustore, it won't work anymore, if I move it again into tomcat/logs
it's working again.
Maybe the file was in the logs folder of tomcat1 when it was started,
then removed. Only this could explain why it was working on Tomcat 1
but not on Tomcat2 which was a copy of 1.
I should restart Tomcat1 and see if it will still be working then.

Really strange!

Peter

 

[EJP]

Really strange!

Nothing strange about it. Clearly Tomcat is configured to look for its
truststore in the logs folder, which BTW is a really stupid place for
it, and when it isn't there it can't be opened so you get this exception.

Exactly as I said really.

 

[Peter Horlock]

Nothing strange about it. Clearly Tomcat is configured to look for its
truststore in the logs folder, which BTW is a really stupid place for
it, and when it isn't there it can't be opened so you get this exception.

Exactly as I said really.

I finally found the reason - there was a starup.sh skript
which did a cd into the logs folder just before the app was started.
Seems like Java looks for the cacerts file in the current working directory.

(I still don't know why it was working once and out of the blue stopped
from working, but I guess I will never find out - someone must somehow
have deleted the file from the logs folder, probably because she/he
thought this cacerts file in the logs folder wasn't in use anymore...

Also, I still don't know why Tomcat ignored my System property which
should have told it where to look for the cacerts file instead...

Peter

 

[Lew]

Nothing strange about it. Clearly Tomcat is configured to look for its
truststore in the logs folder, which BTW is a really stupid place for

That's not true by default.

 

[EJP]

Seems like Java looks for the cacerts file in the current working directory.

No. Java doesn't do that. It seems like *Tomcat* is configured to look
for the cacerts file in the current directory.

Also, I still don't know why Tomcat ignored my System property which
should have told it where to look for the cacerts file instead...

Because it has its own, documented, configuration file.

 

[EJP]

That's not true by default.

I agree. This Tomcat *instance* is configured to do that ... or see the
OP's explanation above ...

 

[Lew]

I agree. This Tomcat *instance* is configured to do that ... or see the
OP's explanation above ...

Just clarifying a possible ambiguity for the sake of other readers.