This content has been marked as final. Show 7 replies
816027 wrote:Not really. If you get your certificate signed by one of the standard Certificate Authorities then it's certificate chain will already be in the the Java trust store so the jar signing will be valid.
or I could used a signed jar file, but then everyone would need to install the corresponding certificate.
I just want an applet that anyone can access: "write once run anywhere".Create a public/private key pair and a CSR and submit the CSR to a standard Certificate Authorities and install the certificate they send you in your key store. Then sign the applet.
The interesting thing is that this works fine on some other machines. Has the default policy changed?I know that on an earlier JRE there was a security bug that allowed an Applet to (arbitrarily?) access URLs other than the one that the Applet was loaded from. I can't remember the detail but I'm sure Google will find it.
Also, I don't serialize anything AWT-related; the state represents a diagram, but it's a bunch of ArrayLists mostly, with only a transient reference to the panel where the diagram will be rendered. Presumably "transient" is actually honored when serializing?Of course you could have found a bug but without seeing the code that tried to write the state I can't judge.
Can anyone suggest any other way around this problem, or a way to find out exactly why readObject thinks it needs permission for sun.awt.windows?
I just want an applet that anyone can access: "write once run anywhere".
Create a public/private key pair and a CSR and submit the CSR to a standard CertificateThanks, but I don't suppose they'll do this for free (nor even cheaply, I suspect), and will need renewing at regular intervals.
Authorities and install the certificate they send you in your key store. Then sign the applet.
If I'm not serializing anything from sun.awt.windows, what is the reason for this to happen?
I will of course continue checking my code, but any suggestions as to the easiest way to find out the types of objects in the serialized state I'm loading would be most welcome.
Hmm. I've just tried it with yet another machine, also JRE6, and it moans when I try to drag & drop diagram elements from the toolbar to the diagram -- access denied to system clipboard.
I can work around this (I don't need to use drag&drop for this) but it's beginning to seem like every JVM has a different set of permissions from every other! "Write once, run on your development system but nowhere else" perhaps... :-(
An unsigned Applet can have very little access to the client computer and I seem to remember that access to the clipboard was a no-no.
Yes you will have to pay the CA to sign your certificate. Yes you will have to renew after a certain period; the period depends on how much you are willing to pay.
I don't know the relevance of sun.awt.windows; I suspect that is just a symptom of your fundamental security problem.
There is an alternative to getting your certificate signed by a CA. You could use your private key and self signed certificate then your users have two possible decisions. At the security prompt, your users can accept the self signing or not. If not then they cannot run (ALL) of your Applet. If they accept then there is tick box they can tick to indicate they will always trust everything from that certificate. If they tick this box then they will always be able to run your Applet and any other Applets you sign with your private key.
Using a self signed approach will at least enable you to decide if your problem is a pure security problem.
Checking the raw stream reveals that I am trying to deserialize nothing except a bunch of my own classes, which contain nothing apart from primitive types, Strings, Hashtables and ArrayLists.
Can anyone tell me why on earth applet security prohibits me from deserializing fundamental stuff like this? (Not to mention why it is different on different machines...)
Is the stack trace originating from your deserialization code, or from a drag & drop operation?
I happens during deserialization, at the point where I call readObject().