# Java Certificate Block - but from which jar or app?

**URL:** <https://forum.servoy.com/t/java-certificate-block-but-from-which-jar-or-app/20250>\
**Category:** Questions\
**Created:** [June 10, 2020, 1:22pm UTC](https://forum.servoy.com/t/java-certificate-block-but-from-which-jar-or-app/20250 "2020-06-10T13:22:09Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bernd.N](https://avatars.discourse-cdn.com/v4/letter/b/7feea3/32.png) [@Bernd.N](https://forum.servoy.com/u/Bernd.N)\
**Post date:** [June 10, 2020, 1:22pm UTC](https://forum.servoy.com/t/java-certificate-block-but-from-which-jar-or-app/20250/1 "2020-06-10T13:22:09Z")

</div>

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](https://canada1.discourse-cdn.com/flex010/uploads/servoy/original/2X/c/c5d0ae19766a47a2c0fb0afa10412a911af666c1.jpeg)

---

<div class="post-metadata">

**Author:** ![Bernd.N](https://avatars.discourse-cdn.com/v4/letter/b/7feea3/32.png) [@Bernd.N](https://forum.servoy.com/u/Bernd.N)\
**Post date:** [June 11, 2020, 1:03pm UTC](https://forum.servoy.com/t/java-certificate-block-but-from-which-jar-or-app/20250/2 "2020-06-11T13:03:08Z")

</div>

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](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](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](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

---

<div class="post-metadata">

**Author:** ![sbutler](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.servoy.com/sbutler/32/4393_2.png) [@sbutler](https://forum.servoy.com/u/sbutler)\
**Post date:** [June 11, 2020, 6:02pm UTC](https://forum.servoy.com/t/java-certificate-block-but-from-which-jar-or-app/20250/3 "2020-06-11T18:02:43Z")

</div>

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/](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.

---

<div class="post-metadata">

**Author:** ![Bernd.N](https://avatars.discourse-cdn.com/v4/letter/b/7feea3/32.png) [@Bernd.N](https://forum.servoy.com/u/Bernd.N)\
**Post date:** [June 12, 2020, 8:44am UTC](https://forum.servoy.com/t/java-certificate-block-but-from-which-jar-or-app/20250/4 "2020-06-12T08:44:40Z")

</div>

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](http://de19axxx.aaa.bbb.net)

---

<div class="post-metadata">

**Author:** ![Bernd.N](https://avatars.discourse-cdn.com/v4/letter/b/7feea3/32.png) [@Bernd.N](https://forum.servoy.com/u/Bernd.N)\
**Post date:** [June 12, 2020, 1:43pm UTC](https://forum.servoy.com/t/java-certificate-block-but-from-which-jar-or-app/20250/5 "2020-06-12T13:43:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kwpsd](https://avatars.discourse-cdn.com/v4/letter/k/bb73d2/32.png) [@kwpsd](https://forum.servoy.com/u/kwpsd)\
**Post date:** [June 12, 2020, 4:57pm UTC](https://forum.servoy.com/t/java-certificate-block-but-from-which-jar-or-app/20250/6 "2020-06-12T16:57:22Z")

</div>

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.
