Hello. I'm unsure of the exact problem so sorry if the topic is not all that descriptive to what follows: My setup is that I have a globus container running on a remote machine where I have a service deployed. The address to the server is: https://an.ip.address:8443/wsrf/services/project/TaskManagementService
and the security descriptor for the service looks like this: <securityConfig xmlns="http://www.globus.org";> <auth-method> <GSISecureConversation/> <GSISecureMessage/> <GSITransport/> </auth-method> <authz value="gridmap"/> <gridmap value="/etc/grid-security/grid-mapfile"/> </securityConfig> The grid-mapfile properly maps my distinguished name to a user account and the CA that signed my certificate is placed in a trusted CA directory. I have had services running in different containers communicating with each other without any problem so the certificate setup should be okay. The client uses the following client security descriptor: <securityConfig xmlns="http://www.globus.org";> <GSISecureConversation> <privacy/> <delegation value="full"/> </GSISecureConversation> <authz value="host"/> </securityConfig> Now, the host has a host certificate and on the machine the client is running I have placed the CA under $GLOBUS_LOCATION/share/certificates/. I only have Java WS Core on the client machine. The client is a Java project that uses the necessary jar files to be able to contact the service. This client does not run in a container; it's stand-alone. What happens is this: - client contacts service- handshaking and authentication of client commences- container prints an error message in the log and closes the connection- client gets an IOException. The container prints this error message: 2011-02-10 11:18:26,015 ERROR container.GSIServiceThread [ServiceThread-5,process:155] Error processing requestToken length 369098793 > 33554432.This could be caused by using the wrong protocol. Client might be using http, rather than https. However the client tries to connect using https (it's in the address, quadruple-checked). And I have verified that the HTTPSSender class is being loaded using a class load breakpoint. The stacktrace on the client looks like this: faultDetail: {http://xml.apache.org/axis/}stackTrace:java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at org.globus.gsi.gssapi.SSLUtil.read(SSLUtil.java:37) at org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readToken(GSIGssInputStream.java:64) at org.globus.gsi.gssapi.net.impl.GSIGssInputStream.readHandshakeToken(GSIGssInputStream.java:54) at org.globus.gsi.gssapi.net.impl.GSIGssSocket.readToken(GSIGssSocket.java:60) at org.globus.gsi.gssapi.net.GssSocket.authenticateClient(GssSocket.java:110) at org.globus.gsi.gssapi.net.GssSocket.startHandshake(GssSocket.java:140) at org.globus.gsi.gssapi.net.GssSocket.getOutputStream(GssSocket.java:161) at org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:433) at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:135) If I actually do change the client to try using http rather than https the container error becomes: 2011-02-10 11:50:46,907 ERROR container.GSIServiceThread [ServiceThread-5,process:155] Error processing requestToken length 1347375956 > 33554432.This could be caused by using the wrong protocol. Client might be using http, rather than https. so there is a difference in the requestToken length. I don't know what this requestToken length really is. I guess it has to do with the ssl handshaking. Can anything be deduced from the value of this requestToken? What are the common things to look for when having this issue?
