Date: Thu, 22 Jul 1999 13:06:54 -0700
From: Jerome Dochez <jerome.dochez@eng.sun.com>
To: Jan Luehe <luehe@laguna.eng.sun.com>
Subject: Re: "Java Plug-In Security Warning" dialog gone / broken under 1.2.2 px
Jan
Thanks for the answer. This unfortunetely confirm what I was suggesting
in my first email, if the root CA are not strictly equal, the security
check will not work. This is extremly sad because that forces people to
use specific root CA to sign their applet. Furthermore, all deployment
browsers would need to have to same root CA in their codestore (IE 3,4,5
right now).
Do you think we could get a better solution with some other crypto API
(like the one I was suggesting called CertCompareCertificateName) ? I
don't feel that each time IE comes out with a new root CA, people would
need to resign their applet with the new CA and deploy the root CA to
all platforms and browsers.=20
Also, since the CAPI bug involved only NT, why not using the "old" API
for 98 and hope it would be fixed for 2000 ?=20
Jerome
Jan Luehe wrote:
>=20
> Hi Chris:
>=20
> I was able to reproduce your problem. Here's an explanation that might
> help you understand what has changed between JRE 1.2.2 RC and JRE
> 1.2.2 FCS.
>=20
> In the 1.2.2 RC release, the Plug-in verified an applet's certificate
> chain as follows:
>=20
> Starting with the (leaf) certificate at the bottom of the chain, we
> verified the signature of each certificate using the public key of the
> certificate at the next level higher up in the chain, until we reached
> the self-signed Root CA certificate at the top of the chain.
>=20
> Then we checked if the signature of that Root CA certificate could be
> verified using the public key of a certificate contained in the
> browser's CA store. We used the CertGetIssuerCertificateFromStore()
> CAPI function to do that. Here's a description of what that function
> does:
>=20
> The CertGetIssuerCertificateFromStore function retrieves the
> certificate context from the certificate store for the first or next
> issuer of the specified subject certificate (see
> http://msdn.microsoft.com/library/sdkdoc/crypto/1ref_functions_0oo5.htm
> for more info).
>=20
> We passed these to flags to that function:
>=20
> CERT_STORE_SIGNATURE_FLAG: Uses the public key in the issuer's
> certificate to verify the signature on the subject certificate.
>=20
> CERT_STORE_TIME_VALIDITY_FLAG: Gets the current time and verifies tha=
t
> it is within the subject certificate's validity period.
>=20
> However, this function does not seem to work properly in the case of
> self-signed certificates: The function would indicate success even if
> there was no appropriate certificate in the CA store.
>=20
> Someone exploited this (CAPI) bug by creating a self-signed certificate
> and choosing any name they wanted for the certificate subject/issuer
> (in the case I am referring to, they chose "Sun Microsystems
> CA"). Then they used that certificate to sign an applet and loaded the
> applet using the Plug-in. Contrary to expectation, the Plug-in popped
> up the security dialog, informing the user that the applet's signer
> had been authenticated as "Sun Microsystems CA", and asking the user
> if they wanted to grant all permissions to the applet. This was a
> very serious security hole.
>=20
> The problem appeared only on Windows NT, but not on Windows 98.
>=20
> Since we could not rely on the above CAPI API, we took a more conservat=
ive
> approach to fix the problem: We now enumerate through all the
> certificates in the CA store to see if there is one whose encoding
> matches that of the Root CA certificate of the applet certificate chain.
>=20
> I noticed that in your case, the Root CA certificate (belonging to
> "OU=3DClass 3 Public Primary Certification Authority, O=3D"VeriSign,
> Inc.", C=3DUS") in the applet certificate chain is different from that
> owner's certificate in the CA store (for example, the validity
> timeframes are different), even though their public keys are the
> same. That means that their encodings are different.
> Therefore, you don't get the pop-up window. (I noticed your
> version of the VeriSign Class 3 certificate expires on Fri Dec 31
> 15:59:59 PST 1999, whereas the one in IE's CA store is valid until
> 2004.)
>=20
> Here is what you could do to get your applet to work with JRE 1.2.2 FCS=
:
> Replace the VeriSign Class 3 certificate in Netscape with the one from
> IE's CA store. Then re-import your object signing certificate (issued
> by VeriSign). This should establish a certificate chain with the new
> VeriSign certificate at the top.
>=20
> Please let us know if that works for you.
>=20
> Jan
>=20
> > X-Sender: cforster@postoffice.i-review.com
> > Mime-Version: 1.0
> > Date: Wed, 21 Jul 1999 16:13:43 -0500
> > To: java-security@java.sun.com
> > From: "Christian M. Forster" <cforster@i-review.com>
> > Subject: "Java Plug-In Security Warning" dialog gone / broken under 1=
.2.2 px
> (FCS)?
> > X-Attachments: D:\VCDBE30\Projects\Signtest\JApplet1.java;
> D:\VCDBE30\Projects\Signtest\JApplet1.htm;
> >
> > I've just subscribed to this list, so could any replies also CC me di=
rectly.
> > Thanks! I've also searched the list archive for info.
> >
> > I submitted this to JDC -> Bugs (review ID: 88143, 3-week backlog?!),=
but I
> > need to deliver a commercial beta applet/JAR that relies on 1.2.2 & t=
he Java
> > Plug-In Security Warning dialog by the end of this August & this is a
> > show-stopper! I've also EMailed one member of the Plug-In Team direc=
tly,
> > but I'm deperate for a confirmation or response! I know Jan L. sees =
this
> > list and has been very responsive.
> >
> > The problem: My Class 3 Verisign Netscape Object Signing cert - sign=
ed JARs
> > work fine under the 1.2.2 RC1 plugin (Plug-In jre 1.2.2 pu) showing t=
he
> > security dialog and allowing the user to grant rights, but fail to sh=
ow the
> > dialog at all on clean machines with 1.2.2 production plugin (Plug-In=
jre
> > 1.2.2 px).
> >
> > The steps I took:
> > 1) Compile 1.2 code to a classes directory,
> > 2) Use Netscape's signtool (w/Verisign class 3 cert) to JAR (ZIP) the=
class
> > files & sign the resultant JAR like this:
> > signtool -da: -k "Our Co. Name" -Z Jarname.jar classdir
> > 3) In a separate test, tried signing the directory & using pkzip to p=
ackage
> > the JAR. Same problem.
> >
> > The JAR is signed by my company's new Class 3 Verisign cert, no secur=
ity
> > dialog is presented under 1.2.2 FCS and if I press the "Show Dialog" =
button
> > in the presented JInternalFrame (see sample code attached), an option=
dialog
> > shows with the yellow banner at the bottom (untrusted).
> >
> > If I try the same JAR on Win95 machines with JRE 1.2.2 RC1 (pu), they
> > properly show the security dialog... machines with JRE 1.2.2 FCS (px)=
do
> > not.... . The JAR was compiled with jdk 1.2.2FCS and JARed/signed wi=
th
> > Netscape's signtool. If I install 1.2.2 RC1 (plug-in ver. 1.2.2 pu) =
over
> > 1.2.2 FCS (plug-in ver. 1.2.2 px) on the machines, the Security Dialo=
g shows
> > and all is well, but obviously I cannot ship under a RC release.
> >
> > Perhaps the required signing procedure has changed from 1.2.2 RC -> 1=
.2.2
> > FCS or I'm overlooking something, but I've read & tried everything I =
can
> > think of and can't get the dialog to show under 1.2.2 FCS. I checked=
the
> > cacerts (identical under RC1 & FCS) and my browsers certs DB (IE 4, N=
N 4).
> > All the relevant Versign CA certs are enabled.
> >
> > Again, any suggestions would be appreciated. I can send along the sig=
ned JAR
> > file to anyone that wants to try it.
> >
> > Has anyone seen the "Java Plug-In Security Warning" dialog presented =
by the
> > 1.2.2 FCS plugin? I'd appreciate hearing the creation & environment =
details.
> >
> > I've read & followed
> > http://java.sun.com/products/plugin/1.2/docs/nsobjsigning.html and
> > http://java.sun.com/products/plugin/1.2/docs/netscape.html and I'm wo=
rried
> > that the addition of the new "usePolicy" runtime permission may have =
broken
> > the facility.
> >
> > Thanks,
> > Chris
> >
> >
--=20
___
/ \\\
|o o|
/------------------------ooO---------Ooo-----------------------/
/ Audantes fortuna juvat /
/ /
/ J=E9r=F4me Dochez Java VM Team /
/ Staff Engineer Java Plug-in Lead Eng /
/ JavaSoft / Sun Microsystems jerome.dochez@eng.sun.com /
/ /
/ Ceux qui ignorent le pass=E9 sont condamn=E9s =E1 le reproduire /
/ Those who are ignorant of history are doomed to repeat it /
/--------------------------------------------------------------/