Servoy version 7.4.2 -releaseNumber 2033
java.version=1.8.0_25
os.name=Windows Server 2008 R2
MSSQL 2014
I just finished a new Servoy server installation. When our solution is run in a smart client (on the server), we get a JRE exception stating that j2db is blocked due to a expired/invalid security certificate. The forum has several posts related to this, and I tried the suggestions that modify the JRE settings but still cannot get the solution to run. Here are the things tried:
General → Network Settings → Direct
Advanced → Perform certificate revocation checks on (Various combinations of: e.g. All certificates in the chain of trust / Certificate revocation lists (CRL’s), etc. )
I am open to suggestions. Also, the j2db in question is in Servoy’s folders (i.e. not something I loaded), so why is it being blocked by the JRE?
I just checked and Servoy 7.4.2 is signed with a now expired certificate. You need to install 7.4.3 which is signed using a new certificate.
If for some reason you NEED the 7.4.2 release then you need to resign everything using your own certificate.
I used Patrick Talbot’s excellent Code Signing Utility.
You just place the jar in your application_server directory, launch it and navigate in the tree to a jar and the pane on the right shows you all the information.
[attachment=0]Screen Shot 2015-03-03 at 22.59.12.png[/attachment]
Of course you can also use this tool to code-sign everything with your own certificate.
I upgraded the server to 7.4.3. When I launch the solution, I get a warning message regarding j2db, but it doesn’t block the solution from running. However, I get a second message regarding IClock that does block the solution from running. Using Patrick’s Code Signer, I looked at IClock and other beans (e.g. in Beans: HTMLBean, Molecule, S11_chart) as well as various plugins, and found that many of them have an ending valid date of February 2015 (past due) on Servoy’s certificate. Some have a blank status, others have a status of Locked (I don’t know what this means), but none have a status of Expired. I am guessing that Servoy needs to re-sign their distribution files…is that correct?
I guess the issue is in the upgrading. It only upgraded changed files.
I bet that when you do a clean install all the components will be signed with the latest certificate.
(this is also the reason why the update didn’t also update those correctly)
if you don’t use them just remove them from your application server beans dir
if you resign your self then ofcourse there is no problem, i will update the main release thread with a zip of the jars that are then signed correctly
@Robert: I completely removed 7.4.2 including the repository and installed 7.4.3, but as Johan pointed out, the items with expired certificates were still present. Also, there was a reason why I reverted to 7.4.2…the server will import our solution in 7.4.2 but not in 7.4.3: an SQL error is thrown, but I cannot track it down. I will start another thread for this.
I assumed you upgraded an existing install because you said you ‘upgraded the server to 7.4.3’.
But I was wrong anyway. Like Johan said, when a file is resigned then it should have seen as a changed file anyway and should have replaced it.
As for the import issue, are you referring to this thread?
I started with a new/virgin installation of 7.4.3 but could not get our solution to load. So, I completely (including deletion of the repository database) uninstalled 7.4.3 and replaced it with 7.4.2 which would load the solution but not run it due to the expired security certificates). Then, I upgraded 7.4.2 to 7.4.3 but still had the solution loading issue. So, I uninstalled everything and completely re-installed 7.4.3 (per your suggestion) which is where I am at today (cannot load solution due to unknown SQL error). Your sleuthing of the j2db expired security certificate and tip for Patrick’s Code Signer is what saved the day!
I posted an earlier thread about the solution not loading due to an unknown SQL error:
