[Karmic] Update to ca-certificates 20090624 prevents ca-certificates-java from installing

[Thierry Carrez]

Binary package hint: ca-certificates

Recent update to ca-certificates 20090624 breaks ca-certificates-java installation, currently preventing all Java-based builds in karmic from succeeding (ca-certificates-java is required by default-jdk, so default-jdk cannot be installed as a build dependency).

Note that you should also get ca-certificates upgrade errors on systems where ca-certificates-java is already installed.

Here is the buildlog error:

Setting up ca-certificates-java (20081028) ...
creating /etc/ssl/certs/java/cacerts...
Certificate was added to keystore
  added certificate cacert.org/cacert.org.crt
Certificate was added to keystore
  added certificate gouv.fr/cert_igca_dsa.crt
Certificate was added to keystore
  added certificate gouv.fr/cert_igca_rsa.crt
keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
  error adding mozilla/COMODO_ECC_Certification_Authority.crt
Certificate was added to keystore
  added certificate mozilla/DigiNotar_Root_CA.crt
Certificate was added to keystore
  added certificate mozilla/Network_Solutions_Certificate_Authority.crt
Certificate was added to keystore
  added certificate mozilla/WellsSecure_Public_Root_Certificate_Authority.crt
failed.
dpkg: error processing ca-certificates-java (--configure):
 subprocess post-installation script returned error exit status 1

Apparently the addition of mozilla/COMODO_ECC_Certification_Authority.crt doesn't please ca-certificates-java since it doesn't know how to handle SHA384withECDSA signatures. I guess this can either be fixed in ca-certificates or ca-certificates-java, so I'll pull both as affected.

[Thierry Carrez (ttx)]

Proposed quick fix for ca-certificates (avoid installing the certificate in question).

[Matthias Klose (doko)]

IcedTea6-1.5:

keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
  error adding /etc/ssl/certs/COMODO_ECC_Certification_Authority.pem

[Matthias Klose (doko)]

could we fix this in ca-certificates-java instead by checking the signature type, and then omit it?

[Thierry Carrez (ttx)]

We could use openssl in jks-keystore.hook to decode proposed .pem contents and specifically exclude the one(s) with:

Signature Algorithm: 1.2.840.10045.4.3.3

(which maps to SHA384withECDSA according to http://javadoc.iaik.tugraz.at/cms_smime/current/iaik/cms/CMSAlgorithmID.html)
I'm just unsure that would be the only one we would want to exclude...

[Philipp Kern (pkern)]

On Thu, Jun 25, 2009 at 03:10:53PM -0000, Thierry Carrez wrote:
> We could use openssl in jks-keystore.hook to decode proposed .pem
> contents and specifically exclude the one(s) with:
>
> Signature Algorithm: 1.2.840.10045.4.3.3
>
> (which maps to SHA384withECDSA according to http://javadoc.iaik.tugraz.at/cms_smime/current/iaik/cms/CMSAlgorithmID.html)
> I'm just unsure that would be the only one we would want to exclude...

Currently, yes. AFAICS.

Kind regards,
Philipp Kern

[Timothy Pearson (kb9vqf)]

This is currently thwarting the 389 Directory Server project at https://launchpad.net/~ubuntu-389-directory-server

It is also affecting bug 382261

Please fix ASAP!

[Thierry Carrez (ttx)]

ca-certificates-java with SHA384withECDSA certificates filtering

Results for initial install (postinst):

creating /etc/ssl/certs/java/cacerts...
  removed untrusted certificate mozilla/Equifax_Secure_Global_eBusiness_CA.crt
  removed untrusted certificate mozilla/UTN_USERFirst_Object_Root_CA.crt
  ignored certificate mozilla/COMODO_ECC_Certification_Authority.crt (SHA384withECDSA unsupported)
Certificate was added to keystore
  added certificate mozilla/DigiNotar_Root_CA.crt
Certificate was added to keystore
  added certificate mozilla/Network_Solutions_Certificate_Authority.crt
Certificate was added to keystore
  added certificate mozilla/WellsSecure_Public_Root_Certificate_Authority.crt
done.

Results for ca-certificates upgrade (hook):

Updating certificates in /etc/ssl/certs... 4 added, 2 removed; done.
Running hooks in /etc/ca-certificates/update.d....
updating keystore /etc/ssl/certs/java/cacerts...
  ignored (SHA384withECDSA unsupported): /etc/ssl/certs/COMODO_ECC_Certification_Authority.pem
Certificate was added to keystore
  added: /etc/ssl/certs/DigiNotar_Root_CA.pem
Certificate was added to keystore
  added: /etc/ssl/certs/Network_Solutions_Certificate_Authority.pem
Certificate was added to keystore
  added: /etc/ssl/certs/WellsSecure_Public_Root_Certificate_Authority.pem
  does not exists: /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem
  does not exists: /etc/ssl/certs/UTN_USERFirst_Object_Root_CA.pem
done.
done.

[Thierry Carrez (ttx)]

Like Matthias said, it's better to workaround it in ca-certificates-java.

[Thierry Carrez (ttx)]

Hmm... This fails to build on an uptodate karmic buildd because the current ca-certificates-java gets installed as a build dependency... which fails with ca-certificates-20090624.

I guess it's necessary to first revert ca-certificates, build ca-certificates-java, then resync ca-certificates ?

[Matthias Klose (doko)]

ca-certificates-20090624build1 uploaded (not running the hooks), ca-certificates-java 20090629 needs a sync from Debian unstable/incoming

[Matthias Klose (doko)]

fixed in ca-certificates-java 20090629

[Colin Watson (cjwatson)]

I've unsubscribed ubuntu-main-sponsors to get this off the sponsorship list, as there doesn't appear to be anything to sponsor for openjdk-6 right now. Please resubscribe if necessary.

[Pantelis Koukousoulas (pktoss)]

Created attachment 240
A small testcase that illustrates the missing SHA384withECDSA Signature Algorithm problem.

[ankostis (ankostis)]

* Needed to add a suitable for 'SHA384withECDSA' provider into 'java.security' config-file.
* Supposedly SHA384withECDSA provided by sun.security.pkcs11.SunPKCS11
 with NSS as the native backend, as described in:
  http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider
 with the following config-file:
  name = NSS
  nssLibraryDirectory = /opt/tests/nss/lib
  nssDbMode = noDb
  attributes = compatibility
* In fedora needed to install nss-devel-3.12.3-4.fc11.i586 due to a missing NSS lib.
* Debug java-prop: java.security.debug={all|provider|sunpkcs11}
* But NSS does *NOT* by default compile ECC! according to:
 http://www.mozilla.org/projects/security/pki/nss/nss-3.11/nss-3.11-algorithms.html
* BUT Testcrypto.java TestCase also fails in sun's jdk!!

[ankostis (ankostis)]

Managed to import COMODO's ECC certificate.

This bug is present also in sun's JDK and it gets fixed as prescribed by Andreas Sterbenz:
http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider

We need to add the 'sun.security.pkcs11.SunPKCS11' provider with a single config-arg pointing to a file containing the following properties:
 name = NSS
 nssLibraryDirectory = /usr/lib
 nssDbMode = noDb
 attributes = compatibility

Tested on:
* Gentoo, needs devlibs/nss installed and a minor config modification:
  nssLibraryDirectory=/usr/lib/nss
and it works ok.
* Debian just needs libnss3-1d installed, and it also works ok.
* Fedora's NSS, by default is compiled most probably *without* ECC!
So it fails.
  (see: http://www.mozilla.org/projects/security/pki/nss/nss-3.11/nss-3.11-algorithms.html)

[Jon-vanalten (jon-vanalten)]

I'll be the first to admit I know little about nss, but it looks like you're absolutely correct as some others have had similar issues:

https://bugzilla.redhat.com/show_bug.cgi?id=492124

May I suggest that you post these details (or simply a link to this bug) in a new nss bug on the Red Hat bugzilla:

https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora

I'd do so myself but it's not my itch to scratch :D (more importantly, someone with more intimate knowledge of the issue could contribute more meaningfully to the report).

From the above convo and the bits I've read elsewhere on the subject it seems this is not an IcedTea bug, so I'm closing this. Feel free to reopen if I am mistaken.

[Matthias Klose (doko)]

are you sure about closing the report? At least java.security needs to be aware of the new security provider. One possibility would be a configure check in IcedTea, and modification of the java.security file.

[Jon-vanalten (jon-vanalten)]

Fairly sure. From Andreas Sterbenz's 2006 blog posting linked by Kostis in comment #2 and #3, programs wishing to use this (not new) provider should add it (ie "Security.insertProviderAt(nss, 1);" at runtime, and set up config file as described. So unless I have misunderstood completely, this is not a build or configure issue for IcedTea.

Furthermore,

http://blogs.sun.com/andreas/entry/elliptic_curve_cryptography_in_java

indicates that the use of ECC depends on NSS library specifically compiled with ECC support. All signs point to Fedora's NSS library not being compiled as such. Thus the recommendation to open Red Hat bug wrt the nss (really I should say nss-devel) package.

If you know something I don't (which is entirely likely), please reopen the report and add info as required.

[Matthias Klose (doko)]

it's keytool from OpenJDK which does need this support to add the certificate to the keystore, and read it again.

[Andrew John Hughes (ahughes)]

I don't think keytool needs to be altered. We could however have NSS support enabled out of the box. We are in a better position than Sun in that we are not distributing proprietary standalone binaries, and can instead depend on NSS. Thus, it seems, from reading these blogs, that we could detect NSS using autoconf and generate the configuration, rather than leaving it to the end user.

The other issue is that Fedora's NSS doesn't have elliptic curve support. This needs fixing in Fedora with the bug Jon mentioned.

You'll be glad to know that a pure Java implementation of elliptic curve cryptography is slated for JDK7; http://openjdk.java.net/projects/jdk7/features/#f73

[Jon-vanalten (jon-vanalten)]

oic. After looking some at sun/security/tools/KeyTool.java and sun/security/pkcs11/SunPKCS11.java, I agree that changes to KeyTool would not be the best approach here. There are a number of provider types in the JDK, they are not given any special treatment by KeyTool. Similary not all providers are known in java.security.

A couple of questions come to mind about the possibility of generating a NSS config file (depending on detection of nss library). First: how would we know whether the local library is built with ECC support? It is not afaik a default build option, Fedora may not be the only distro not building with that option. Second: folks wishing to use this provider would need to know the location of the config file to pass as an arg when specifying this provider to keytool. Either that or we need to patch SunPKCS11.java so that default constructor looks to some location for config file rather than failing. Do other providers require config files, and is there already some location where such files are put by default?

[Pantelis Koukousoulas (pktoss)]

During our little coding camp in greece, this was one of the issues we looked into.
It turns out it is possible to use libnss as a PKCS11 provider, thereby making
the import of the specific certificate (and potential others in the future that want
to use the same algorithm) work.

The details are in http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=356

Since it only needs a new dependency openjdk -> libnss and a simple config file
this should be a viable solution.

There is already a patched version of openjdk in my ppa:
https://launchpad.net/~pktoss/+archive/ppa/

[ankostis (ankostis)]

(In reply to comment #9)
> A couple of questions come to mind about the possibility of generating a NSS
> config file (depending on detection of nss library).
> First: how would we know whether the local library is built
> with ECC support?
> It is not afaik a default build option,
> Fedora may not be the only distro not building with that option.

As listed in #3, i had verified that:
* gentoo[1] and
* debian/ubuntu[2] build NSS with ECC by default.
Also linked this bug to fedora's relevant bug[3] as suggested.

[1] http://bugs.gentoo.org/247221
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490826
[3] https://bugzilla.redhat.com/show_bug.cgi?id=492124

[Andrew John Hughes (ahughes)]

OpenJDK7 just gained native ECC support:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6840752
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1ff7163fc5f7

From reading the changeset it seems they import the Mozilla NSS code. So we may actually need to patch this back out in IcedTea... sigh.

Jon, for 6 I think we would need to patch java.security to include that provider if NSS is available.

[Andrew John Hughes (ahughes)]

I've queried this inclusion of NSS on the security-dev list:

http://mail.openjdk.java.net/pipermail/security-dev/2009-August/001115.html

[Andrew John Hughes (ahughes)]

Just tried adding this on Gentoo and I'm getting:

java.lang.RuntimeException: Could not parse key values
 at sun.security.pkcs11.P11Key$P11ECPublicKey.fetchValues(P11Key.java:1026)
 at sun.security.pkcs11.P11Key$P11ECPublicKey.getEncodedInternal(P11Key.java:1036)
 at sun.security.pkcs11.P11Key.getEncoded(P11Key.java:126)
 at sun.security.x509.CertificateX509Key.encode(CertificateX509Key.java:105)
 at sun.security.x509.X509CertInfo.emit(X509CertInfo.java:819)
 at sun.security.x509.X509CertInfo.encode(X509CertInfo.java:189)
 at sun.security.x509.X509CertImpl.sign(X509CertImpl.java:528)
 at sun.security.x509.X509CertImpl.sign(X509CertImpl.java:486)
 at sun.security.x509.CertAndKeyGen.getSelfCertificate(CertAndKeyGen.java:288)
 at sun.security.tools.KeyTool.doGenKeyPair(KeyTool.java:1223)
 at sun.security.tools.KeyTool.doCommands(KeyTool.java:827)
 at sun.security.tools.KeyTool.run(KeyTool.java:194)
 at sun.security.tools.KeyTool.main(KeyTool.java:188)
Caused by: java.io.IOException: Point does not match field size
 at sun.security.ec.ECParameters.decodePoint(ECParameters.java:92)
 at sun.security.pkcs11.P11ECKeyFactory.decodePoint(P11ECKeyFactory.java:78)
 at sun.security.pkcs11.P11Key$P11ECPublicKey.fetchValues(P11Key.java:1023)
 ... 12 more

This is with dev-libs/nss-3.12.3-r1

[Andrew John Hughes (ahughes)]

To replicate, you need an IcedTea6 build in ${java.home}. Then create ${java.home}/jre/lib/security/nss.cfg as follows:

name = NSS
nssLibraryDirectory = ${nsslibdir}
nssDbMode = noDb
attributes = compatibility

where nsslibdir can be found by running pkg-config --variable=libdir nss

You then link this in by adding the following line to ${java.home}/jre/lib/security/java.security:

security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

Then run:

${java.home}/bin/keytool -v -genkeypair -keyalg EC -keysize 256 -keystore ectest.jks -storepass test12 -dname "CN=ECC Test"

[Andrew John Hughes (ahughes)]

A little debugging finds that:
array length: 67
field size: 256
n = 32
array: [4, 65, 4, -26, -5, 56, -82, -53, -122, 32, 102, -86, -64, -59, 84, 5, 110, 1, -49, 38, -7, 3, -97, 122, -36, -18, 99, -126, -83, 83, 34, 12, -38, -84, 43, 83, -38, -25, -58, 9, -30, -37, 108, -43, 35, -118, -15, 53, 104, -26, -45, -51, 3, -83, 100, -119, -108, 25, 75, -37, 39, 9, 50, -121, 105, 68, 96]

The check that throws the exception is the failure of array length to equal (n*2)+1 (65) in this case. The array returned by NSS has two extra bytes. n is calculated from the field size of 256 by adding 7 and shifting right 3. If the field size was 257, it would thus match the array size but this is not a legal EC key size.

[Andrew John Hughes (ahughes)]

The problem is that the Java code doesn't support an DER encoded key.
From mozilla/security/nss/lib/softoken/pkcs11.c in NSS:

            /* special note: We can't just use the first byte to determine
             * between these 2 cases because both EC_POINT_FORM_UNCOMPRESSED
             * and SEC_ASN1_OCTET_STRING are 0x04 */

     /* handle the non-DER encoded case (UNCOMPRESSED only) */
            if (pubKey->u.ec.publicValue.data[0] == EC_POINT_FORM_UNCOMPRESSED
                && pubKey->u.ec.publicValue.len == keyLen) {
                break; /* key was not DER encoded, no need to unwrap */
            }

            /* if we ever support compressed, handle it here */

     /* handle the encoded case */
            if ((pubKey->u.ec.publicValue.data[0] == SEC_ASN1_OCTET_STRING)
                && pubKey->u.ec.publicValue.len > keyLen) {
  SECItem publicValue;
                SECStatus rv;

                rv = SEC_QuickDERDecodeItem(arena, &publicValue,
                                         SEC_ASN1_GET(SEC_OctetStringTemplate),
                                         &pubKey->u.ec.publicValue);
                /* nope, didn't decode correctly */
                if ((rv != SECSuccess)
                    || (publicValue.data[0] != EC_POINT_FORM_UNCOMPRESSED)
                    || (publicValue.len != keyLen)) {
                    crv = CKR_ATTRIBUTE_VALUE_INVALID;
                    break;
                }
                /* replace our previous with the decoded key */
                pubKey->u.ec.publicValue = publicValue;
                break;
            }

[Andrew John Hughes (ahughes)]

Tracked this bug down to a lack of DER decoding in ECParameters:

http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-August/000708.html

[Andrew John Hughes (ahughes)]

Fixed in IcedTea6 HEAD:

http://icedtea.classpath.org/hg/icedtea6/rev/b387a64caa08

As noted earlier, for ECC support NSS must be built with ECC support.

[Matthias Klose (doko)]

openjdk now supports PKCS11 cryptography via NSS, all certificates in ca-certificates can be imported

[Andrew John Hughes (ahughes)]

Fixed in 1.7.