SSL and pkcs12

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL and pkcs12

Flaklypa
I have a Pkcs12 that Im trying to use for ssl client authentication (by
setting the javax.net.ssl.keyStoreType, javax.net.ssl.keyStore and the
javax.net.ssl.keyStorePassword properties), but Im getting this error:

HTTP transport error: java.net.SocketException: Default SSL context
init failed: failed to decrypt safe contents entryjava.
security.NoSuchAlgorithmException: RC2 Only for safeContents)

The pkcs12 has a 3DES PBE for both cert and key. If, when I generate the
PKCS12, instead use a RC2 based PBE it works!?

Also, how do I force the ssl implementation to use BC ? Because by
setting the previously mentioned properties I suppose it uses the
default provider, which isn't BC on my system)

Reply | Threaded
Open this post in threaded view
|

Re: SSL and pkcs12

David Hook-4

Can't say I've quite seen it happen like this before.

The JSSE is now supposed to use the standard mechanism for finding
providers for algorithms so providing BC is installed it should pick it
up as it's needed. I think what's happened is that the exception is
trying to tell you that it expects the certs to be encrypted with RC2
(which used to be the standard way of doing it DES-EDE for the key, 40
bit RC2 for the certs) - so the problem is the PKCS12 store
implementation being used, not what ciphers it can find. This one I have
seen before, although not in this context.

Try setting javax.net.ssl.keyStoreType to PKCS12-DEF - this will use the
Bouncy Castle PKCS12 implementation, but preserve defaults for
everything else.

Regards,

David

On Sat, 2005-08-27 at 09:31 +0200, Daniel Granath wrote:

> I have a Pkcs12 that Im trying to use for ssl client authentication (by
> setting the javax.net.ssl.keyStoreType, javax.net.ssl.keyStore and the
> javax.net.ssl.keyStorePassword properties), but Im getting this error:
>
> HTTP transport error: java.net.SocketException: Default SSL context
> init failed: failed to decrypt safe contents entryjava.
> security.NoSuchAlgorithmException: RC2 Only for safeContents)
>
> The pkcs12 has a 3DES PBE for both cert and key. If, when I generate the
> PKCS12, instead use a RC2 based PBE it works!?
>
> Also, how do I force the ssl implementation to use BC ? Because by
> setting the previously mentioned properties I suppose it uses the
> default provider, which isn't BC on my system)
>


Reply | Threaded
Open this post in threaded view
|

How to create a signed CMS message without content

Tomas Gustavsson-3

Hi, I ran into some trouble working with the CMS classes to create SCEP
messages. A SCEP response contains an SignedData message with empty
content, and I couldn't figure out how to create the empty content with
BC so I just stuck a dummy text in there. This causes a client using
Cryptlib to fail unforturnately.

This is the kind of code I use:
-----
CMSEnvelopedDataGenerator edGen = new CMSEnvelopedDataGenerator();
ArrayList certList = new ArrayList();
certList.add(cert);
CertStore certs = CertStore.getInstance("Collection", new
CollectionCertStoreParameters(certList), "BC");

msg = new CMSProcessableByteArray("PrimeKey".getBytes());
CMSSignedDataGenerator gen = new CMSSignedDataGenerator();
gen.addSigner(signKey, signCert, CMSSignedDataGenerator.DIGEST_SHA1);
gen.addCertificatesAndCRLs(certs);
s = gen.generate(msg, true, "BC");
-----

Can I create an emtpy message instead of the "PrimeKey" text?

Appended is the response I got from Peter Gutman when investigating the
issue.

Cheers,
Tomas

-----
Thanks.  Ahh, there's the problem, EJBCA isn't returning a proper PKCS
#7 cert
chain.  It should be:

pkcsCertRep SignedData ::= { -- PKCS#7
   version 1
   digestAlgorithm {iso(1) member-body(2) US(840)
                    rsadsi(113549) digestAlgorithm(2) 5}
   contentInfo { -- empty content since this is degenerated PKCS#7
                 contentType {pkcs-7 1}}
   certificates {
   [...]

whereas what's returned is actually a signed-data message:

    0 NDEF: SEQUENCE {
    2    9:   OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
   13 NDEF:   [0] {
   15 NDEF:     SEQUENCE {
   17    1:       INTEGER 1
   20   11:       SET {
   22    9:         SEQUENCE {
   24    5:           OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
   31    0:           NULL
          :           }
          :         }
   33 NDEF:       SEQUENCE {
   35    9:         OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
   46 NDEF:         [0] {
   48 NDEF:           OCTET STRING {
   50    8:             OCTET STRING 'PrimeKey'
          :             }
          :           }
          :         }
   66 1236:       [0] {
   [...]

So when cryptlib sees the signed data it doesn't know what it's supposed
to do
with it and rejects the message.  (Actually there's code in there to
speculatively skip the data content if possible, but in this case since
it has
an indefinite length cryptlib can't tell how far to skip ahead without
burrowing down into the data content, which it doesn't try to do because
it's
not really supposed to be there in the first place.
-----