WS-AT XTS with .NET/WCF interop SSL problems

[bonio100]

Hi all,

I am having a spot of bother getting the XTS demo (theartre, taxi etc) working with a .NET/MSDTC client. The .NET client initiates the transaction.

We seem to establish the first ssl connection, but as soon as we send a response to MSDTC I get a 403 error.

Now I know that XTS doesnt support https yet but it 'might' work. Some seem to get further than I do.

We have swapped and imported our certificates. I still have a feeling this is down to certificate configuration - We are using self signed certificates and importing each others.

I am not in the office now but tomorrow I will post more details.

An exact description of the problem, bar the fact the .net side initiates the transaction:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=100138

Page related to the problem (half way down):
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1156107&SiteID=1

Has anyone managed to get this going? If I find a solution in the meantime I will post it back here.

Thanks

[adinn]

Now I know that XTS doesnt support https yet but it 'might' work. Some seem to get further than I do.

Err, not exactly. XTS works fine with https, just as well as it does with http. The only problems we have had reported were outside the scope of the XTS code in the HTTP transport layer.

The deal with 'support' is that XTS is not yet included as a part of the JBoss EAP platform for which support contracts are available. So, until AS 5.0 any help you get with XTS problems is on this forum, for free and best-effort.

That said, please continue trying to get this to work and I'll keep reading this thread in case I can contribute. However, currently it looks to me that the problem is to do with certificates, not the XTS code.

[bonio100]

Hi,

I managed to move beyond a 403 now to get a 400 at the same point. I moved past this by importing the certificates (mine/the ms clients) into the trust store rather than just the key store. I have also read that the MSDTC is very strict on what the certifcates shoud contain - I am going to try re-rolling a new certificate.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1842541&SiteID=1

Trouble is I can only find one page regarding this error on the whole internub.

Yes, I understand about the support issues, I apprieciate any small bits and the time people spend on this forum.

In the meantime this is the curent location of the problem.
9:53:08,341 INFO [STDOUT] http-137.223.83.28-8081-1, WRITE: TLSv1 Application Data, length = 345
09:53:08,341 INFO [STDOUT] http-137.223.83.28-8081-1, WRITE: TLSv1 Application Data, length = 1806
09:53:08,387 INFO [STDOUT] http-137.223.83.28-8081-1, READ: TLSv1 Application Data, length = 131
09:53:08,419 ERROR [STDERR] bookSeats: Participant enrolment failed
09:53:08,419 ERROR [STDERR] com.arjuna.wst.SystemException: Sender[[com.arjuna.webservices.transport.http.HttpClient_4] - Invalid response code returned: 400]
09:53:08,419 ERROR [STDERR] at com.arjuna.mwlabs.wst.at.remote.TransactionManagerImple.registerParticipant(TransactionManagerImple.java:215)
09:53:08,419 ERROR [STDERR] at com.arjuna.mwlabs.wst.at.remote.TransactionManagerImple.enlistForDurableTwoPhase(TransactionManagerImple.java:77)
09:53:08,419 ERROR [STDERR] at com.arjuna.xts.nightout.services.Restaurant.RestaurantServiceAT.bookSeats(RestaurantServiceAT.java:69)
09:53:08,419 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
09:53:08,419 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
09:53:08,419 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
09:53:08,419 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
09:53:08,419 ERROR [STDERR] at org.jboss.wsf.container.jboss42.DefaultInvocationHandler.invoke(DefaultInvocationHandler.java:102)
09:53:08,419 ERROR [STDERR] at org.jboss.wsf.container.jboss42.DefaultInvocationHandlerJAXRPC.invoke(DefaultInvocationHandlerJAXRPC.java:57)


Again if I solve this problem I will report back here.

[bonio100]

Well, we have just managed to get this working over SSL with all services working over https (using the tomcat ssl connector).

Main problems encountered were :
1) Getting configured certificates working. If not you would fail at handshaking stage 'pxix building failed' or would get a 403 error. You need to have on the java side a certificate (self signed is fine) which you have supplied to the MS client and they have trusted. In return you need their cert and to trust their CA cert (or the same if self signed). CA cert should be in your trust store and personal cert in your keystore. This is actually not that difficultas long as you trust each others certificates correctly.

2) Ensure the subject of your certificates are the same as your hostname and use hostnames throughout your addresses and not IP addresses.

We then arrived at 400 errors. As far as we can tell this means the certificate stuff is fine. This was down to a bug in a similar vein to :
http://mail-archives.apache.org/mod_mbox/ws-commons-dev/200610.mbox/%3c22157717.1160047582107.JavaMail.root@brutus%3e

Basically the MS DTC send messages with an address component which looks like:
Address xmlns='http://schemas.xmlsoap.org/ws/2004/08/addressing'>
https://full.hostname/WsatService/Registration/Coordinator/</Address

(Note I had to remove the open and closing bracket to get that to post right....)


The Java XTS sends messages around which look like this :
<wsa:Address xmlns:wsa='http://schemas.xmlsoap.org/ws/2004/08/addressing'>https://full.hostname:8081/xts/soap/RegistrationCoordinator</wsa:Address>


Essentially when XTS responds to the MS DTC the address was getting a bit mangled as it was storing the 'From' Endpoint reference for a later response:
<wsa:To xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing">https://full.hostname/WsatService/Registration/Coordinator/</wsa:To>

Note the xmlns:xmlns. It appears when an attribute is not qualified it uses the default xmlns namespace and then MSDTC doesnt like it. Hence we have to stop this prefixing of xmlns.

In order to get out prototype working, I performed the following code modification to WS-C.jar in SP7. This was just a temporary hack and not meant as a real fix! Modified bit in bold.


File ParsingSupport.java
protected final void parse(final XMLStreamReader in)
throws XMLStreamException
{
final int attributeCount = in.getAttributeCount() ;
for(int count = 0 ; count < attributeCount ; count++)
{
QName attributeName = in.getAttributeName(count) ;
final String attributeValue = in.getAttributeValue(count) ;

if (attributeValue.equals("http://schemas.xmlsoap.org/ws/2004/08/addressing") &&
attributeName.getLocalPart() == "xmlns")
{
attributeName = new QName("", "xmlns");
}

putAttribute(in, attributeName, attributeValue) ;
}

It probably wrong....But it works and there seems to have been a lot of others stumped on this problem with no real solutions.

Next step is to get databases involved.