Here some information on Globus troubleshooting
Check also 
ReplicaCheckCE
  x509 certificates 
There are 3 versions of certificates: old, GT3 (RFC draft) and 
RFC 3820
You can see more about differences and which versions are available and default in different Globus versions in 
http://dev.globus.org/wiki/Security/ProxyCertTypes
OSG 1.2 uses GT 4.0 that even if it supports RFC proxies, it defaults to GT3 ones. GT3 proxies are little tested and in some cases the support may even be 
almost dropped.
In commands like 
voms-proxy-init the version of the proxy may affect the communication with the VOMS server depending on its version. ATLAS has 3 servers (2 at CERN and one at BNL) so the error may seem intermittent depending on the server contacted. 
voms-proxy-init -quiet -voms atlas:/atlas -vomses /osg/mwt2/app/atlas_app/local/vomses -key $X509_USER_PROXY -cert $X509_USER_PROXY -out $XrdSecGSIUSERPROXY -limited -noregen
has been reported to fail if the 
-noregen is not included
-noregen should only tell to voms-proxy-init to use the created proxy instead of using the certificate and key but its behavior is not clear when -cert and -key are in the command line. Doing 
some tests: 
-  old proxy (ver2) and RFC proxy seem to work always fine with and without -noregen
  -  GT3 proxy (default in OSG 1.2) works only with -noregen, otherwise fails at CERN (Error: Could not establish authenticated connection with the server. globus_gss_assist token :-1: read failure: Operation not permitted) and hangs at BNL
 
 
It is not clear why -noregen affects the behavior. Note that the error goes away in OSG 3 installations, using GT5 that by default uses RFC proxies
tmp_x509up_u20003_23271 is an example problematic proxy failing at the VOMS servers.
  CA Certificates 
The Globus tools will trust certificates issued by a CA if (and only if) it can find information about the CA in the trusted certificates directory.
The trusted certificates directory is located as described below and exists either on a per-machine or on a per-installation basis.
X509_CERT_DIR is the environment variable used to specify the path to the trusted certificates directory. This directory contains information about which CAs are trusted (including the CA certificates themselves) and, in some cases, configuration information used by grid-cert-request to formulate certificate requests. The location of the trusted certificates directory is looked for in the following order:
 
-  value of the X509_CERT_DIR environment variable
  -  $HOME/.globus/certificates
  -  /etc/grid-security/certificates exists
  -  $GLOBUS_LOCATION/share/certificates
 
 
Doc source: 
http://www.globus.org/toolkit/docs/4.2/4.2.1/security/gsic/pi/#id2554930
From the source file of globus_gsi_sysconfig_get_cert_dir (in 
globus_gsi_system_config.c): Get the Trusted Certificate Directory containing the trusted Certificate Authority certificates.  This directory is determined in the order shown below.  Failure in one method results in attempting the next.
On UNIX: 
-  X509_CERT_DIR environment variable - if this is set, the trusted certificates will be searched for in that directory.  This variable allows the end user to specify the location of trusted certificates.
  -  $HOME/.globus/certificates - If this directory exists, and the previous methods of determining the trusted certs directory failed, this directory will be used.  
  -  /etc/grid-security/certificates - This location is intended to be independent of the globus installation ($GLOBUS_LOCATION), and  is generally only writeable by the host system administrator.  
  -  $GLOBUS_LOCATION/share/certificates
 
 
On Windows  
-  X509_CERT_DIR environment variable - if this is set, the trusted certificates will be searched for in that directory.  This variable allows the end user to specify the location of trusted certificates.
  -  x509_cert_dir registry key - If this registry key is set on windows, the directory it points to should contain the trusted certificates.  The path to the registry key is 
software\\Globus\\GSI
  -  \\<user home directory>\\.globus\\certificates - If this directory exists, and the previous methods of determining the trusted certs directory failed, this directory will be used.  
  -  Host Trusted Cert Dir - This location is intended to be independent of the globus installation ($GLOBUS_LOCATION), and is generally only writeable by the host system administrator.  
  -  Globus Install Trusted Cert Dir - this is 
$GLOBUS_LOCATION\\share\\certificates.  
 
 
Globus 4.2 has grid-cert-diagnostics (not in VDT 2.0):
http://www.globus.org/toolkit/docs/4.2/4.2.0/security/gsic/user/grid-cert-diagnostics.html
Some other documents: 
 
  Updating manually CA certificates and CRLs 
vdt-ca-manage fetchCRL works only if it is in the cron as well (else it is refusing to run)
vdt-control --enable fetch-crl
vdt-control --on fetch-crl
vdt-ca-manage fetchCRL
Alternatively you can go to the directory and run manually: cd into it and run 
$VDT_LOCATION/fetch-crl/sbin/fetch-crl
To update the CA certs and check the status:
vdt-update-certs
vdt-ca-certs-status
  Host certificates 
Note  that: 
-  host certificate must be owned by root
  -  permission must be 444 on the certificate, 400 on the key (nothing different)
 
 
Failure to complain will give sometime misleading errors on the clients trying to connect
  Time synchronization 
Synchronization is essential for security
ntpd -q -g
or
ntpd -q -g -x
ntpq -p
less /etc/ntp.conf 
man ntpdate
man ntpd 
ntpd -q
date
/etc/init.d/ntpd start
chkconfig 
chkconfig --list ntpd
chkconfig --add ntpd
chkconfig --list ntpd
chkconfig --level 3,5 ntpd on
chkconfig --level 3 5 ntpd on
chkconfig --level 35 ntpd on
chkconfig --list ntpd
cat /etc/resolv.conf 
less /etc/ntp.conf 
date
-- 
MarcoMambelli - 01 Apr 2010