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)

On the web, I've found the following:
>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

On 29/03/2010 8:25 PM, Peter Horlock wrote:
> 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.

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

Peter Horlock wrote:
> 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.

--
Lew

On Mon, 29 Mar 2010 11:25:29 +0200, Peter Horlock
<peter.horlock@googlemail.com> wrote, quoted or indirectly quoted
someone who said :

>"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.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com

If you tell a computer the same fact in more than one place, unless you have an automated mechanism to ensure           they stay in sync, the versions of the fact will eventually get out of sync.

Roedy Green wrote:

> 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: spamfang@kimmeringer.de
               PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

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

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

On 29/03/2010 11:17 PM, Peter Horlock wrote:
> 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.

EJP schrieb:
> On 29/03/2010 11:17 PM, Peter Horlock wrote:
>> 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.
> 

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

On 9/04/2010 10:20 PM, Peter Horlock wrote:
> 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.

On 10 Apr., 01:34, EJP <esmond.not.p...@not.bigpond.com> wrote:
> On 9/04/2010 10:20 PM, Peter Horlock wrote:
>
> > 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.

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

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

On 13/04/2010 4:33 PM, Peter Horlock wrote:
> 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.

EJP schrieb:
> On 13/04/2010 4:33 PM, Peter Horlock wrote:
>> 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.

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

EJP wrote:
> 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.

> it, and when it isn't there it can't be opened so you get this exception.
> 
> Exactly as I said really.

-- 
Lew

On 14/04/2010 9:01 PM, Peter Horlock wrote:
> EJP schrieb:
>>
>> Clearly Tomcat is configured to look for its
>> truststore in the logs folder

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

On 15/04/2010 7:24 AM, Lew wrote:
> EJP wrote:
>> 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.

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

EJP wrote:
> On 15/04/2010 7:24 AM, Lew wrote:
>> EJP wrote:
>>> 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.
> 
> 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.

-- 
Lew