I have a webstart application that accesses http://jogamp.org/deployment/v2.2.4/jogl-all-awt.jnlp. For the past few days I've been getting a notification that the certificate used to identify this application has expired, and my app gets blocked from running. The dialog shows:
I'm not sure that we're going to sign anew an old release with a valid "trusted" certificate, it's up to Sven to decide, please contact him.
In the meantime, maybe you should really plan to switch to JOGL 2.3.2, it's not a big deal, there have been some changes in the API but they are quite trivial, some packages have been renamed and the Screenshot class has been removed.
I'm really sorry for the disturbance. Do you use only Webstart?
Julien, thanks for the response. We don't use webstart exclusively. The apps are also deployed as standalone Java applications on our store kiosks. However, in those cases we package the jogl jar file right in our deployment. We only access the jogamp website when using webstart to run these apps.
I attempted to run using the 2.3.2 version and actually saw the same problem. I cleared my entire Java cache before attempting that webstart run. I see the same message - "The certificate used to identify this application has expired". From what I can see it looks like all of the jars have this issue. If I run with my Java security set any higher than "medium" the application will be blocked from running.
You can host JogAmp itself on your own server and sign its JARs with your own signature to work around the current problem. This is what I did for years, I even ended by making a single fat JAR with a single JNLP file.
I used my own server to store all JARs because there were some troubles because of Pack2000.
I have no update from Sven. The problem is that the JARs are signed with his personal certificate :s In the future, it would be better if we used a certificate for the whole organization to avoid relying on a single person because it's weak and problematic when this one is unavailable. If you need a quick workaround, why not pointing to your fat JARs in your JNLP file(s)?
I've tried downloading the jogl all platforms 7z and signing all the jars with the same CA issued key we use to sign our app, but we still get "Application blocked by java Security" dialog for Name: Java(tm) Binding to the OpenGL(r) AP ...
This is the kind of thing I do at work and it has worked flawlessly for several years but you need to be 100% sure that absolutely all JARs mentioned in a single JNLP file use the same "trusted" certificate. Moreover, you need to remove the existing signature files (RSA and DSA files). Personally, I prefer making a single fat JAR with the correct information, the correct manifest with the mandatory attributes especially about the permissions, the application name, etc.
every jar I checked didnt have an existing signature. I signed them all with the same key (we only have one key). I used a script to do it and checked the date modified time of all of them to make sure I didnt miss any.
You have to take care of the following manifest attributes:
- Trusted-Library / Trusted-Only
which manifest files do I have to modify? jogl-all.jar gluegen-rt.jar and then the windows-x-x.jar and other platforms?
any other ones?
so jogl-all.jar for instance looks like
Implementation-Title: Java Bindings for OpenGL Runtime Environment
Application-Name: Java Bindings for OpenGL
Specification-Vendor: JogAmp Community
Created-By: 1.8.0_60-b27 (Oracle Corporation)
Implementation-URL: http://jogamp.org/ Implementation-Vendor: JogAmp Community
Ant-Version: Apache Ant 1.9.4
Specification-Title: Java Bindings for OpenGL API Specification
what would I have to change these too? and why do I have to change these when the online web versions that we linked to on the jogl site used to just work before the security update without modifying their manifest files?
At least, set "Codebase" to "*" or to a meaningful value depending on where you store the JARs, do so in all JOGL and GlueGen JARs you use including those containing the native libraries. I understand that it's very painful. Sven seems to be extremely busy, I'll ask him when he can renew the trusted certificates again.