I think the Tomcat connector works ok but I don't think your test is quite
correct. First of all, not only Tomcat will use /etc/grid-security/certificates
by default. The globusrun-ws will try to use that, and the gt4 container
(separate from Tomcat connector) will use that by default. So your test must
isolate Tomcat experiments from everything else. I suggest having
/etc/grid-security/certificats directory, and than changing the Tomcat cacerdir
property to some empty directory. That should cause 'unknown CA' errors from
Tomcat or in Tomcat logs only. 

I double checked this and the cacertdir property works fine for Tomcat 4.1.x
and 5.0.x but did not exactly for Tomcat 5.5.x. It works ok for Tomcat 5.5.x if
the property is specified as 'cACertDir' instead of 'cacertdir'. Tomcat 5.5.x
seems to be touchy about the case.
I fixed up the code in cvs to accept the 'cacertdir' property in lowercase for
Tomcat 5.5.x.

I will try again tomorrow. We are running Tomcat 5.0.28

Sorry for taking so long to get back to you on this.

I took your advice and separate the client from the server to try to isolate
the problem. 

For the server, I have Tomcat 5.0.28 running on Fedora Core 3. The 'cacertdir'
attribute is set to '/home/pavlo/vdt-tomcat/globus/TRUSTED_CA' which contains
all the CA files. The default directory '/etc/grid-security/certificates/' does
not exist on this machine.

My client is running on a separate Fedora Core 4 machine. The default directory
'/etc/grid-security/certificates/' does exist on this machine.

This is what I have in my 'conf/server.xml' file for Tomcat:

      <!-- Globus Container Connector -->
      <Connector className="org.globus.tomcat.coyote.net.HTTPSConnector"
         port="9443"
         maxThreads="150"
         minSpareThreads="25"
         maxSpareThreads="75"
         autoFlush="true"
         disableUploadTimeout="true"
         scheme="https"
         enableLookups="true"
         acceptCount="10"
         debug="0"
         cert="/etc/grid-security/containercert.pem"
         key="/etc/grid-security/containerkey.pem"
         cacertdir="/home/pavlo/vdt-tomcat/globus/TRUSTED_CA"/>

Now when I execute the same test as before, I am still having problems:

CLIENT:

$ globusrun-ws -submit -F vdt-fc3-ia32.cs.wisc.edu:9443 -c /bin/date
Submitting job...Done.
Job ID: uuid:00af4d7a-debe-11da-b813-0030482e1f74
Termination time: 05/09/2006 18:10 GMT
<< HANG >>

SERVER:

INFO: Server startup in 13159 ms
May 8, 2006 1:11:02 PM
org.globus.wsrf.impl.security.authorization.ServiceAuthorizationChain authorize
INFO: Authorized "/DC=org/DC=doegrids/OU=People/CN=Andrew Pavlo 202950" to
invoke "{http://www.globus.org/namespaces/2004/10/gram/job}createManagedJob".
May 8, 2006 1:11:07 PM
org.globus.wsrf.impl.servicegroup.client.ServiceGroupRegistrationClient status
WARNING: Warning: Could not register
https://198.51.254.220:9443/wsrf/services/ManagedJobFactoryService to
servicegroup at https://198.51.254.220:9443/wsrf/services/DefaultIndexService
-- check the URL and that the remote service is up.  Remote exception was ;
nested exception is:
        org.globus.common.ChainedIOException: Authentication failed [Caused by:
Failure unspecified at GSS-API level [Caused by: Unknown CA]]
May 8, 2006 1:11:07 PM
org.globus.wsrf.impl.servicegroup.client.ServiceGroupRegistrationClient status
WARNING: Warning: Could not register
https://198.51.254.220:9443/wsrf/services/ManagedJobFactoryService to
servicegroup at https://198.51.254.220:9443/wsrf/services/DefaultIndexService
-- check the URL and that the remote service is up.  Remote exception was ;
nested exception is:
        org.globus.common.ChainedIOException: Authentication failed [Caused by:
Failure unspecified at GSS-API level [Caused by: Unknown CA]]
May 8, 2006 1:11:07 PM
org.globus.wsrf.impl.servicegroup.client.ServiceGroupRegistrationClient status
WARNING: Warning: Could not register
https://198.51.254.220:9443/wsrf/services/ReliableFileTransferFactoryService to
servicegroup at https://198.51.254.220:9443/wsrf/services/DefaultIndexService
-- check the URL and that the remote service is up.  Remote exception was ;
nested exception is:
        org.globus.common.ChainedIOException: Authentication failed [Caused by:
Failure unspecified at GSS-API level [Caused by: Unknown CA]]

Now if I create the symlink from '/etc/grid-security/certificates/' to
'/home/pavlo/vdt-tomcat/globus/TRUSTED_CA', everything works:

CLIENT:

$ globusrun-ws -submit -F vdt-fc3-ia32.cs.wisc.edu:9443 -c /bin/date
Submitting job...Done.
Job ID: uuid:799b80a0-debe-11da-8247-0030482e1f74
Termination time: 05/09/2006 18:14 GMT
Current job state: Active
Current job state: CleanUp
Current job state: Done
Destroying job...Done.

SERVER:

May 8, 2006 1:14:24 PM
org.globus.wsrf.impl.security.authorization.ServiceAuthorizationChain authorize
INFO: Authorized "/DC=org/DC=doegrids/OU=People/CN=Andrew Pavlo 202950" to
invoke "{http://www.globus.org/namespaces/2004/10/gram/job}createManagedJob".
May 8, 2006 1:14:28 PM
org.globus.wsrf.impl.security.authorization.ServiceAuthorizationChain authorize
INFO: Authorized "/DC=org/DC=doegrids/OU=People/CN=Andrew Pavlo 202950" to
invoke "{http://wsrf.globus.org/core/notification}destroy".
May 8, 2006 1:14:30 PM
org.globus.wsrf.impl.security.authorization.ServiceAuthorizationChain authorize
INFO: Authorized "/DC=org/DC=doegrids/OU=People/CN=Andrew Pavlo 202950" to
invoke "{http://www.globus.org/namespaces/2004/10/gram/job/exec}destroy".
May 8, 2006 1:14:36 PM org.globus.mds.index.impl.DefaultIndexService
processConfigFile
INFO: Reading default registration configuration from file:
/home/pavlo/vdt-tomcat/tomcat/v5/webapps/wsrf/WEB-INF/etc/globus_wsrf_mds_index/hierarchy.xml

So I think this might prove my original point that the server does not work
correctly if '/etc/grid-security/certificates/' does not exist. But since you
say it works as expected, could you please tell me what I am missing so I can
update the VDT?

The cacertdir paramter in the Tomcat connector control the CA certificates for
the connector only. It does not control the CA certificates for all GT
services. That's controlled by a container security descriptor. See security
documentation. Basically, the error you see on the server side or by hanging
client is not caused by misconfigured Tomcat connector but by misconfigured
service. 
Also, if you see your globusrun output, you actaully see that a job was
successfully submitted ("Submitting job...Done."). Therefore, some requests got
through. If you change the cacertdir parameter to some non-existient directory
you will not even see that much. 

Subject: Re:  Globus-WS in Tomcat Does Not Honor caCertDir
  Attribute


>The cacertdir paramter in the Tomcat connector control the CA certificates for
>the connector only. It does not control the CA certificates for all GT
>services. That's controlled by a container security descriptor. See security
>documentation.

I looked in the "Writing server-side security descriptor files", and 
it didn't say anything about setting the trusted CA directory. Can 
you point us more directly?

http://www.globus.org/toolkit/docs/4.0/security/authzframe/security_descriptor.html#s-authzframe-server-secdesc-descFile

Thanks,
-alain

Apparently the ability to set CA cert dirs from the container security
descriptor is a trunk-only feature, which is why you can't find it in the 4.0
authzframework documents.  Instead, you can set a cacert value in the tomcat
container owner's cog.properties file, or possibly just have X509_CERT_DIR set
in the environment.