Cannot do http requests from hc after ssl update

Classic Servoy
1

Last week we renewed our SSL certificate that we use on our *.stb.nl saas servers. But since then we experience problems with using the http plugin to invoke REST api’s on some servers.
We do this in a headless client in a war deployment.
We used to run with APR (crt files) instead of the jks (java implementation). This does not matter, however on some servers it works, on others it doesn’t.
To update the SSL certificate we replaced the jks file in Tomcat conf or in case of APR, the main .crt file.

In servoy-admin we see these errors:

javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
	at sun.security.ssl.Alerts.getSSLException(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.handleException(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:535)
	at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403)
	at com.servoy.extensions.plugins.http.HttpClient$1.connectSocket(HttpClient.java:105)
	at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
	at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
	at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
	at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
	at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
	at com.servoy.extensions.plugins.http.BaseRequest.executeRequest(BaseRequest.java:212)
	at com.servoy.extensions.plugins.http.BaseRequest.js_executeRequest(BaseRequest.java:138)
	at com.servoy.extensions.plugins.http.BaseRequest.js_executeRequest(BaseRequest.java:124)
	at sun.reflect.GeneratedMethodAccessor953.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:158)
	at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:312)
	at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1774)
	at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:837)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:158)
	at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:406)
	at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3204)
	at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:156)
	at com.servoy.j2db.scripting.ScriptEngine.executeFunction(ScriptEngine.java:665)
	at com.servoy.j2db.plugins.ClientPluginAccessProvider$MethodExecutor.run(ClientPluginAccessProvider.java:564)
	at com.servoy.j2db.server.headlessclient.SessionClient.invokeAndWait(SessionClient.java:931)
	at com.servoy.j2db.plugins.ClientPluginAccessProvider$1.run(ClientPluginAccessProvider.java:478)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
	at sun.security.validator.PKIXValidator.<init>(Unknown Source)
	at sun.security.validator.Validator.getInstance(Unknown Source)
	at sun.security.ssl.X509TrustManagerImpl.getValidator(Unknown Source)
	at sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(Unknown Source)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
	at org.apache.http.conn.ssl.SSLContextBuilder$TrustManagerDelegate.checkServerTrusted(SSLContextBuilder.java:190)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(Unknown Source)
	at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
	at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
	at sun.security.ssl.Handshaker.processLoop(Unknown Source)
	at sun.security.ssl.Handshaker.process_record(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
	... 32 more
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
	at java.security.cert.PKIXParameters.setTrustAnchors(Unknown Source)
	at java.security.cert.PKIXParameters.<init>(Unknown Source)
	at java.security.cert.PKIXBuilderParameters.<init>(Unknown Source)
	... 46 more

Now this looks like a problem with Java or its cacerts but really all that changed is our certificate. War deployment and solution is the same. Java versions is 8u161 on all systems. I tried removing and updating it to 8u171 but no luck.
A webservice call from the client on the server itself (using RDP) works fine, just not in headless clients.

Does anyone have a clue what can cause this issue?

2

Hi Ruben,

maybe the rating is lower than it used to be, and servers are blocking you for that reason.
Checkout your rating on: https://www.ssllabs.com/ssltest by entering the url.

Hope that helps

3

Hi Marc,

Thanks for your message. According to that site we have an A rating, seems to be good enough.

4

This is a real strange issue, which we never saw before. We have looked into this, but IMHO this has nothing todo with the certificate installed in tomcat (for you incoming connections)
You do a call from the same server, to external (ssl) API, and than you got this error…

And even stranger… in a client on the server itself works, but on the same server in a headless client this does’nt work (on some servers! other servers do work)
Right?

Are you 100% sure, there are no (double) installed Java?
Did you try, to completely uninstall Java. (really check if all Java folders are removed…) and do a clean install? And restart the server after that?

5

Yes it just doesn’t work in a headless client. But on other servers it does indeed. Smart client always works.

I have to agree it’s probably not the SSL certificate for that reason. But on the other hand, really the only thing that changed is the SSL certificate.
So it must be somehting else in the stack. Of course I tried to remove/reinstall java completely, remove all java directories, restart, everything (I think).

6

OK, me and Harjo had a look together and we found a solution. If we run Tomcat under the Administrator account instead of the Local System account, it works again.
What we didn’t find out though, is the reason why :P So maybe it’s just a coincidence as this doesn’t seem to be related to the new certificate. However we really had the problem since the SSL certificate was changed.

Can anyone shine a light on this? Johan?

7

Could this be a privilege issue?
Maybe the local system account wasn’t allowed to read the keystore file from the location where it was stored?

8

My guess aswell, but why did SSL work correctly for incoming requests but not for outgoing via headlessclient?
Probably the cacerts was not accessible but how can that happen from one day to the next?

9

we already also have a thread here: viewtopic.php?f=22&t=21848

but somehow this is really something that the basic ‘cacerts’ file is not correct somehow.

at least thats what they are saying here:

https://stackoverflow.com/questions/678 … -non-empty

but bob had the exact same problem (with the exact same stacktrace) in that other forum post.

10

in coming request are completely different, thats tomcat keystore (if you let tomcat handle the ssl)

outgoing just uses the basic java installation, so the default java certificate store to connect to https urls.

Those are 1 different worlds, not directly related to each other.