signed jar file-- jnlp fails to prompt user to accept certificate

Question

I am an amateur programmer. I created an application which consists of a single, self-signed jar file. The application will be used only by students in my math class, so I think self-signing is okay.

I followed the Oracle instructions to sign the jar and then used the jarsigner tool to verify the jar. Supposedly, it was fine.

In the .jnlp file, I included the security tag with all-permissions:

    <security>
        <all-permissions/>
    </security>

When the program launches, however, I never see a dialog prompting the user to accept the certificate or asking for some kind of permission to run on the client computer. It was my understanding that I should see such a dialog, according to Oracle documentation.

I have read this page on stackoverflow:

JNLP get a permission

and I have a similar situation in that I get a security exception. In my case, the exception is thrown when the app attempts to show a filechooser dialog:

java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)

This is because the user was never asked to provide permission. I believe I followed the advice on that stackoverflow page, but it doesn't seem to be working for me. It's like the jar appears to be unsigned. I even tried removing the all-permissions tag and got exactly the same behavior.

I have looked inside the jar and I can see that the two required files are in there: MYKEY.DSA and MYKEY.SF. I looked inside the readable one (.SF) and it contains the text that should be there. I believe that is all the jar needs in order to be signed.

So here are my questions:

1) Does it matter what the names are of the .DSA and .SF files are, with respect to the app? Currently they just have the name of the alias I used with keytool.

2) Does it matter if the java version on my server is 1.7 while the java version on my development computer is 1.6? I need to compile in 1.6 because our school has not upgraded to 1.7, so when it runs on client computers it needs to be 1.6.

3) Is there a way to determine which version of jarsigner I am using when I run it from the terminal? I tried jarsigner -version, but that is not one of the options. I notice that the top of the MYKEY.SF file looks like this:

    Signature-Version: 1.0
    Created-By: 1.4.2-02 (Blackdown Java-Linux Team)
    SHA1-Digest-Manifest: OHMs6w/CQlG3MVYNxC7l1vTWdZw=

    Name: org/arps/tranz/TranzActionMap.class
    SHA1-Digest: dSI3RKfgUrRHbwnZLyXbkiJLWdU=

Does this mean that there is actually some older version of jarsigner running? I didn't think Java 1.4 was still on my computer. In any case, my version of jarsigner seems to create the same kind of file as seen here:

http://docs.oracle.com/javase/tutorial/deployment/jar/intro.html

I don't know if files created by a 1.6 jarsigner or 1.7 jarsigner look any different, or if it should matter.

4) If the version of jarsigner is the culprit, how do I force a newer version of jarsigner to run from the terminal (Ubuntu)?

Thanks for your help. As I said at the start, I am an amateur programmer. All I really want to do is to be ready for my classes next week.

UPDATE:

After struggling for quite a time with a jar tool that couldn't find libjli.so, I have now successfully used the 1.6 jar tool and jarsigner tool, so that the top of the MYKEY.SF file looks like this:

    Signature-Version: 1.0
    SHA1-Digest-Manifest-Main-Attributes: DGUFMaJYirZi//67NI+M5RVi63k=
    Created-By: 1.6.0_03 (Sun Microsystems Inc.)
    SHA1-Digest-Manifest: ZPS3aOyPW/tymxbGdfe4/qBVK/g=

But I still get the same behavior, where the app starts to launch without asking the user to accept the certificate. So now my main question is:

Does it matter that the jar was created with 1.6 while my server is running 1.7?

I don't know how much java activity actually happens on the server. At some point, it switches over to the client computer but I assume parts of jnlp happen on the server first.

Answer 1

In answer to your specific questions:

1. It is handled automatically by the jar signer tool, don't sweat the names.
2. The Java version of the server is not relevant, unless the server is compiling the code. But even then, Java apps. should be 'forward compatible'. I.E. an app. compiled in 1.5, should run in 1.5, 1.6 & 1.7..
3. I don't think the jar signer tool does anything different in the file writing since it was first made, so the version is irrelevant.
4. Irrelevant based on point (3).