Submitted On 21-MAR-2001
jonbnews
Yes, hundreds of deployed applets are broken because of the
way the new plugin verifies signatures. This is
unacceptable. As well, the process for deploying a signed
applet is now much more complex for the end user because
they must manually import the certificate into the local
keystore. How is the end user supposed to accomplish
that? This is a terrible step backwards from 1.3.0-C.
Submitted On 26-MAR-2001
jplerxt
I must agree that the current situation, and it's solution
are unacceptable. End users should not be expected to
perform direct security file manipulations. Furthermore,
for our corporate intranet apps, we should not be expected
to pay some other signing authority for the ability to run
our own apps. I have just spent several days trying to
track this problem down, and am aghast that there is no
apparent documentation on the subject.
Submitted On 12-APR-2001
liscjd
Already we are getting support calls asking why our applets
are crashing with security exceptions. What did you expect
anyone using certificates to do when you implemented this
non backwards compatible so called feature? Anyone who
installs netscape 6 gets the 1.3.0_01 JVM by default now we
have to tell them to uninstall and go back to their OLD
browser.
Submitted On 20-APR-2001
liscjd
so where can I find out how this new way works and can I
make my own certificates?
Submitted On 20-APR-2001
fkeichfe
In my opinion, this situation is a great drawback for
professional software development.
The question is: If my applets are conform to 1.3.1, what
changes will be introduced in JDK 1.4?
The back-compatibility was always a great advantage of Java.
Why weren't the users and developers warned or informed
that there is a major change in signature verification?
Why wasn't a solution found analog to the "deprecated" flag
in the API, so that the developer were informed that the
current behaviour might change in a current version?
Many questions, but unfortunately too few answers.
Submitted On 25-APR-2001
jgoins
I DON'T CARE ABOUT NETSCAPE COMPATIBILITY!
My user's use IE and I need to use IE's certificates. This
is stupid. This is done without any warning, and you
expect everyone to just accept it?
Your as bad as Microsoft!
Submitted On 15-MAY-2001
falklanghammer
We have just run into the very same problem. I just cannot
believe it.
YOU GUYS BREAK EXISTING CODE IN A MINOR-DOT VERSION WITHOUT
ANY ADVANCE NOTICE AND WITHOUT ANY LEGITIMATE REASON!!!!
Why should a plug-in which is an IE ActiveX control care
about NS? This is wrong argueing to the point where I start
to believe that you made a deal with Verisign to sell
signatures.
And then you close bugs so noone can vote...
AT this point our company must start considering using
ActiveX (aka .NET) technology.
Just shaking head.
Submitted On 17-MAY-2001
Jason B
Hi all,
I feel this is a bit troublesome as the problem happens with certificates which are in the cacerts store
already, I have a Thawte cert which behaves in the same manner, so clearly there is something amiss here.
What type of workaround is there for users of trusted certificates (whose applets should be verified by the
default, as the correct roots are in the cacerts store)?
If anyone reads this and has experienced similar problems with Trusted certs, I would love to hear from you.
jasonb@thawte.com
Thanks
Submitted On 17-MAY-2001
amenkes
This should not be closed when it affects so many people
without a decent solution.
Submitted On 17-MAY-2001
Jason B
Hi Again,
This really needs to be resolved...
Submitted On 21-MAY-2001
MichaelSchlueter
A new report(4447912) has been opened on this issue. Let's
vote, before it is closed again.
Submitted On 19-JUN-2001
migG
It is actually documented in Release notes:
http://java.sun.com/j2se/1.3/relnotes.html#plugin
I noticed this myself quite early, as I deploy an custom enterprise-CA issued
cert, and had to import the root CA cert into cacerts file, as described at:
http://home.iSTAR.ca/~neutron/ImportCA/ and link:
http://home.iSTAR.ca/~neutron/ImportCA/jre1.3/index.html
It is more awkward then importing root CA certs to either IE or Netscape
root CA databases, but can be done (awkwardly).
Also, with J2SE v1.4 beta, the Plugin documentation STILL seems to be
incorrect wrt resolution of the root CA certificate (indicates that the *browsers*
own sec-manager and associated root CA store is queried):
http://www.javasoft.com/j2se/1.4/docs/guide/plugin/developer_guide/rsa_how.html#trust
- Mitch Gallant
http://home.istar.ca/~neutron/java.html
Submitted On 09-JUL-2001
wichelman
Yet another unhappy customer. Waiting for a reasonable
resolution ...
Submitted On 30-JUL-2001
BratR
Help me solve this problem as I dont know what to do.
Is this the help we get from the new Super Giants???
Thank
Submitted On 12-SEP-2001
evantoliopoulos
When will you add a GUI certificate administration tool to
your plug-in that allows uses to import certificates?
Telling a user to use keytool is unacceptable!
Submitted On 12-SEP-2001
evantoliopoulos
When will you add a GUI certificate administration tool to
your plug-in that allows uses to import certificates?
Telling a user to use keytool is unacceptable!
Submitted On 19-SEP-2001
kram_esh
This bug has to be re-opened and fixed immdly. We cannot
educate all end users on how to add the certificate to the
cacerts file using keytool.
Submitted On 19-APR-2002
mhall119
OK, I understand the reasons for wanting to make Java's
security independant of the browsers, but you have to allow
the Plug-In to install new certificates instead of using
the command line. Would it really be that difficult to
have the Plug-In ask the user if they want to install the
new certificate? I think you guys should work really hard
to have this feature in the very next version of the plug-
in, otherwise Java isn't going to be an options for many
developers, and you'll lose to Microsoft's products.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
