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