openjdk team mailing list archive
-
openjdk team
-
Mailing list archive
-
Message #08807
[Bug 392104] Re: [Karmic] Update to ca-certificates 20090624 prevents ca-certificates-java from installing
Launchpad has imported 20 comments from the remote bug at
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=356.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2009-06-25T14:26:48+00:00 Matthias Klose wrote:
IcedTea6-1.5:
keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
error adding /etc/ssl/certs/COMODO_ECC_Certification_Authority.pem
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/2
------------------------------------------------------------------------
On 2009-07-06T18:39:23+00:00 Pantelis Koukousoulas wrote:
Created attachment 240
A small testcase that illustrates the missing SHA384withECDSA Signature Algorithm problem.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/13
------------------------------------------------------------------------
On 2009-07-07T15:26:00+00:00 ankostis wrote:
* 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!!
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/14
------------------------------------------------------------------------
On 2009-07-07T16:35:10+00:00 ankostis wrote:
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)
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/15
------------------------------------------------------------------------
On 2009-07-14T20:47:45+00:00 Jon-vanalten wrote:
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.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/16
------------------------------------------------------------------------
On 2009-07-14T21:05:21+00:00 Matthias Klose wrote:
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.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/17
------------------------------------------------------------------------
On 2009-07-14T21:46:29+00:00 Jon-vanalten wrote:
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.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/18
------------------------------------------------------------------------
On 2009-07-14T22:04:44+00:00 Matthias Klose wrote:
it's keytool from OpenJDK which does need this support to add the
certificate to the keystore, and read it again.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/19
------------------------------------------------------------------------
On 2009-07-14T23:43:47+00:00 Gnu-andrew-n wrote:
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
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/20
------------------------------------------------------------------------
On 2009-07-15T15:31:39+00:00 Jon-vanalten wrote:
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?
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/21
------------------------------------------------------------------------
On 2009-08-03T08:41:21+00:00 ankostis wrote:
(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
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/23
------------------------------------------------------------------------
On 2009-08-21T17:19:41+00:00 Gnu-andrew-n wrote:
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.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/24
------------------------------------------------------------------------
On 2009-08-24T19:26:29+00:00 Gnu-andrew-n wrote:
I've queried this inclusion of NSS on the security-dev list:
http://mail.openjdk.java.net/pipermail/security-
dev/2009-August/001115.html
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/25
------------------------------------------------------------------------
On 2009-08-27T16:33:50+00:00 Gnu-andrew-n wrote:
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
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/26
------------------------------------------------------------------------
On 2009-08-27T16:36:49+00:00 Gnu-andrew-n wrote:
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"
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/27
------------------------------------------------------------------------
On 2009-08-27T17:18:07+00:00 Gnu-andrew-n wrote:
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.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/28
------------------------------------------------------------------------
On 2009-08-27T18:30:03+00:00 Gnu-andrew-n wrote:
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;
}
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/29
------------------------------------------------------------------------
On 2009-08-27T23:20:19+00:00 Gnu-andrew-n wrote:
Tracked this bug down to a lack of DER decoding in ECParameters:
http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-August/000708.html
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/30
------------------------------------------------------------------------
On 2009-09-28T18:50:53+00:00 Gnu-andrew-n wrote:
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.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/31
------------------------------------------------------------------------
On 2010-03-15T18:43:03+00:00 Gnu-andrew-n wrote:
Fixed in 1.7.
Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-
certificates/+bug/392104/comments/33
** Bug watch added: Red Hat Bugzilla #492124
https://bugzilla.redhat.com/show_bug.cgi?id=492124
** Bug watch added: Debian Bug tracker #490826
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490826
--
You received this bug notification because you are a member of OpenJDK,
which is subscribed to ca-certificates-java in Ubuntu.
https://bugs.launchpad.net/bugs/392104
Title:
[Karmic] Update to ca-certificates 20090624 prevents ca-certificates-
java from installing
Status in Iced Tea:
Fix Released
Status in “ca-certificates” package in Ubuntu:
Invalid
Status in “ca-certificates-java” package in Ubuntu:
Fix Released
Status in “openjdk-6” package in Ubuntu:
Fix Released
Status in “ca-certificates-java” package in Debian:
Fix Released
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/icedtea/+bug/392104/+subscriptions
References
