Hi Iam try to run the webservice using x509 certificate validation, I got following error,
Unable to create an X509 certificate factory: D:\keystores\request.arm: java.security.cert.CertificateParsingException: java.io.IOException: X509.ObjectIdentifier() -- data isn't an object ID (tag = 49). I found the Reason for the error, but How can i solve that problem. The reason was Java keystore is not able to handle 4096bit RSA keys. Please help me to solve this problem . Tools used: Websphere Studio 5.2.1 Regards Babu J -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 5:20 PM To: wss4j-dev@ws.apache.org Subject: WSS4J with Tomcat + SSL Token encription is working fine in my developement Tomcat server without SSL. The use of the private key and public key to encript the token is working fine. When I deploy the same application in Tomcat with SSL (the use of SSL is a requirement) I'm having problems with the key used for the encription (wrong key specified). I'm using the same private key to activate SSL but the problems continue. I don't need to sign the whole soap mesage but just the token. Is it possible to use WSS4J inside a Tomcat server using SSL? A possible solution would be to create a new instance of Tomcat without SSL for all my web services in the same server running the main web application with Tomcat + SSL but I would like to find out if there is a solution to my problem before I proceed. Thanks in advance for any replies, Alberto -----Original Message----- From: Yevgeny Rouban [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 11:51 AM To: wss4j-dev@ws.apache.org Subject: Re: X509Data in Encryption KeyInfo Hello. I encountered the same issue with different wrapping of the IssuerSerial and found this thread. But from this discussion its not quite clear why WSS4J (version 1.1) generates the following XML omitting the X509Data element around the X509IssuerSerial element: <ds:KeyInfo ...> <wsse:SecurityTokenReference ...> <ds:X509IssuerSerial ...> <ds:X509IssuerName ...> ...</ds:X509IssuerName> <ds:X509SerialNumber ...>...</ds:X509SerialNumber> </ds:X509IssuerSerial> </wsse:SecurityTokenReference> </ds:KeyInfo> The oasis-200401-wss-x509-token-profile-1.0.pdf (Section 3.2 Token References) reads: "Reference to an Issuer and Serial Number The <wsse:SecurityTokenReference> element contains a <ds:X509Data> element that contains a <ds:X509IssuerSerial> element that uniquely identifies an end entity certificate by its X.509 Issuer and Serial Number." The only place in the spec where the X509Data element is omitted is the example in the Section 3.4 Encryption. I believe that is a typo. And this is corrected in the oasis-wss-x509-token-profile-1.1.pdf. I expect the following structure: <ds:KeyInfo ...> <wsse:SecurityTokenReference ...> <ds:X509Data> <ds:X509IssuerSerial ...> <ds:X509IssuerName ...> ...</ds:X509IssuerName> <ds:X509SerialNumber ...>...</ds:X509SerialNumber> </ds:X509IssuerSerial> </ds:X509Data> </wsse:SecurityTokenReference> </ds:KeyInfo> I believe that this is a bug of WSS4J 1.1 and a bug of those implementations that WSS4J is interoperable with. If I am wrong, could you please explain why? Are there any clarifications on this? I would suggest to fix WSS4J 1.1 so that it could accept both variants (with and without the X509Data element). Otherwise other implementations to be interoperable with WSS4J 1.1 would have to generate incorrect XML. -- Yevgeny Rouban INTEL Middleware Product Division >-----Original Message----- >Subject: X509Data in Encryption KeyInfo > >Alex, > >I've just checked the head of the SVN and this is supported. The >heade of SVN has some WSS spec 1.1 features and we cleaned up this >ambiguity as well. We did not change WSS4J 1.1 because the interops >we did with this version were successfull. > >The current version (SVN head) accepts both vraiants at the receiver >side. > >Regards, >Werner > >> -----Ursprüngliche Nachricht----- >> Von: Alex Horwitz [mailto:[EMAIL PROTECTED] >> Gesendet: Montag, 23. Januar 2006 15:34 >> An: Dittmann, Werner; wss4j-dev@ws.apache.org >> Betreff: RE: X509Data in Encryption KeyInfo >> >> Thanks for the quick reply Werner. >> >> My point of reference was the x509 token profile 1.0 section >> 3.2.3, which prefers the x509 issuer/serial reference be >> wrapped in an <X509Data> element. I do see, however, that >> they disregard this guidance in 3.4 Encryption, and wss4j is >> consistent with this example. I do see that in the 1.1 spec >> http://www.oasis-open.org/committees/download.php/15253/oasis- >> wss-x509-token-profile-1.1.pdf it appears they've cleaned this up. >> >> Unfortunately, WebLogic 9.0 does generate and expect the >> <X509Data> element, and because of the ambiguity in the spec, >> I can't exactly open an SR against them for this. >> >> Ah well. >> >> -Alex >> >> >> -----Original Message----- >> From: Dittmann, Werner [mailto:[EMAIL PROTECTED] >> Sent: Monday, January 23, 2006 8:55 AM >> To: Alex Horwitz; wss4j-dev@ws.apache.org >> Subject: AW: X509Data in Encryption KeyInfo >> >> >> Alex, >> >> the X509Data element is a contaier that can hold several data >> types. Currently WSS4J support the IssuerSerial data inside >> a X509Data - other data elements / types are not defined by >> the WS Security specifications (V1.0 specs). >> >> Regards, >> Werner >> >> >> > -----Ursprüngliche Nachricht----- >> > Von: Alex Horwitz [mailto:[EMAIL PROTECTED] >> > Gesendet: Montag, 23. Januar 2006 14:44 >> > An: wss4j-dev@ws.apache.org >> > Betreff: X509Data in Encryption KeyInfo >> > >> > Hello All! >> > >> > This issue has come up before: >> > >> > http://mail-archives.apache.org/mod_mbox/ws-fx-dev/200409.mbox >> /%3c79D5F4B2D775204D9C7852EE41C5477303E9D459> >> @mchh2a1e.mchh.siemens.de%3e >> > >> > but, essentially, I'm testing interoperability between >> > WebLogic 9.0 and Axis1.2.1/WSS4J1.1, and my only roadblock is >> > the inability of WSS4J to consume/generate the X509Data >> > element in the EncryptedKey/KeyInfo/SecurityTokenReference/ . >> > Has anyone else encountered this problem? Or, more >> > modestly, is this a problem in my interpretation or did I >> > ignorantly miss a more recent follow-up that clarifies this issue. >> > >> > Thanks very much for you help. >> > >> > -Alex >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] DISCLAIMER: Information transmitted by this e-mail may be proprietary to Ramco Systems Ltd., and / or the authors of the information and is intended for use only by the individual or entity to which it is addressed, and may contain confidential or legally privileged information. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are not authorised to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. Ramco Systems Limited therefore does not accept liability for any errors, omissions, viruses or computer problems experienced as a result of this transmission. If you have received this e-mail in error, please notify us immediately at mail to: [EMAIL PROTECTED] and delete this mail from your records. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
