Eclipse Foundation Code-signing certificate chain not trusted
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Eclipse |
Unknown
|
Unknown
|
|||
eclipse (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Lucid |
Fix Released
|
Undecided
|
Unassigned | ||
Maverick |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: eclipse
apt-cache policy eclipse-jdt
eclipse-jdt:
Installed: 3.5.2-2ubuntu4.2
Candidate: 3.5.2-2ubuntu4.2
Version table:
*** 3.5.2-2ubuntu4.2 0
500 http://
100 /var/lib/
3.5.2-2ubuntu4 0
500 http://
When attempting to install updates via Eclipse's Help>Check for Updates the user is prompted to accept a code-signing certificate used by the Eclipse Foundation with a Verisign Class 3 Public Primary Certification Authority root that has an MD2withRSA signing algorithm.
In my case one of the updates causing the issue is the Eclipse CDT.
The certificate should already be trusted via the public root CA certificates in the package ca-certificates that are written into "/etc/ssl/
The problem is caused by the Eclipse Foundation's certificate chain in the JAR file's META_INF/
Although the package "ca-certificates" contains the Verisign root CA ("/usr/
If the user ticks the checkbox next to the certificate Eclipse tries and fails to install this certificate into the keystore with the error "keystore is read-only". Even changing the permissions on the keystore doesn't solve that.
However, the certificate ought to be accepted so adding it is not the correct solution.
The problem is that both Sun Java and OpenJDK both disabled trust in certificates signed using MD2withRSA in November 2009. It is this that is causing Eclipse to ask about trusting the Eclipse Foundation certificate.
There is a solution in the Eclipse head (eclipse bug # 309059 "Eclipse foundation certificate not trusted by latest Oracle VMs"). I am investigating whether this can be cherry-picked and used against 3.5.2 in Ubuntu.
Here are the notes from my investigation of the issue.
--------
I investigated the Ubuntu and Debian packages "ca-certificates" and "ca-certificate
In Eclipse, when updating CDT for example, the user is offered a list of certificates which aren't trusted via the installed roots. In this case:
"Eclipse.org Foundation, Inc; Digital Class 3 - Java Object Signing..."
The certificate chain presented is:
"Eclipse.org Foundation, Inc; Digital Class 3 - Java Object Signing..."
> "Eclipse.org Foundation, Inc; Digital Class 3 - Java Object Signing..."
>> "Verisign Class 3 Code Signing 2004 CA; ..."
>>> "null; Class 3 Public Primary Certification Authority; Verisign\, Inc."
When examining the details of each certificate in the chain I noticed that the signing algorithm for the first 3 is "SHA1withRSA".
*HOWEVER*, the signing algorithm for "null; Class 3 Public Primary Certification Authority; Verisign\, Inc." is MD2withRSA.
MD2 with RSA was shown to be insecure some time ago (see CVE-2009-2409) and Verisign withdrew this certificate and replaced it with one using SHA1withRSA ("Root 2" downloadable from the Verisign web-site at https:/
The Debian and Ubuntu "ca-certificates" package contains the MD2withRSA certificate in the "mozilla/" sub-directory, which infers to me that it has come from the Mozilla collection of trusted roots.
---
openssl x509 -text -noout -issuer -issuer_hash -in /usr/share/
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
Signature Algorithm: md2WithRSAEncry
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 1 23:59:59 2028 GMT
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
---
I couldn't find the SHA1withRSA version so I downloaded it
---
wget https:/
openssl x509 -text -noout -in Verisign_
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
Signature Algorithm: sha1WithRSAEncr
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 2 23:59:59 2028 GMT
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
---
and replaced the existing file and re-generated the "/etc/ssl/
At this point I expected Eclipse to treat the updates as trusted and not prompt, but I was disappointed. Eclipse offered the same certificate chain described above.
When I looked at the "null; Class 3 Public Primary Certification Authority; Verisign\, Inc." details I noticed the signing algorithm *IS STILL* MD2withRSA.
Earlier I had thought the certificate details had come from the Java keystore, but this made me think it may be coming from the JAR file's "META_INF/
I ran jarsigner on "org.eclipse.
jarsigner -certs -verify -verbose -keystore /etc/ssl/
1760 Tue Feb 16 14:52:22 GMT 2010 META-INF/
1554 Tue Feb 16 14:52:24 GMT 2010 META-INF/
5638 Tue Feb 16 14:52:24 GMT 2010 META-INF/
0 Tue Feb 16 14:33:48 GMT 2010 META-INF/
sm 76 Tue Feb 16 14:52:18 GMT 2010 META-INF/
[entry was signed on 16/02/10 19:52]
X.509, CN="Eclipse.org Foundation, Inc", OU=Digital ID Class 3 - Java Object Signing, O="Eclipse.org Foundation, Inc", L=Ottawa, ST=Ontario, C=CA
[certificate is valid from 30/01/09 00:00 to 14/04/12 00:59]
X.509, CN=VeriSign Class 3 Code Signing 2004 CA, OU=Terms of use at https:/
[certificate is valid from 16/07/04 01:00 to 16/07/14 00:59]
[KeyUsage, NetscapeCertType extension does not support code signing]
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US (verisign_
[certificate is valid from 29/01/96 00:00 to 02/08/28 00:59]
Although jarsigner doesn't report the signing algorithm it does show whether any of the certificates are in the system's keystore using the "k" flag against a file, but in this case the only flags are "sm", and the command was run after the new SHA1withRSA certificate had been installed.
Also, in this case we are fortunate that the two versions of the certificate issued by Verisign have different expiry dates:
MD2withRSA: Aug 1 23:59:59 2028 GMT
SHA1withRSA: Aug 2 23:59:59 2028 GMT
jarsigner shows the certificate chain uses the one with expiry date "02/08/28 00:59" which is in fact "Aug 1 23:59:59 2028 GMT" since I am currently in the GMT+1 time-zone.
So the certificate chain Eclipse is taking exception to appears to be derived from the updates ("META-
I did further investigations on the MD2withRSA issue and discovered that the algorithm was disabled beginning with Sun Java 6 build 1.6.0_17. See http://
This arrived in Debian and Ubuntu with the package:
sun-java6 (6-17-1)
* QA upload.
* New upstream version. (Closes: #558173)
Release notes at http://
-- Giuseppe Iuculano <email address hidden> Sat, 28 Nov 2009 19:02:56 +0100
In OpenJDK MD2withRSA was also disabled and arrived in Ubuntu with the package:
openjdk-6 (6b17~pre2-
* Security updates:
...
- (CVE-2009-2409) deprecate MD2 in SSL cert validation (Kaminsky) (6861062).
...
-- Matthias Klose <email address hidden> Mon, 09 Nov 2009 17:48:43 +0100
I suspect this is the crux of the issue. MD2withRSA is not supported by these recent versions of the JRE/JDKs, but the Eclipse Foundation is/has been signing JARs with a certificate that has the MD2withRSA root in its chain.
The solution would seem to be for the updated Verisign "Class 3 Public Primary Certification Authority" to be installed on the Eclipse Foundation's signing server so that when jarsigner runs it uses the SHA1withRSA signed certificate.
However, this doesn't help already existing signed plug-in bundles.
In Eclipse bug #309059 "Eclipse foundation certificate not trusted by latest Oracle VMs" a patch was added to KeyStoreTrustEn
description: | updated |
Changed in eclipse (Ubuntu): | |
assignee: | nobody → TJ (intuitivenipple) |
importance: | Undecided → Medium |
Changed in eclipse (Ubuntu): | |
status: | New → In Progress |
Changed in eclipse (Ubuntu): | |
assignee: | nobody → TJ (intuitivenipple) |
tags: | added: patch |
Changed in eclipse (Ubuntu Lucid): | |
status: | New → Fix Committed |
tags: |
added: verification-done removed: verification-needed |
The patch I've attached has been tested by building in a local pbuilder for lucid, installing the updated packages, then running Eclipse and successfully updating without any certificate prompts from Eclipse.