Thilo,
that's a real problem - if the used SKI algorithm is not
known. This is why I refused to implement it the first
time - because there are two methods availiabe (maybe even
another one if one reads RFC3280 - thete is a unique id
mentioned). And recomputing the SKI applying one or the
other method is somewhat "guessing the right stuff". Such
a guessing is _not_ what security is all about.
My opinon is: either one has the certificate exactly as
it is required or the verification will fail!
Thus I would like to start a discussion on that topic on
the list:
What are the opinions of the other subscribers
on the list regarding this topic?
To your other questions: when we were doing interop
tests the certificates were provided by someone in
PKCS#12 format. Dims converted it into the keystore.
AFAIK OpenSSL is able to produce v3 certificates. You
may have a look into the interop/keys directory
about some hints (README) how to convert the
*pfx files containing PKCS#12 into keystore. Maybe
this provides some help.
Also in the top level keys directory there are some *.sh
files that provide some help to create an own "CA" (very
basic) and to convert the certificates into keystore.
WSS4J also supports PKCS#12 keystore format. This format
is usually used by Windows.
Regards,
Werner
Thilo Frotscher schrieb:
Hi,
I inserted the code Hans sent into class Merlin.
However, it didn't help, since this algorithm
calculates different byte arrays than WSE sends
me. We are using WSE Service Pack 3, which is the
most recent. Maybe we should try the second
described algorithm.
We still don't get this interop to work...
- How can I create X509 *v3* certificates on the
Java side? Keytool can only create *v1*, which
does not contain SKIs.
- How can I tell WSE that it should not use
SKI as a Security Token Reference, but
Issuer Serial?
- How can I import certificates that were created
on Windows into a keystore? Which keystore type
is recommended?
Since you did a lot of interop tests between .NET
and WSS4J, it would be great if you could send some
step-by-step instructions on how to make this
certificate stuff work between WSS4J and .NET.
Any help is appreciated VERY much!
Thanks,
Thilo
Werner Dittmann schrieb:
Hans,
thanks for the info - I remeber you mentioned this some
time ago and provided the algo. I'll try to include this algo
into Merlin.
Just another question: RFC3280 states that there are two
common ways to crate a SKI - you algo describes one.
Do you know if it is necessary to implement the other
one too?
Regards,
Werner
Granqvist, Hans schrieb:
Hi Thilo,
I think this issue has been discussed on this list before.
(Do you have access to the archives?)
To summarize:
A cert without the OID SKI is still a valid cert since it
is not a critical extension. The SKI is a derived value and
there are two known ways of calculating SKI: the right way,
and some funky way that appeared in some WSE revision.
In another project, we had to deal with certs lacking a SKI,
and we solved it by calculating the SKI ourselves.
Hans
-----Original Message-----
From: Thilo Frotscher [mailto:[EMAIL PROTECTED] Sent:
Thursday, July 28, 2005 9:04 AM
To: [email protected]
Subject: [WSS4J] NullPointerException in Merlin / .NET Interop issues
Hi all,
we have an interoperablity issue between WSS4J and WSE. And we
believe to have found a bug in WSS4J. Please have a look at it and
give some advice.
Scenario: We want to send an encrypted and signed message from WSE
to WSS4J. I created a key pair with keytool on Java SE 5.0 and
exported a certificate from my keystore (JCEKS). This certificate
was successfully imported on the .NET side. The SOAP message that
WSE sends to WSS4J looks ok.
However, WSE uses a <SecurityTokenReference> with a <KeyIdentifier>
element. When this <SecurityTokenReference> is processed by WSS4J a
NullPointerException is thrown in Class Merlin, method
getSKIBytesFromCert(X509Certificate cert)
Reason for the exception: look at this code from getSKIBytesFromCert...
byte[] derEncodedValue = cert.getExtensionValue(SKI_OID);
if (cert.getVersion() < 3) {...}
byte abyte0[] = new byte[derEncodedValue.length - 4];
The return value of cert.getExtensionValue(SKI_OID) is null in our
case. Thus, the third line fails. As stated in Sun's API
documentation, null return values can happen.
http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/X509Extension.html#getExtensionValue(java.lang.String)
1) This should be enhanced so that NullPointerExceptions can't happen
anymore.
2) What does it mean that null is returned? Does this mean that the
certificate doesn't have an extension? 3) Would it be still a valid
certificate or is it invalid without the extension?
4) How can we resolve this issue? Do the certificates created by
keytool/Java5.0 have interop issues?
5) (maybe off-topic): does anybody know how .NET can be configured to
send a <SecurityTokenReference> with <X509IssuerSerial> instead of
<KeyIdentifier>?
Thank you very much,
Thilo
_________________________________________________________________________
Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle
Freunde gleichzeitig schicken:
http://freemail.web.de/features/?mc=021179
