We have been using a java applet from a 3rd party vendor for years. The vendor no longer exists. The certificate is expired and java is showing a warning message every time users access the applet.
Is there some way to mark the certificate or the JAR as being trusted so it doesn't keep warning users?
Get yourself a new code signing certificate and sign the JAR file(s) yourself.
Related
We develop several Java apps for internal use within our company (jnlp). With Java 1.7u40 we are seeing a nasty warning that unknown publishers will not be allowed to run in future java releases.
I understand your jars need to be signed by a trusted CA for code signing ... self signing will not suffice. I don't like the fact that we now will have to pay just to sign our apps for internal use only. I truly must be misunderstanding something. Is there a way to code sign the jars so that they will continue to run with future java releases without the need to pay a CA (Verisign, etc)?
If your company runs an internal CA, then you can issue a code signing certificate from that. Most companies that use Active Directory will also have a CA deployed.
Another approach would be to run a script on all company machines that installs the code signing certificate into the trusted certificates store.
I've made a Java applet and I self signed it before, but due to security changes in recent Java updates, self signing no longer gives the applet the necessary permissions.
I need the applet to be able to read the local file system to use images and to be able to connect to a MYSQL database.
The applet used to work with the database when I self signed it, but not anymore.
In addition, many unknown users will be using the applet, so I won't have control over their machines.
Where can I get my applet professionally signed and if possible, is there another way to self sign that will make the applet work?
Purchase a certificate from any reputable certificate authority. Use that to sign your code. List of CAs
Or, some companies also do this: Sign the jars themselves, but pre-populate the JDK trust store with your (self created) CA cert. If you have control over the JRE that is installed on all user machines, you can place your certificate in JRE/lib/security/cacerts so that is trusted ahead of time.
update: This page (Java Control Panel Documentation) describes what type of signature is required for various client side security level settings:
As long as the applet 'phones home' to the DB & this demo. of the JNLP API file services1 works for the problem machines you should be set to go for a Plug-In 2 JRE (1.6.0_10+) JRE. And if the client has less than that, they should seriously look to update. The Deployment Toolkit Script can assist with that.
It is relevant in that:
It uses a self signed certificate
It allows a sand-boxed app. to read/write to the local file system.
An applet launched using JWS has access to the API.
This should only be considered a work-around. The correct way to solve the problem is to heed the advice offered to get a certified code certificate. Oracle seems to be heading towards making it so that unsigned or self-signed code will not just be sand-boxed, but entirely forbidden (& that is for the best).
As an aside re. DB access: For the protection of the DB. The applet should be forced to go through a 'public interface' (via the site that hosts the applet). Do not give the applet direct access to the DB. Otherwise hackers also have direct DB access.
I created an application which is currently on Android market. The key used to sign the application was made using jarsigner. How do I sign using the .key file originally generated?
You will need the original private key that you used to sign the first version.
Full information is available here, but here is the excerpt it sounds like you need:
Application upgrade – As you release
updates to your application, you will
want to continue to sign the updates
with the same certificate or set of
certificates, if you want users to
upgrade seamlessly to the new version.
When the system is installing an
update to an application, it compares
the certificate(s) in the new version
with those in the existing version. If
the certificates match exactly,
including both the certificate data
and order, then the system allows the
update. If you sign the new version
without using matching certificates,
you will also need to assign a
different package name to the
application — in this case, the user
installs the new version as a
completely new application.
AFAIK, .key is not a standard (conventional) file ending. Most of the time you are working with a .keystore file. The keystore contains the key. The keystore and the key both have passwords and separate security measures for safety.
If you generated your ".key" file using jarsigner and one of the commands listed here, then you likely created a keystore file and happened to give it the ending ".key" If this is the case, then just compile your application into release mode, sign the application using the jarsigner tool, and use zipalign (not sure what this is for, compression perhaps?).
If you don't have the original keystore and key file, then you're boned. Sorry :/ Tons of other info can be found on the Signing Your Application page
HTH,
Hamy
I have a web application that downloads a jar file from the web server using java web start. The jar is signed using J2SE security tool. However, I get the security warning "The application digital signature cannot be verified. Do you want to run the application?"
Am I missing something that is causing this??
If it is self-signed you also need to add the certificate into windows certificate store.
If you use a Certificate Authority such as Verisign then you will not have the problem.
See here for an explanation (from Verisign) on why to sign from them.
Java 1.5 added an enhancement to support signature timestamps. The idea, as far as I can tell, is that signed jar files should not become invalid just because the code signing certificate has expired, as long as the files were signed while the certificate was valid. In theory, this means we do not have to re-sign and redeploy our applications every year when the certificate expires. Unfortunately, there seem to be problems in the implementation, based on these two forum threads:
http://forums.sun.com/thread.jspa?threadID=744677
http://forums.sun.com/thread.jspa?threadID=5309004
I'm about to begin testing this, but I was wondering if anyone has successfully done this, without having to import the timestamping certificate on the client (which would defeat the whole purpose)?
The Thawte TSA root certificate was added to Sun's JRE cacerts file in 6u10 and 5.0u18.
Unfortunately, this feature appears to be completely worthless at this time. It is easy to add a timestamp when signing a jar file, just add this parameter to the jarsigner command:
-tsa https://timestamp.geotrust.com/tsa
This is the URL to Thawte's timestamping server. Unfortunately, the Thawte timestamping CA cert is not included in the Java runtime's list of trusted CA certs, so it is effectively meaningless. That is, if you load the applet after the code signing certificate has expired, you get the "untrusted" warning dialog instead of the "trusted" one.
There is a "workaround", of sorts, posted here, but it works by embedding the Thawte timestamping CA cert in the applet itself, and running keytool on the client to import the cert. I can't see how this would work though, since the user will already have seen the signed code dialog before this code can run.
I'll keep looking for a solution, but I'm not hopeful. I can't imagine why a usable timestamping CA cert has not been included with the Java runtime after all this time.