| 2010-10-06 16:50:45 |
TJ |
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://gb.archive.ubuntu.com/ubuntu/ lucid-updates/universe Packages
100 /var/lib/dpkg/status
3.5.2-2ubuntu4 0
500 http://gb.archive.ubuntu.com/ubuntu/ lucid/universe Packages
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/certs/java/cacerts" when ca-certificates-java is installed.
The problem is caused by the Eclipse Foundation's certificate chain in the JAR file's META_INF/ECLIPSEF.RSA originating from a Verisign code-signing root certificate ("Class 3 Public Primary Certification Authority") that used the MD2withRSA signing algorithm.
Although the package "ca-certificates" contains the Verisign root CA ("/usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt") signed using MD2withRSA Eclipse refuses to trust the Eclipse Foundation code-signing certificate.
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-certificates-java". The former contains the collection of trusted public roots installed to "/usr/share/ca-certificates/", the latter generates "/etc/ssl/certs/java/cacerts" (when update-ca-certificates -f is run) that is symbolic-linked to by the Sun and OpenJDK versions of Java.
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://www.verisign.com/support/roots.html) but said that it is acceptable to continue trusting previously issued certificates that have this in their chain of trust (https://press.verisign.com/easyir/customrel.do?easyirid=AFC0FF0DB5C560D3&version=live&prid=523818&releasejsp=custom_97).
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/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
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://www.verisign.com/repository/roots/root-certificates/PCA-3.pem -O Verisign_Class_3_Public_Primary_Certification_Authority.crt
openssl x509 -text -noout -in Verisign_Class_3_Public_Primary_Certification_Authority.crt
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
Signature Algorithm: sha1WithRSAEncryption
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/certs/java/cacerts" file using "sudo update-ca-certificates -f -v".
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/ECLIPSEF.RSA".
I ran jarsigner on "org.eclipse.cdt_6.0.2.201002161416.jar" and examined the results (edited for brevity here):
jarsigner -certs -verify -verbose -keystore /etc/ssl/certs/java/cacerts /home/tj/.eclipse/org.eclipse.platform_3.5.0_155965261/plugins/org.eclipse.cdt_6.0.2.201002161416.jar
1760 Tue Feb 16 14:52:22 GMT 2010 META-INF/MANIFEST.MF
1554 Tue Feb 16 14:52:24 GMT 2010 META-INF/ECLIPSEF.SF
5638 Tue Feb 16 14:52:24 GMT 2010 META-INF/ECLIPSEF.RSA
0 Tue Feb 16 14:33:48 GMT 2010 META-INF/
sm 76 Tue Feb 16 14:52:18 GMT 2010 META-INF/eclipse.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://www.verisign.com/rpa (c)04, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[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_class_3_public_primary_certification_authority)
[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-INF/ECLIPSEF.RSA"), not the host system.
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://java.sun.com/javase/6/webnotes/6u17.html and bug 6861062 "Disable MD2 in certificate chain validation" (not publically viewable!).
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://java.sun.com/javase/6/webnotes/6u17.html
-- Giuseppe Iuculano <iuculano@debian.org> 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-0ubuntu3)
* Security updates:
...
- (CVE-2009-2409) deprecate MD2 in SSL cert validation (Kaminsky) (6861062).
...
-- Matthias Klose <doko@ubuntu.com> 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 KeyStoreTrustEngine.java to ignore the root CA in signed JARs and find it in the "cacerts" file. |
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://gb.archive.ubuntu.com/ubuntu/ lucid-updates/universe Packages
100 /var/lib/dpkg/status
3.5.2-2ubuntu4 0
500 http://gb.archive.ubuntu.com/ubuntu/ lucid/universe Packages
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/certs/java/cacerts" when ca-certificates-java is installed.
The problem is caused by the Eclipse Foundation's certificate chain in the JAR file's META_INF/ECLIPSEF.RSA originating from a Verisign code-signing root certificate ("Class 3 Public Primary Certification Authority") that used the MD2withRSA signing algorithm.
Although the package "ca-certificates" contains the Verisign root CA ("/usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt") signed using MD2withRSA Eclipse refuses to trust the Eclipse Foundation code-signing certificate.
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-certificates-java". The former contains the collection of trusted public roots installed to "/usr/share/ca-certificates/", the latter generates "/etc/ssl/certs/java/cacerts" (when update-ca-certificates -f is run) that is symbolic-linked to by the Sun and OpenJDK versions of Java.
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://www.verisign.com/support/roots.html) but said that it is acceptable to continue trusting previously issued certificates that have this in their chain of trust (https://press.verisign.com/easyir/customrel.do?easyirid=AFC0FF0DB5C560D3&version=live&prid=523818&releasejsp=custom_97).
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/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
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://www.verisign.com/repository/roots/root-certificates/PCA-3.pem -O Verisign_Class_3_Public_Primary_Certification_Authority.crt
openssl x509 -text -noout -in Verisign_Class_3_Public_Primary_Certification_Authority.crt
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be
Signature Algorithm: sha1WithRSAEncryption
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/certs/java/cacerts" file using "sudo update-ca-certificates -f -v".
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/ECLIPSEF.RSA".
I ran jarsigner on "org.eclipse.cdt_6.0.2.201002161416.jar" and examined the results (edited for brevity here):
jarsigner -certs -verify -verbose -keystore /etc/ssl/certs/java/cacerts /home/tj/.eclipse/org.eclipse.platform_3.5.0_155965261/plugins/org.eclipse.cdt_6.0.2.201002161416.jar
1760 Tue Feb 16 14:52:22 GMT 2010 META-INF/MANIFEST.MF
1554 Tue Feb 16 14:52:24 GMT 2010 META-INF/ECLIPSEF.SF
5638 Tue Feb 16 14:52:24 GMT 2010 META-INF/ECLIPSEF.RSA
0 Tue Feb 16 14:33:48 GMT 2010 META-INF/
sm 76 Tue Feb 16 14:52:18 GMT 2010 META-INF/eclipse.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://www.verisign.com/rpa (c)04, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[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_class_3_public_primary_certification_authority)
[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-INF/ECLIPSEF.RSA"), not the host system.
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://java.sun.com/javase/6/webnotes/6u17.html and bug 6861062 "Disable MD2 in certificate chain validation" (not publically viewable!).
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://java.sun.com/javase/6/webnotes/6u17.html
-- Giuseppe Iuculano <iuculano@debian.org> 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-0ubuntu3)
* Security updates:
...
- (CVE-2009-2409) deprecate MD2 in SSL cert validation (Kaminsky) (6861062).
...
-- Matthias Klose <doko@ubuntu.com> 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 KeyStoreTrustEngine.java to ignore the root CA in signed JARs and find it in the "cacerts" file.
|
|
