Java Certificate Block - but from which jar or app?

Questions
1

Is it possible to find out which plugin or other app is causing the blocking that can be seen from the screenshot ?
(Java complains about an expired certificate)

Our usual plugins all have valid certificates.

When I open the complete tree in the “Code Signing Utility” from Patrick Talbot, all jars either have a “locked” symbol or a green symbol with a small s, meaning “signed with current certificate”.
There is no jar in the complete tree that shows the symbol for “Signatur is expired or invalid”

It does not help to add our JNLP to the Java exception list for the specific user. In other cases, that helped.

java_is_blocking_2.jpg
java_is_blocking_2.jpg843×644 76.1 KB

2

I just got more information, but have to wait if this is already a final workaround for the problem for all installations.

It seemed to help to put only the first part of the complete JNLP-path into the exception list, without the JNLP-file itself.
So instead of

http://de1****to.net:8080/servoy-client/b.jnlp
we did put only the first part to the exception list:

http://de1********to.net:8080

According to this Java doc, that means that this is then the OK for all files below:

https://www.java.com/de/download/faq/exception_sitelist.xml

So any JAR on the Servoy Server that has a certificat problem seems to be accepted after that measure.

The Terminal Server had the Java Version 8 Update 144, I recommended to update to 8 Update 231

3

Do you have your own code signing cert that you use or do you use them however they come signed?
If you have your own, download keystone explorer and inspect the key store. Look at each cert in the chain to make sure it didn’t expire. https://keystore-explorer.org/
If you don’t have your own code singing cert, then one of the third party certs may have expired. For example the IT2BE code singing cert we use had the Sectigo root expire so we released an update a few days ago with updated certs.

4

Thank you for your tip, I will try to do so.

What I really find strange is that only very few users are affected.
Normally, it’s “Computer says NO!” in all cases when a certificate is wrong.

And as a quick workaround, I do not know which path I should store to the Java Exception list.
All our plugins are below
D:\servoy_new\application_server

Does someone know how to access this very path when the server name on the company network is something like
http://de19axxx.aaa.bbb.net

5

I just got a hint from Johan to shut down the server first.
After that, I could look again for the complete JAR tree in the Code Signing Utility (after restart of that tool), and actually detected two not properly signed JARs.

6

I know this is after the fact, but I want to mention it for others…

Whenever you run the Code Signer utility, the yellow/gold ‘locked’ icon indicates that the certificates cannot be accessed, because the Servoy server is running. To fully use Code Signer, you must first stop the Servoy server service, run Code Signer as needed, then re-start the Servoy server. I am not certain this is stated in the Code Signer manual…we learned this the hard way.