Error
This error appears in the LFC/DPM log file.
07/28 10:08:22 18550,0 Cns_serv: Could not establish security context: _Csec_recv_token: Connection dropped by remote end !
Explanation
This warning only means that the LFC/DPM client dropped the connection itself.
Normally this should not be treated as an severe error as it may be related to the expired proxy, as seen in the server log file:
$ lfc-ls /
send2nsd: NS002 - send error : No valid credential found
/: Bad credentials
There were reports such an error could also appear due to malformed CA certificates.
In order to be sure it is good to set Globus environmental variables to debug certificates and Csec processing:
export GLOBUS_GSI_CERT_UTILS_DEBUG_LEVEL=5
export GLOBUS_GSSAPI_DEBUG_LEVEL=5
export CSEC_TRACE=1
If in the log we encounter flow familiar to this one:
...
globus_i_gsi_callback_check_signing_policy entering
globus_i_gsi_callback_check_gaa_auth entering
ca_policy_file_path is /etc/grid-security/certificates/c4435d12.signing_policy
oldgaa result: 1(0 yes, 1 no, -1 maybe)
print detailed answer:
ACCESS RIGHT
type : pos_rights
authority : globus
value : CA:sign
CONDITION
type : cond_subjects
authority : globus
value : "/C=CH/O=SWITCH - Teleinformatikdienste fuer Lehre und Forschung/CN=SWITCH Personal CA/Email=switch.personal.ca@switch.ch"
status : 00000001
globus_i_gsi_callback_error_result entering
...
That means we quite likely deal with malformed signing_policy file, used to apply ACLs based on the cond_subjects which are interpreted as regular expression filters.
In the example below CA with id '/C=US/O=Globus/CN=Globus Certification Authority' will grant
signed right to all certificates that match any of
cond_subjects.
# EACL entry #1|
access_id_CA X509 '/C=US/O=Globus/CN=Globus Certification Authority'
pos_rights globus CA:sign
cond_subjects globus '"/C=us/O=Globus/*" "/C=US/O=Globus/*""/O=Grid/O=Globus/*"'
# end of EACL
We experienced cases when
cond_subjects were not properly matching user certificates and the Globus logic was refusing to use certificates of such CAs, thus making impossible to connect.
Consider
malformed policy pattern (for a given user certificate - it is nothing wrong with it normally except it will never match users certificates DN as this CA was not coherent if it comes to
cond_subjects and DNs issued for users):
access_id_CA X509 '/CN=SWITCH CA/emailAddress=switch.ca@switch.ch/O=Switch - Teleinformatikdienste fuer Lehre und Forschung/C=CH'
pos_rights globus CA:sign
cond_subjects globus '"/CN=SWITCH Personal CA/emailAddress=switch.personal.ca@switch.ch/O=SWITCH - Teleinformatikdienste fuer Lehre und Forschung/C=CH"'
and compare it with the valid one in this case:
access_id_CA X509 '/CN=SWITCH CA/emailAddress=switch.ca@switch.ch/O=Switch - Teleinformatikdienste fuer Lehre und Forschung/C=CH'
pos_rights globus CA:sign
cond_subjects globus '"/C=CH/O=Switch - Teleinformatikdienste fuer Lehre und Forschung/CN=SWITCH Personal CA"'
The order of tokens in
cond_subjects is important - in this case newly issued policy file fixed the problem.
If the CA cannot help, one may try to fix signing_policy file by removing or amending offending
cond_subjects.
Help
For more information, contact
helpdesk@ggusNOSPAMPLEASE.org (remove the NONSPAM !) : your ROC will help you and contact the appropriate experts if needed.
--
SophieLemaitre - 28 Jul 2006