Community
Participate
Working Groups
Created attachment 164792 [details] screen capture of accept dialog and its "details" page. Apologies if this is merely a naive user question, but lately, when testing various install scenarios, I get a dialog popped up that says "do you trust this certificate?" I'll attach a screen cap to show some details. It all looks pretty normal to me. I thought part of the "security" of using a certificate, was that users didn't have to make a judgment on if it was trust worthy ... that the software could just tell (looking up the root certificate trail, or what ever its called). So, does this mean somethings wrong? Could this be something weird with my system? It doesn't seem to always happen, and I haven't been paying enough attention to detect a pattern. Should I start paying attention? Or is this normal?
(In reply to comment #0) > It doesn't seem to always happen, and I haven't been paying enough attention to > detect a pattern. Should I start paying attention? Or is this normal? This definitely is not normal. The root authority of the Eclipse certificate is VeriSign which should be included in the CA certs for your installed VM by default. What VM and OS are you using when you see this?
I agree with Tom, you should never see this. Sounds like your cacerts file has been wiped out or something.
Ok, knowing this isn't normal, I systematically tried to reproduce, and see it occurs when I use my Sun VM (not when I use my IBM VM). It is Sun's VM as reported below but I would not be the least surprised its something odd about my particular install, not necessarily Sun's VM, per se. D:\>java -version java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode) So, I'll close as "not eclipse" but if anyone is interested in trying, I could reproduce this by unzipping Galileo SR2 version of Java EE IDE EPP package from main download site, and then try to install the "patches" features from http://download.eclipse.org/webtools/tempTestUpdates31/ I would not be surprised its something odd about my particular install because I do monkey with my VM installs occasionally (such as just delete them, instead of "uninstall" them) ... and noticed a while back some other odd things (such as Windows 7 add/remove software dialog shows some as installed, but won't let me uninstall them). Also, I'm not even sure where I got this Sun VM to install. It might have been from my company's internal site for Java VMs ... but don't recall. Thanks for confirming at least the message isn't normal. Glad to here its not a p2 bug. :) Oh, and if interested, if I click "cancel" on the confirm license dialog, I get following message about why the features could not be installed (which is why I mentioned p2): An error occurred during the org.eclipse.equinox.internal.provisional.p2.engine.phases.CheckTrust phase. session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.CheckTrust, operand=, action=). One or more certificates rejected. Cannot proceed with installation.
I have been getting this same error when running Eclipse with Java 1.6.0_20 on Ubuntu/lucid using the standard sun-java6-jdk package. If with the standard Java 5 package which is Java version 1.5.0_20 I do not get the certificate errors. For the record: This also caused product builds to fail for me: runDirector: [p2.director] Installing org.eclipse.equinox.p2.examples.rcp.cloud.product 1.0.0.201004242034. [p2.director] Installation failed. [p2.director] One or more certificates rejected. Cannot proceed with installation. [p2.director] One or more certificates rejected. Cannot proceed with installation. A problem occured while invoking the director. BUILD FAILED
I'm getting this error on windows xp and linux x86 and x86_64 both with the latest sun JVMs. Does anyone have a suggested workaround?
I just verified that this dialog is not displayed with sun jre 1.5.0_22 for windows, but is displayed for sun jre 1.6.0_20 for windows.
I've gotten to the root of the problem. Sun replaced one of the root verisign certs for one with a stronger algorithm in 1.6.0_19. Is it possible for you guys to request a new cert from verisign that exists in both 1.6.0_18 and 1.6.0_19? I'll attach the list of certs from jre1.5.0_22 and jre1.6.0_20 for comparison. It looks like class3g3 and class3g2 are unchanged between the releases. http://forums.sun.com/thread.jspa?threadID=5435040 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6904162
Created attachment 166673 [details] Verisign certs from sun jre1.5.0_22
Created attachment 166674 [details] Verisign certs from sun jre1.6.0_20
(In reply to comment #7) > Is it possible for you > guys to request a new cert from verisign that exists in both 1.6.0_18 and > 1.6.0_19? > Off hand, this doesn't sound like the right approach. Wouldn't it still be a problem with "old" builds that have already been signed and released? Such as Galileo SR2? Or am I misunderstanding? (I know little about this, so feel free to clarify). If it would still be a problem with old builds, then it still sounds like Sun's/Oracle's problem?
(In reply to comment #10) > (In reply to comment #7) > > Is it possible for you > > guys to request a new cert from verisign that exists in both 1.6.0_18 and > > 1.6.0_19? > > > > Off hand, this doesn't sound like the right approach. Wouldn't it still be a > problem with "old" builds that have already been signed and released? Such as > Galileo SR2? Or am I misunderstanding? (I know little about this, so feel free > to clarify). If it would still be a problem with old builds, then it still > sounds like Sun's/Oracle's problem? I agree, I find it strange that they changed a few of the aliases completely to use SHA1withRSA instead of MD*withRSA. The certificate used by eclipse mapped to the cacerts alias "verisignclass3ca" in the 1.5 VMs and pre 1.6_19 VMs. On these VMs that alias mapped to a trusted certificate that used the MD2withRSA signature algorithm. This certificate no longer can map to that alias (or any other alias in cacerts) on 1.6_19 or later. If we move to a new certificate we need to be very cautious to make sure that new certificate exists in every cacerts of all the VMs we support. Not just the 1.6 VM variants. Otherwise we will start seeing these errors on older VMs as well.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #7) > > > Is it possible for you > > > guys to request a new cert from verisign that exists in both 1.6.0_18 and > > > 1.6.0_19? > > > > > > > Off hand, this doesn't sound like the right approach. Wouldn't it still be a > > problem with "old" builds that have already been signed and released? Such as > > Galileo SR2? Or am I misunderstanding? (I know little about this, so feel free > > to clarify). If it would still be a problem with old builds, then it still > > sounds like Sun's/Oracle's problem? > > I agree, I find it strange that they changed a few of the aliases completely to > use SHA1withRSA instead of MD*withRSA. The certificate used by eclipse mapped > to the cacerts alias "verisignclass3ca" in the 1.5 VMs and pre 1.6_19 VMs. On > these VMs that alias mapped to a trusted certificate that used the MD2withRSA > signature algorithm. This certificate no longer can map to that alias (or any > other alias in cacerts) on 1.6_19 or later. > > If we move to a new certificate we need to be very cautious to make sure that > new certificate exists in every cacerts of all the VMs we support. Not just > the 1.6 VM variants. Otherwise we will start seeing these errors on older VMs > as well. Yes, it should be present in as many JVMs as possible. I should have phrased my request better. Still, the jars should be trusted in the latest JVMs. While this bug is Sun/Oracle's _fault_, it is eclipse's problem. It will only get worse as more people upgrade their JREs.
Another option is to build a keystore directly into the framework that contains the alias for the trusted eclipse certificate and have a trust engine that looks at the built-in trusted keystore in the framework as well as the built-in VM cacerts. But this will only help work around the issue for bundles installed into the framework itself. We will still have issues with the launcher and equinox framework jars themselves because the are loaded by the VM class loaders which will not know about the built-in framework trusted keystore. It also does not help in scenarios where the framework is not always used (e.g. jetty). It also sounds quite insecure to package the keystore that is supposed to prove certificate trust inside a jar that is signed with the certificate that we need to prove is trusted.
Assuming an acceptable root cert can be found that exists in an acceptable number of JREs, is there any other reason why the cert couldn't be changed?
> > Yes, it should be present in as many JVMs as possible. I should have phrased > my request better. Still, the jars should be trusted in the latest JVMs. > While this bug is Sun/Oracle's _fault_, it is eclipse's problem. It will only > get worse as more people upgrade their JREs. Wouldn't the first course of action be to open a bug with Sun/Oracle that their cert upgrade is not "compatible" with their previous ones? That they removed too much? I couldn't really follow what was said in the referenced bugs/forum reports ... but that's my intuition. Maybe they could fix it in their next maintenance release? Thanks, btw, for digging into this.
(In reply to comment #14) > Assuming an acceptable root cert can be found that exists in an acceptable > number of JREs, is there any other reason why the cert couldn't be changed? Not really, other than it means we need every jar in all of Helios to be resigned to get them up to the latest one. This will take coordination. We cannot do anything about older releases like the Galileo release, it is done and over. Also, not everything at eclipse is on the Helios release train (sorry David I cannot remember your preferred terminalogy :). Any existing repositories that contain features that have not been resigned will get trust warnings when then are installed. Denis, has verisign given you any advanced warning that the certificate the foundation purchased was going to be removed as a trusted certificate? Seems like they should be giving us a free replacement for this.
(In reply to comment #15) > > > > Yes, it should be present in as many JVMs as possible. I should have phrased > > my request better. Still, the jars should be trusted in the latest JVMs. > > While this bug is Sun/Oracle's _fault_, it is eclipse's problem. It will only > > get worse as more people upgrade their JREs. > > Wouldn't the first course of action be to open a bug with Sun/Oracle that their > cert upgrade is not "compatible" with their previous ones? That they removed > too much? I couldn't really follow what was said in the referenced bugs/forum > reports ... but that's my intuition. Maybe they could fix it in their next > maintenance release? > > Thanks, btw, for digging into this. I found some links on the following thread in the sun forums: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6904162 This issue is related to a fundamental flaw in certs that use MD2. MD2 is not secure. See the following for more info: http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=218900008 http://www.semiaccurate.com/2009/08/02/dan-kaminsky-feels-disturbance-internet/ http://www.theregister.co.uk/2009/07/30/universal_ssl_certificate/ Based on these articles, it is very reasonable of Sun/Oracle to have removed these certs from use. (In reply to comment #16) > We > cannot do anything about older releases like the Galileo release, it is done > and over. If we found a cert that existed on enough JVMs (including past ones), couldn't we potentially re-sign the Galileo release jars, too? When the root cert expires, you'll have to do this as well, or else users will get similar warnings. I don't know how long you commit to making releases available, but as long as they are signed/supported, they should use a reputable root cert. Thank you guys, too, for being receptive to discuss this further despite it being closed.
(In reply to comment #17) > If we found a cert that existed on enough JVMs (including past ones), couldn't > we potentially re-sign the Galileo release jars, too? When the root cert > expires, you'll have to do this as well, or else users will get similar > warnings. Changing the certificate will change the content of the jars, so the bundle version numbers would all need to change as well for our mirroring and install technology to work properly. This just isn't going to happen at this point after the release. As for certificate expiry, what counts is whether the certificate was valid at the time the jar was signed, not the time the certificate is checked.
In any case, based on this information I am reopening this bug to consider updating the Eclipse Foundation certificate.
(In reply to comment #18) > (In reply to comment #17) > > If we found a cert that existed on enough JVMs (including past ones), couldn't > > we potentially re-sign the Galileo release jars, too? When the root cert > > expires, you'll have to do this as well, or else users will get similar > > warnings. > > Changing the certificate will change the content of the jars, so the bundle > version numbers would all need to change as well for our mirroring and install > technology to work properly. This just isn't going to happen at this point > after the release. As for certificate expiry, what counts is whether the > certificate was valid at the time the jar was signed, not the time the > certificate is checked. That makes sense. (In reply to comment #19) > In any case, based on this information I am reopening this bug to consider > updating the Eclipse Foundation certificate. Thanks!
Didn't we just renew the cert for 3 years?
(In reply to comment #21) > Didn't we just renew the cert for 3 years? Yes, about a year ago (bug 252879). The issue is that since then, a flaw was discovered that apparently makes the root certificate unsecure. The most recent Sun JVM release therefore removed that root certificate from the list of "trusted" certificates. The result is that a user running the latest Sun JVM gets a warning dialog saying the Eclipse Foundation certificate is not trusted (comment #0). However from digging around, I see Verisign claims their existing certificates are not vulnerable to this attack [1], and that existing customers do not need to replace their certificates. Based on this it appears Sun was incorrect to remove that certificate from their trusted cert list, although the damage is done at this point. [1] https://press.verisign.com/easyir/customrel.do?easyirid=AFC0FF0DB5C560D3&version=live&prid=523818&releasejsp=custom_97
The new VeriSign certificate (alias verisignclass3ca in cacerts) has the same public key as the old md2 signed certificate. The signature on the jars is valid and I have verified with the jarsigner tool from both jdk16015 and jdk16020. There should be no need to update the existing signatures. C:\eclipse\e36m6\eclipse\plugins>java -version java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing) C:\eclipse\e36m6\eclipse\plugins>jarsigner -verify org.eclipse.equinox.p2.direct or_2.0.0.v20100311-1335.jar jar verified. The problem is in the verification logic in the CheckTrust module. It is not considering an alternate path to a good trust root. Currently the signature path looks like this (DIRECTOR -> Verisign CodeSigning Intermediate -> MD2 trustroot). The jar can also be verified by using (DIRECTOR -> Verisign CodeSigning Intermediate -> SHA1 trustroot). The logic in the KeyStoreTrustEngine class could be modified to ignore root CAs in signature chains or to do a search in the truststore if the root CA is not found.
(In reply to comment #23) > The new VeriSign certificate (alias verisignclass3ca in cacerts) has the same > public key as the old md2 signed certificate. The signature on the jars is > valid and I have verified with the jarsigner tool from both jdk16015 and > jdk16020. There should be no need to update the existing signatures. > > C:\eclipse\e36m6\eclipse\plugins>java -version > java version "1.6.0_20" > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing) > > C:\eclipse\e36m6\eclipse\plugins>jarsigner -verify > org.eclipse.equinox.p2.direct > or_2.0.0.v20100311-1335.jar > jar verified. > All that did was verify that the content has not changed or been corrupted according to the signature on the jar. It did not establish any trust for the certificates. You have to run something like this to get the full information on the signed entries ... jarsigner -keystore <URL to cacerts> -verbose -verify <path to jar> You will get entries like this for an eclipse bundle: smk 347 Fri Apr 23 10:35:54 CDT 2010 org/osgi/util/tracker/ServiceTrackerCustomizer.class Where the flags in the left most column mean this s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore i = at least one certificate was found in identity scope Notice the 'k' char. If you use the cacerts included with java6_20 then you will notice the 'k' char is missing. So none of the certs in the chain is found in the cacerts keystore. This means the signer is not trusted according the built-in cacerts. > The problem is in the verification logic in the CheckTrust module. It is not > considering an alternate path to a good trust root. Currently the signature > path looks like this (DIRECTOR -> Verisign CodeSigning Intermediate -> MD2 > trustroot). The jar can also be verified by using (DIRECTOR -> Verisign > CodeSigning Intermediate -> SHA1 trustroot). > > The logic in the KeyStoreTrustEngine class could be modified to ignore root CAs > in signature chains or to do a search in the truststore if the root CA is not > found. We already do this, but the problem is none of the certs in the chain are contained in cacerts. We would have to have a separate keystore that we trust to contain the root certificate (or one of the others in the chain) to verify the trust.
Sorry to update the title again, but previous title described a possible fix rather than the problem.
I'm raising the priority on this to major since we now have several complaints regarding this on our mailing list. It seems urgent that it is fixed.
(In reply to comment #24) > (In reply to comment #23) > > The new VeriSign certificate (alias verisignclass3ca in cacerts) has the same > > public key as the old md2 signed certificate. The signature on the jars is > > valid and I have verified with the jarsigner tool from both jdk16015 and > > jdk16020. There should be no need to update the existing signatures. > > > > C:\eclipse\e36m6\eclipse\plugins>java -version > > java version "1.6.0_20" > > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > > Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing) > > > > C:\eclipse\e36m6\eclipse\plugins>jarsigner -verify > > org.eclipse.equinox.p2.direct > > or_2.0.0.v20100311-1335.jar > > jar verified. > > > > All that did was verify that the content has not changed or been corrupted > according to the signature on the jar. It did not establish any trust for the > certificates. You have to run something like this to get the full information > on the signed entries ... > > jarsigner -keystore <URL to cacerts> -verbose -verify <path to jar> > > You will get entries like this for an eclipse bundle: > > smk 347 Fri Apr 23 10:35:54 CDT 2010 > org/osgi/util/tracker/ServiceTrackerCustomizer.class > > Where the flags in the left most column mean this > s = signature was verified > m = entry is listed in manifest > k = at least one certificate was found in keystore > i = at least one certificate was found in identity scope > > Notice the 'k' char. If you use the cacerts included with java6_20 then you > will notice the 'k' char is missing. So none of the certs in the chain is > found in the cacerts keystore. This means the signer is not trusted according > the built-in cacerts. > > > > The problem is in the verification logic in the CheckTrust module. It is not > > considering an alternate path to a good trust root. Currently the signature > > path looks like this (DIRECTOR -> Verisign CodeSigning Intermediate -> MD2 > > trustroot). The jar can also be verified by using (DIRECTOR -> Verisign > > CodeSigning Intermediate -> SHA1 trustroot). > > > > The logic in the KeyStoreTrustEngine class could be modified to ignore root CAs > > in signature chains or to do a search in the truststore if the root CA is not > > found. > > We already do this, but the problem is none of the certs in the chain are > contained in cacerts. We would have to have a separate keystore that we trust > to contain the root certificate (or one of the others in the chain) to verify > the trust. Thanks for note on jarsigner, I will try that again. If you take the first two certificates in the chain (eclipse codesigning & VeriSign intermediate), you can build a valid chain to the new VeriSign root CA. The root certificate in the signature is not needed to verify the signature since the root CA must be contained in the truststore. I don't think a separate truststore is needed, just different path building logic.
Created attachment 168123 [details] Ignore root CA in signed jar, find in cacerts Attached a proposed modification to the KeyStoreTrustEngine that ignores trustroots in the signature, it will search the cacerts file instead. This was from 3.6M6 source. Old: if (cert.getSubjectDN().equals(cert.getIssuerDN())) { certChain[i].verify(certChain[i].getPublicKey()); rootCert = certChain[i]; // this is a self-signed certificate } else { New: // Back off the root CA, we will find it in truststore if (certChain.length > 1) { cert = (X509Certificate) certChain[i-1]; }
I will take ownership of this one to see if the suggestion from Tim will work. Thanks Tim! The idea may work but I think we need to be careful not to change the behavior drastically in the fix.
Created attachment 168157 [details] patch Here is an updated patch. I moved the code to check the store for the CA root out to a new method. I also kept the logic intact for when the last cert in the chain is not a self-signed certificate although I did return fast in this case instead of allowing it to fall through to check the store again for an alias. Finally I only check for the alternative root in the store if our first attempts with the original root from the chain is not found in the store. I need to test this out on my Windows installation since my mac does not have the latest cacerts available yet.
I verified that the fix does indeed work with the latest cacerts. I still have some concerns that I need to iron out. The call to: cert.verify(nextCert.getPublicKey()); Where cert is the second to last cert in our chain and nextCert is one of the trusted certificates in the cacerts file (keystore). I assume this call will fail if the cert was not signed using the private key from nextCert. If not then it would be very easy to mock up a chain that ended with an untrusted certificate which somehow used the same public key as the real trusted certificate. That should only be possible if the mocked up certificate had access to the private key of the trusted certificate in the cacerts keystore. Otherwise the call to cert.verify must fail.
Attempting to get this reviewed for RC1
Patch released. I discussed this approach with my security contacts at IBM. This approach is correct. As long as we check that the issuer of the intermediate cert is equal to the subject of the trusted cert in the keystore AND that trusted cert's public key can be used to verify the intermediate certificate then we are correct to establish trust of the certificate chain. Thanks all for the effort to get a solution to this issue.
Comment on attachment 168123 [details] Ignore root CA in signed jar, find in cacerts Marking for IP log. I did not use this directly but I did borrow the idea as a basis for the final solution. Thanks Tim.
