Granting access to signed applet not working

[Terri I.]

I have a self-signed applet (NOT using commercial CA).
It appears that I have successfully generated the necessary key
and used it to sign my jar file.
When I load the page with the applet, I actually get the popup window
asking if I want to grant or deny privileges (which seems to tell me that
the plug-in figured out that the applet was signed, could read it's
signature, and validated the 'CA' that signed the code). But if I click on
Yes or Always, the applet still doesn't work - I get the securityexception
that access is denied trying to run the executable my applet is trying to
run.
Does anybody have any suggestions? Thanks!

 

[Terri I.]

How can I tell what file the browser's JRE is trying to write to when I
say to grant access to a signed applet?? I'm wondering if the problem is that
the JRE is trying to add a certificate to a keystore/cacerts file that I don't
have write access to?? On our network, I cannot write to the C: drive, so if
the JRE is trying to update a cacerts file in that location, it will not work.
I am not getting any error messages, but just wondered if this was a possibility.

 

[Roedy Green]

How can I tell what file the browser's JRE is trying to write to when I
say to grant access to a signed applet??

Usually you build that into the policy file. That is where you can
give fine grained permission to some Applets and not others about
exactly where they are allowed to write.

 

[Roedy Green]

Update: I got temporary administrator access to my machine and the problem
definitely seems related to my inability to write to my C:. I tried a sample
signed applet from the Sun site - it worked fine while I was logged on as
administrator, but failed while logged on as a regular user (i.e. no write
access to C.

Sooo, how can I tell the plug-in to access the cacerts file from some other
location?? In our environment, asking users to modify their policy files is
not a viable option.

Why do you think this is a problem with getting the wrong cacerts
file?

cacerts is supposed to be system wide, not a private administrator
file. Granted, you may have a dozen of them, one per JDK, JRE, JWS....

Do you have Sun's standard policy file in place? Are there any other
policy files that may be getting used instead?

 

[Terri I.]

Why do you think this is a problem with getting the wrong cacerts
file?

cacerts is supposed to be system wide, not a private administrator
file. Granted, you may have a dozen of them, one per JDK, JRE, JWS....

Do you have Sun's standard policy file in place? Are there any other
policy files that may be getting used instead?

I thought it might be a problem with the cert being added to the cacerts
file since it works for me when I'm logged on as a user that has write
access to the C: (where the JRE's cacerts file is located). The standard
policy file is also there, and without changing anything related to it,
again, signed code seems to work when I can write to the C: drive. It's not
that cacerts is not accessible to everyone, but it cannot be written to by
everyone if it is sitting on the C:.

 

[Terri I.]

Why do you think this is a problem with getting the wrong cacerts
file?

cacerts is supposed to be system wide, not a private administrator
file. Granted, you may have a dozen of them, one per JDK, JRE, JWS....

Do you have Sun's standard policy file in place? Are there any other
policy files that may be getting used instead?

One other thing. I did try to run the keytool -import command against the
cacerts file to see if I could directly import my self-generated cert in there,
and as expected, I got an access denied message on the file since it is on
the C: drive. So while the plug-in seems to recognize the cert for my signed
applet, it does not recognize the CA cert. I have seen threads where people
talk about using self-signed certs in this way - I'm wondering if none of them
had to deal with users who could not write to their C: drives (or whatever
drive the JRE is located on).

 

[Terri I.]

There is another way of looking at this. The administrator does not
want his users installing software on C: He thus blocked access to C:

This block worked. The solution is to call in the admin, and let him
supervise the install.

I've had to do this just to install a SET parameter at one of my
clients.

That's fine for a 1-user install. But I am working on an application that is
available to everyone in our organization, so I don't want the users to have
to do something special for the setup. I'm going to have to think of another
way to do this if I can't tell the plug-in to look elsewhere for the cacerts
file. My application worked fine with a self-signed cert in Netscape 4.75, this
just seems like a step backwards...