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