Signed applets in 1.4.1: non-trust ignored: severe security problem?

Hello all,
I am signing applets with a developer certificate.
Until know everything worked fine with Plugin 1.3.1.
Know I changed to Plugin 1.4.1 and encountered a strange behaviour: When I open the HTML page with a browser (tried IE 5.5 and Mozilla 1.1) the certificate-question pops up. The problem: if I choose not to trust the certificate, the applets starts nevertheless and I can use the system clipboard inside my Applet (for what applets needs to be signed)!
This looks like a severe security problem!
Does anyone know anything about this? Can you reproduce this?
thanx!
Marcus

Hi,
I tried to reproduce what you said with plugin 1.4.0 (I don't have 1.4.1 yet) and IE6.0 (It doesn't have anything to do with the browser)
My Java console said :
"User has denied the priviledges to the code
writeFile: caught security exception"
The security seems to work OK in 1.4.0.
I will have to try 1.4.1.
Patrick

Similar Messages

Signed applet doesn't popup "trust applet" dialog

Hi,
I have the following situation with a Java applet:
It is VeriSign signed and needs access to the hard drive.
It works fine on most computers and prompts the user if they want to trust the applet.
But on some computers this trust window never appears.
The window I'm talking about is this:
Warning - Security
The application's digital signature has been verified.
Do you want to run the application?This question just won't show up on some computers.
I know that some of them are running Vista, and I know that UAC is causing major issues (I found a site explaining the reason).
Is there anything simple that I can tell Vista users to do to give permission to the applet to run?
Is there anything at all I can tell Vista users?
Thanks!

Dunno why Vista or XP or IE would be causing this with settings... except to not let applets run at all. The signing control is managed entirely by the plugin in any recent Java version (1.4+, at least).
Untrusted applets would have to be added to a list, if there was one, which I'm not aware of a list.
If this were an issue with default configs on Vista or XP or IE, believe me I would have heard about it all up and down the last year+. Early last year, we released a new applet which is signed, and that's how I know that 1.4.1_02 doesn't work at all. And late last year we actually started using new functionality that would take advantage of the signed applet (talking to another server) so, if that didn't work on a lot of client's PC's, I would have heard long before now.
What is the problem, actually? Is the applet running at all? If so, are you sure it's not running as a signed applet (can you test with something an unsigned applet couldn't do)? Cuz there is the "remember this decision" option so you don't have to get the warning more than once from the same signer.

N95 gives message non-trusted on signed certificat...

Hello,
I hope I poste this on the correct discussion board
I have a N95 device that I have setup to receive mails and update my calendar. After configuring the device I receive a message indicating (translation=)'the site has sent a non-trusted certificate. Still continue?' This message appears every time the device syncs. I have a trusted certificate from Verisign installed on the server, do I need to install the certificate on the device or am I doing something wrong? I thaught that a signed certificate didn't need to be installed? Please advice (sorry if this seems a stupid question but I'm not familiar with mobile devices thx for the help)

if your trying to use PC suite while the phone is connected, the mode to select will be PC suite mode.
other than that, make sure the keypad is not locked
if your trying to use mass storage mode, turn off PC suite first and make sure that the phone detects a memory card in it
if my post helped u out, please click the Star next to it to add some KUDOS to my name

How to Randomfile access Non-Signed Applet?

How to access a file with RandomFile Access with a non-signed Applet?
Similar to this but with Random Seek,Read, Write.
BufferedReader inData = new BufferedReader(new InputStreamReader(home.openStream()));
Thank you

Have you looked at
http://java.sun.com/docs/books/tutorial/essential/io/index.html

OS X 10.5.6, Safari 3.2.1 hangs when second applet loaded is signed applet

Dear Forum,
I've been investigating a customer's problem. She is trying to use our
VoIP applet, but it continuously freezes Safari when the Trust dialog shows.
A "Force Quit" is necessary.
I managed to reproduce the problem consistently on
- PowerMac7 OS X 10.5.6 (Build 9G55)
- Architecture: ppc
- Safari 3.2.1 (5525.27.1)
- JVM 1.5.0_16 from Apple
The problem is persistent when:
- the signed applet is loaded as second applet in the browser
- the signed applet is cached by the JVM
Our customer uses:
- Mac Book ProOS X 10.5.6
- Safari 3.2.1
- JVM 1.5.0_16 from Apple
This problem does not occur on:
- Mac OS X 10.4.11 (Mac Powerbook G4)
- Safari 3.2.1 (4525.27.1)
- JVM 1.5.0_16 from Apple
and not on:
- MacBook Air, OS X 10.5.6, 1.6 Ghz Intel core 2 duo
- Safari Version 3.2.1 (5525.27.1)
- JVM 1.5.0_16 from Apple
Steps to reproduce the problem:
Launch Safari.
In (first) page/tab go to
http://www.javatester.org/version.html
(this uses a non signed applet)
Open a second tab. Here go to:
http://ukapi.phonefromhere.com/talk/vtop2.xsql?key=01612884242
This is a signed applet that will ring our office over VoIP.
Click the "Trust" button (signed by PhoneFromHere).
As long as this applet isn't cached by the JVM this will work, so
the first time you will succeed.
Now Quit Safari (not "just" close all Safari windows, but a "real" quit) and repeat the exercise.
The second (and next) time this will fail (only if the signed applet is loaded as second, so the order is important)! This keeps failing until I go (back) to the Java Preference window (via Finder) and explicitly delete the cached files.
The URL will work when loaded first (cached or not).
Some diagnostics, that might help:
I configured the Java Preference window to "enable Logging, Tracing and Show applet livecycle exceptions".
When the applet fails to load (and Safari freezes/hangs), the last few records of the plugin150.log are:
<message>basic: Loading http://ukapi.phonefromhere.com/talk/lib/pfh.jar from cache
<message>basic: Reading cached JAR file from JRE 1.5 release
<message>basic: Certificates for http://ukapi.phonefromhere.com/talk/lib/pfh.jar is read from JAR cache
<message>security: Loading certificates from Deployment session certificate store
<message>security: Loaded certificates from Deployment session certificate store
<message>security: Checking if certificate is in Deployment session certificate store
(and then nothing)
whereas when it succeeds to load, as soon as I click the "Trust" button, it's say:
<message>security: User has granted the priviledges to the code for this session only
The Report is a bit too long to port, I'll include the same text above when sending it.
Model: PowerMac7,2, BootROM 5.1.3f0, 2 processors, PowerPC 970 (2.2), 1.8 GHz, 2 GB
To cut a long story short? Is this a know bug (I couldn't find anything, but you never know)? Does anyone have any ideas how to fix this?
Thanks, Birgit

I have the same issue now after downgrading my Flash plugin. I downgraded from 10 to 9 latest because I like using Camino and for some reason Flash 10 doesn't play nice with Camino. But all of a sudden as I use Camino 2b2 for everyday and Safari 3.2 for banking and such, the browser hangs requiring a forced quit when I close it. I've re-installed the browser twice now with all the previous folders, and preferences erased and caches emptied. I even when to re-installing 10.5.6 and it still crashes, it's odd. Maybe 10.5.7 will address this.

Signed applet in Intranet site

Hi
I have an applet which i want to make a signed applet,
has anyone created an internal certificate and use it with the applet,
are there any disadvantages for doing so, rather then getting a certificate from verisign or some third party company.
is there any expiration date for my generated certificate.
Ashish

Hi
I have an applet which i want to make a signed
applet,
has anyone created an internal certificate and use it
with the applet,
are there any disadvantages for doing so, rather then
getting a certificate from verisign or some third
party company.
is there any expiration date for my generated
certificate.
Ashish
1. A public certificate is better for it usually
executes the applet/application without prompting the
user (who might chose "No" if asked, including by
mistake). So a public/third party certificate from a
well known source is better than the one you can
create using the jarsigner tool. If you have time and
money go and use a public certificate, otherwise
create your own.
2. It does have an expiration date, usually 6 months
or so.I am looking to do the same thing as Ashish. I've tested my signed applet, which I created using keytool/jarsigner. Now I would like to eliminate any security-related interaction on the part of my users. So my 2 questions are...
1) If I go the route of obtaining a certificate from a trusted authority, are you saying I can avoid the initial "Do you trust the publisher of this applet" popup?
2) What does happens when my certificate expires? Is there a difference with a public vs. non-public certificate?
Thanks,
-Bill

Prevent abuse of a signed applet?

Hi
I am creating an application using HTML, javascript, and a set of java classes.
Communication betwwen the javascript and java is done by an applet, signed with a real certificate.
I would like to prevent someone copying my signed jar, and abusing it.
The classes behind my applet will do (a.o.) local I/O.
The type of abuse I am worried about is e.g. java code from another jar calling public methods on classes in my signed jar, using them to read or write files, and thus abusing my certificate for doing something else than my applet/jar was meant to.
I am looking for advice on how to prevent such things from happening.
Thoughts that already crossed my mind, are:
- making sure only my applet (and as few as possible other classes) has a public constructor
- declaring as much classes as possible (at least the sensitive classes) as final
- avoid non-final public static variables that contain default names of files
If anyone has some more ideas, please post them! I'll be very gratefull!
If you know about a similar question (and answer) in this forum, please let me know, as I have not found it.

harmmeijer,
thanks for the answer, and especially the idea of checking the call stack!
You scared the hell out of me however, by saying:
Your applet would not work at all in jre 1.4.2 signed or policy, when the method is called by javascriptand reading the thread you referenced!
Everything worked fine in jre 1.4.1_2 and earlier. It continued working in 1.4.2_01 in combination with Netscape (v 7.1)
But the combination MSIE (v6.0) with jre v1.4.2_01 did require a minor change:
From my signed applet, I called a .class.getResource(...).getURL()
It didn't work anymore, so I do it know in my applet's init() method, instead of in a stack started by javascript.
All my other I/O (and reflection) still works (thank all gods!), since I do it in a separate thread that I start in my applet's init() method. I hope it keeps working in jre 1.5 :-)
Any other input is very welcome!

Signed Applet not loading on Mac OS X if using HTTPS protocol

Hi All,
I need to open a trusted applet on Mac OS 10.2. The applet works fine if using HTTP protocol. But if the protocol used is HTTPS the the applet does not loads and "javax.net.ssl.SSLException - untrusted server cert chain" exception comes on the console.
The error comes for both - Verisign and javakey - signed applet.
On seaching for possible solution on the net, i came across following link: http://www.macosxhints.com/article.php?story=20020525101202503&query=Workaround+for+secure+Java+applet+problems
It says that this is Mac's known bug and gives the workaround as:
1. Access the problematic site with Internet Explorer on Windows. Click on the padlock item and export the certificate to a file.
2. Copy the certificate to your Mac.
3. Use the command
sudo keytool -import -trustcacerts -keystore /Library/Java/Home/lib/security/cacerts -file mycert.cer
to import the certificate file to your keystore (substitute mycert.cer with the name of the file containing the certificate). The keystore is password protected - the default password is "changeit".
4. Restart your browser
But the client cannot be asked to do all this to run the applet.
Is this problem being solved by Mac in their java implementation or is there any other possible solution?
Thanx in advance.
Regards,
Charu

I am experiencing the same problem - I notice it does not happen on OS9.2 using IE but appears a problem on all browsers on OSX
Apple gave me the following reply.....
Re: Bug ID# 3268633: cannot load applet class under https connection
Hello Andrew,
Thank you for bringing this problem to our attention. We have received feedback
from engineering on your
reported issue.
Please know that to get Java to recognize the certificate you will need to do
one of two things, depending
on which VM you are using. Since you want it to work with Internet Explorer, we
will assume Java 1.3.1.
In Java 1.3.1 you'll need to add the certificate to
/Library/Java/Home/lib/security/cacerts using
/usr/bin/keytool to import the certificate into the certificate database.
In Java 1.4.1 you should be able to just add the certificate to the keychain
using certtool. For more
details on how to do this, please refer to the information found at
<http://java.sun.com/j2se/1.4.1/docs/tooldocs/solaris/keytool.html>. After
doing so, if you should require
further help from Apple in resolving this issue, we recommend that you request
assistance from Developer
Technical Support. This must be done by filing a Technical Support Incident.
So I am supposed to tell every Mac user to do the above am I?!!!

File read access denied for signed applet

Hi:
I have a signed applet with a certificate generated with the keytool. Yet, I keep getting this error:
java.lang.Exception: java.security.AccessControlException:
    access denied (java.io.FilePermission C:\WINDOWS\system32\aetpkss1.dll read)The error is produced when the method loadKeyStore(pin) below is called.
    private KeyStore ks;
    private Provider provider;
    private static final String providerName    = "PKCS11";
    private static final String providerLibrary = "aetpkss1.dll";
    public void loadKeyStore(String pin) throws IOException,
     CertificateException, KeyStoreException, NoSuchAlgorithmException {
     if (provider == null)
         registerProvider(providerLibrary);
     try {
         ks = KeyStore.getInstance(providerName,provider);
     } catch (Exception e) {
         throw new KeyStoreException("Failed get keystore instance\n"
                         + e.getMessage());
     try {
         ks.load(null, pin.toCharArray());
     } catch (Exception e) {
         throw new KeyStoreException("Failed load keystore\n"
                         + e.getMessage());
    public void registerProvider(String library)
     throws FileNotFoundException, KeyStoreException {
     String fileName;
     if (new File(library).isAbsolute())
         fileName = library;
     else
         fileName = getAbsolutePath(library);
     if (!(new File(fileName).exists()))
         throw new FileNotFoundException("No such file: " + fileName);
     String config = "name = " + providerName + "\n"
         + "library = " + fileName;
     ByteArrayInputStream confStream =
         new ByteArrayInputStream(config.getBytes());
     try {
         provider = new sun.security.pkcs11.SunPKCS11(confStream);
         Security.addProvider(provider);
     } catch (Exception e) {
         throw new KeyStoreException("Can initialize " +
                         "Sun PKCS#11 provider. Reason: " +
                         e.getCause().getMessage());
    private String getAbsolutePath(String lib) throws FileNotFoundException {
     String[] searchPath;
     /* NOTE: This should be modified to suit different versions of   *
      *       Windows and not just Windows XP                         */
     if (System.getProperty("os.name").matches("^(?i)Windows.*")) {
         searchPath = new String[] { "C:\\WINDOWS\\system32" ,
                         "C:\\java" };
     } else {
         searchPath = new String[] { "/usr/local/lib/" };
     for (int i = 0; i < searchPath.length; i++) {
         if ((new File(searchPath[i] + File.separator + lib).exists()))
          return (searchPath[i] + File.separator + lib);
     throw new FileNotFoundException("Library not in search path " + lib);
    }The above code is called by a java script, the class' constructor is empty.
The error appears not to be caught by my code. I have tried to insert try/catch statements everywhere to figure out where this error is produced.
The code is write off of the applet for signing with a smart card by Svetlin Nakov - and his applet works!
I have also made a CLI application that uses the above code and it works perfectly.
So: Something is wrong either with my certificate, the signing method, signature verification or something completely different. Any hints?
The certificate I generated with
keytool -genkey -keystore mystore -alias me
keytool -seflcert -keystore mystore -alias meI have tired both with and without the selfcert step.
Thanks! Erik

The problem has been identified: Placing registerProvider() in the constructor the error no longer occurs, instead an error is produced when the key store is loaded.
It appears that the javascript code is not trusted and so, even though the applet is signed, access privileges are restricted to those of the java script.
A solution to this problem is not clear, but possibly, serving the pages from a trusted server, the java script will be trusted, some documentation seem to indicate.

Safari will not run a signed applet on mac os x 10.5.7 with new Java update

Hi Everyone,
I've got a problem that hopefully you guys can help me solve. I have an applet that runs on windows, mac and linux that is signed by a verisign certificate my work has. The certificate is valid and everything works just fine on windows and linux, but after I upgraded our macs with the newest java update for mac (which gave macs Java 1.6.13), the applets won't work. When the applet is loaded in Safari or Firefox, it asks if I want to trust the certificate. When I tell it to trust it, Safari comes back with a message saying that it will not trust the code and will treat it as unsigned code.
For a long time the applet was built and signed on windows, but now it can be built and signed on windows and mac. Building and signing on either platform gives the same results and the mac signed applet works just fine on windows.
Has anyone else run across this problem? Any help or advice will be appreciated.
Thanks,
Robbie

BenGlancy wrote:
How did you tell it to fully trust it? I thought the dialog comes up asking the user whether to trust it.
I only ask because it's not practical to expect all users to dig around for settings to trust a particular certificate.They don't have to dig around. When a signed Applet is loaded, if the certificate chain contains a certificate not in the trust store then a dialogue box asks the user if he wants to run it anyway. This dialogue box also has check box to indicate the the user should always trust this certificate and checking this means the user will not be asked again.

Java Applet Window showing on signed applet popups

I have an applet deployed that is signed, but I'm experiencing a very annoying problem with JPopup windows that cross outside the border of the JFrame created by the Applet.
Those pop-up windows still show the warning at the bottom "Java Applet Window". That part is pretty annoying and I don't understand why it's doing that since they are coming from a signed, trusted applet.
Just to be clear, any of the JPopups or JDialogs or anything else we display inside the frame doesn't have this warning since we signed the applet.

Our team is also using a signed applet and are having trouble with popup items not being accessible outside of the JFrame.
In appletviewer the popup (JXDatePicker) is fully accessible. If running in Internet Explorer on Windows 2000 the portion of the popup outside of the JFrame paints correctly but cannot receive click events correctly.
It would be preferrable that if the popup cannot receive events outside of the applet frame that the popup would be smart enough to pop itself fully in the applet frame.
Any suggestions?
Thank you.

Read Only for Non Trusted Users

Hi everyone:
Is it possible to forbid non trusted (or non certified) users for modifying the pdf (I'm interested in signing protection particularly) but allowing them to open the pdf in READ ONLY mode?
I'm wondering how to do it using Adobe Acrobat Professional 8 (info with Adobe Acrobat Pro X will be also appreciated) and opening the pdfs in their Reader corresponding versions (managing non trusted users as READ ONLY users).
Thanks for your time
Regards,
Javier

Thanks Bill:
I've been trying what you said, and is possible to "lock" the pdf so it's in read only mode via password (using Adobe Acrobat X). Is it possible to do the same with certificates? As far as I have seen, if you use certificates policies, you use the certificate to encrypt the document but then, non certified users are not allowed to access the pdf. I'm really interested in using certification restrictions but being able to access the pdf: I want to simulate the READ ONLY MODE for everybody and the WRITE mode for certified users.
Using this kind of restrictions, the only problem that I see (for end users) is that they should disable secure settings before editing / signing (this two options appear disabled with this method). Is it possible to get them available and open the "enter password" dialog when clicking them, not managing the security properties?
Thanks for your time
Regards
Javier

Signed applet does not grant AudioPermission "record"

From what I gather, if I have a trusted signed applet sitting on a webpage and
the visitor accepts (runs) the applet, then they should not need to have:
grant {
permission javax.sound.sampled.AudioPermission "record";
in their java policy file. Well I have done all this (with a certificate from
Thawte) and posted a thorough example at:
http://www.livesite.net/JavaSoundTest
At the bottom of that page there is a "Check permissions" link which will alert
true/false if we have record permission. Clicking any "Record" link will
attempt to open a TargetDataLine.
My experience (and problem) is: record permission must be granted even though
the applet is signed by a trusted CA.
I would very much appreciate any help.
Are you able to record/playback (without granting record permission in your
java policy files) with the JavaSoundTest applet webpage?
Is there something I am missing?
------ More information ------
Java Control Panel -> Advance -> Security
'allow user to grant permissions to signed content' is checked
Reproducable on:
MS NT4 w/ IE6
MS Windows 2000 w/ Firefox 1.5
MS Windows XP w/ Firefox 1.5
MS Windows XP w/ IE6
Fedora FC6 w/ Firefox 2.0
Also, this happens with a commented-out record permission in the user
.java.policy file, or when the policy file does not exist.
------ Source code: opening the target data line ------
Using the JavaSoundTest applet page without granted permission, clicking a
record link will yield this exception in the java console:
java.security.AccessControlException: access denied (javax.sound.sampled.AudioPermission record)
at java.security.AccessControlContext.checkPermission
at java.security.AccessController.checkPermission
at java.lang.SecurityManager.checkPermission
at com.sun.media.sound.JSSecurityManager.checkRecordPermission
at com.sun.media.sound.DirectAudioDevice$DirectDL.implOpen
at com.sun.media.sound.AbstractDataLine.open
at net.livesite.jsound.Recorder.run(Recorder.java:161)
while opening a TargetDataLine as:
23 private static TargetDataLine line;
157 line = (TargetDataLine) AudioSystem.getLine( lineInfo );
158
159 try
160 {
161 line.open( format, (int) format.getSampleRate() );
162 }
------ Source code: Using the security manager ------
The "Check permissions" link on the TestJavaSound applet page calls this method:
191 public boolean hasSoundRecPriv()
192 {
193 boolean ret = false;
194
195 try
196 {
197 SecurityManager sm = System.getSecurityManager();
198 if (sm != null)
199 {
200 sm.checkPermission(new AudioPermission("record"));
201 }
202 ret = true;
203 }
204 catch(SecurityException e)
205 {
206 ret = false;
207 }
208
209 return ret;
210 }
(This is a continued post from JAVASOUND-INTEREST at SUN.COM)

Is there something I am missing?1) Applets are not well supported by Sun,
and are inherently problematic as a reult
of that.
2) My experience suggests that the diagnotics
applet is not reliable for detecting JMF.
3) I guess the JMF applet is doing checks of
policy files, despite the signed code.
You might circumvent most of these problems,
by using web-start to launch an application.
Here are some of my tests at launching
JMF using web-start.
http://www.javasaver.com/testjs/jmf/

Calling1.4.1 signed applet from Javascript causes keyboard/focus problems

Pretty sure there's a JRE bug here, but I'm posting to forums before I open one in case I'm missing something obvious :-)
This issue may be specific to IE, I haven't tested elsewhere yet. Our web application is centered around a signed applet that is initialized with XML data via Javascript. We first noticed the problem when our users started upgrading from the 1.3.x plug-in to the 1.4.x plug-in. The major symptom was that shortcut keys stopped working. I debugged the problem off and on for about a month before I boiled it down to a very simple program that demonstrates the issue (included below). Basically, the program has a function that adds a JButton to a JPanel and registers a keyboard listener (using the new DefaultKeyboardFocusManager class) that prints a message to the console. This function is called by the applet's init() method, as well as by a public method that can be called from Javascript (called callMeFromJavascript()). I also included a very simple HTML file that provides a button that calls the callMeFromJavascript() method. You can test this out yourself: To recreate, compile the class below, JAR it up, sign the JAR, and put in the same dir with the HTML file. Load the HTML file in IE 5.0 or greater, and bring the console up in a window right next to it. Now click the button that says init--you should see the small box appear inside the button that indicates it has the focus. Now press some keys on your keyboard. You should see "KEY PRESSED!!!" appearing in the console. This is proper behavior. Now click the Init Applet from Javascript button. It has removed the button called init, and added one called "javascript". Press this button. Notice there is no focus occurring. Now press your keyboard. No keyboard events are registered.
Where is gets interesting is that if you go back and make this an unsigned applet, and try it again, everything works fine. This bug only occurs if the applet is signed.
Furthermore, if you try it in 1.3, signed or unsigned, it also works. So this is almost certainly a 1.4 bug.
Anyone disagree? Better yet, anyone have a workaround? I've tried everything I could think of, including launching a thread from the init() method that sets up the components, and then just waits for the data to be set by Javascript. But it seems that ANY communication between the method called by Javascript and the code originating in init() corrupts something and we don't get keyboard events. This bug is killing my users who are very reliant on their shortcut keys for productivity, and we have a somewhat unique user interface that relies on Javascript for initialization. Any help or suggestions are appreciated.
================================================================
Java Applet (Put it in a signed JAR called mainapplet.jar)
================================================================
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class MainApplet extends JApplet implements KeyEventDispatcher
    JPanel test;
    public void init()
        System.out.println("init called");
        setUp("init");
    public void callMeFromJavascript()
        System.out.println("callMeFromJavascript called");
        setUp("javascript");
    private void setUp(String label)
        getContentPane().removeAll();
        test = new JPanel();
        getContentPane().add( test );
        JButton button = new JButton(label);
        test.add( button );
        test.updateUI();
        DefaultKeyboardFocusManager.getCurrentKeyboardFocusManager().addKeyEventDispatcher(this);
    public boolean dispatchKeyEvent(KeyEvent e)
        System.out.println("== KEY PRESSED!!! ==");
        return false;
}================================================================
HTML
================================================================
<form>
<APPLET code="MainApplet" archive="mainapplet.jar" align="baseline" id="blah"
     width="200" height="400">
     No Java 2 SDK, Standard Edition v 1.4.1 support for APPLET!!
</APPLET>
<p>
<input type="button" onClick="document.blah.callMeFromJavascript();" value="Init Applet via Javascript">
</form>

I tried adding the requestFocus() line you suggested... Same behavior.
A good thought, but as I mention in my description, the applet has no trouble gaining the focus initially (when init() is called). From what I have seen, it is only when the call stack has been touched by Javascript that I see problems. This is strange though: Your post gave me the idea of popping the whole panel into a JFrame... I tried it, and the keyboard/focus problem went away! It seems to happen only when the component hierarchy is descended from the JApplet's content pane. So that adds yet another variable: JRE 1.4 + Signed + Javascript + components descended from JApplet content pane.
And yes, signed or unsigned DOES seem to make a difference. Don't ask me to explain why, but I have run this little applet through quite a few single variable tests (change one variable and see what happens). The same JAR that can't receive keyboard events when signed, works just fine unsigned. Trust me, I'm just as baffled as you are.

Signed applet working in Netscape 6 but not in IE 5.5

I have an applet that reads a file from a server and tries to write it to a client machine. To this i self signed the jar file containing the applet using the keytool and jarsigner. So now I had a self signed applet. I tried to run this in IE. It gave the same error message that i used to get when I tried to run it the applet as unsigned. What am I missing here? Is self signing not enough to run the applet in IE? The same applet works in Netscape 6 and successfully downloads the file to the local machine. Please help me. I have added the certificate to the IE security panel as trusted.

Netscape 6 has Java VM 1.3. if you use MSIE, you should try JavaPlugin.
If interested in an appli that helps in signing process, you may download XLRSecTool for
free at:
. Windows:
http://www.xlreader.com/download/stl10ea/InstData/Windows/NoVM/istl10ea.exe
. Unix and Linux:
http://www.xlreader.com/download/stl10ea/InstData/Unix/Others/istl10ea.bin
. Other Java-enabled OS
http://www.xlreader.com/download/stl10ea/InstData/Java/install.zip
Requires Java VM 1.3.1
Screenshot:
http://www.xlreader.com/images/sshot_s673x548.gif
-- Robert
=====
[email protected]
XL-Reader Project - Secured online documentation solutions
www.xlreader.com
=====

Signed applets in 1.4.1: non-trust ignored: severe security problem?

Similar Messages

Maybe you are looking for