Machines installed with Java Plug_in 1.3.0_0x (includes _01, _02, 1.3.1) or later will not able to launch the applet version of iIM client and  get the error message:  "Unable to verify Root CA"

Use a different cert recognized by plug-in.

  xxxxx@xxxxx   2001-04-26

The main change in 1.3.0_0x is that JPI now uses the root CA cert store in JRE instead of the browser. 

The issue is that GTE CA cert which comes with the browser but not in the jre/lib/security/cacerts file that comes with the JRE, which is used by the plug-in 1.3.0_0x. To workaround the issue, use a CA cert that is in cacert file. 

  xxxxx@xxxxx   2001-04-26

The workaround does not work. 

Paul <Yungching.Young@eng.sun.com> wrote:
--
The evaluation of your bug report has been completed.

The problem you encountered has been noticed by our 
engineers,
and they are currently working on it.  For more information 
about 
this issue, you can visit the website at

http://developer.java.sun.com/developer/bugParade/bugs/44479
12.html

If you have further information might help investigate this 
problem,
please feel free to use our bug submitting page at
http://java.sun.com/cgi-bin/bugreport.cgi

Thank you for taking the time to report this problem.

Regards,
Paul
----------------- Original Bug Report-------------------

category : java_plugin
subcategory : ocx
release : 1.3
type : bug
synopsis : bugs 4407689  4398868 4424604 closed by mistake
description : java version "1.3.0_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.3.0_02)
Java HotSpot(TM) Client VM (build 1.3.0_02, mixed mode)

  Bugs 4407689, 4398868, and 4424604 have been closed by 
mistake.

The current minor release 1.3.0_02 breaks the majority of 
signed applets out
there (all applets in IE with self-signed signatures), and 
the solution
proposed for 1.3.1 will not fix this situation (because 
users will see too many
security warnings).

This will have such a tremenduous impact on the image of 
Sun as a provider for
enterprise-ready software that the bug needs be re-opened.

It has to stay open until it is clear that all before-
mentioned applets
continue working without causing hot-line support traffic 
(because of security
dialogs popping up) when JRE 1.3.1 got installed by some 
other web pages.
workaround : .
suggested_val : 
cust_name : Falk Langhammer
cust_email : falk@livis.de
jdcid : falklanghammer
keyword : webbug
company : Living Pages Research GmbH
hardware : x86
OSversion : windows_2000
bugtraqID : 0
dateCreated : 2001-05-15 08:20:05.4
dateEvaluated : 2001-05-16 16:11:57.239

When does Sun will include other Root-Certifactes than Thawte- and Verisign-Certificates in cacerts ?

Sun *needs* to have a strategy, and work with various commercial CAs to ensure that the cacerts file 
deployed with j2re includes all the really well known ones (not just the few REALLY REALLY well known 
ones); i.e. a stragegy somewhat like that used by Netscape or Microsoft in their CA certs database selection 
process.
 - Mitch @  http://home.istar.ca/~neutron/java.html

How much do Sun receive from Verisign for each new object 
certificate sold ?

Having to purchase a certificate from one of Sun's trusted 
CA's is an unacceptable solution.  I can't justify spending 
$400 on a globally accepted certificate for an applet that 
will run only on our company's intranet.  This is not a 
solution at all, this is just forcing people to spend more 
money than they should.  If you don't allow the Java Plug-
in to install new CA's through a web interface, Java is 
going to be replaced by a technology that does.

Is this really fixed (JDK 1.3.1_04) ?

this is about enough to turn me away from java

Bla bla $400 bla bla Intranet.

You should talk to your administrators and have a a decent set up of the jre.

Using policy on your intranet and your own keystore for authentication.

I was quite unhappy to see the default SUN jre installation 
let the user trust whatever it opens. An avarige user has 
problems to find the "no" button.