OK, more news :
we manually updated the CRLs on our test RB, and job-list-match worked
(no more authentication pb).
So it seems that both CRLs Datagrid-fr AND CNRS-Projet (and maybe also
CNRS) have to be up to date... ??
files are :
/etc/grid-security/certificates/cf4ba8c8.* ->CA=CNRS
/etc/grid-security/certificates/34a509c3.* ->CA=CNRS-Projets
/etc/grid-security/certificates/6b4ddd18.* ->CA=Datagrid-fr
Could it be possible that two (or more) CRLs are checked for only one
certificate ??
It seems so (not sure about that) :
> more /etc/grid-security/certificates/34a509c3.signing_policy
# EACL French CA, project level: CNRS-Projets
access_id_CA X509 '/C=FR/O=CNRS/CN=CNRS-Projets'
pos_rights globus CA:sign
cond_subjects globus '"/C=FR/O=CNRS/CN=Datagrid-fr"
"/C=FR/O=CNRS/CN=CNRS-Projets"'
Regards,
Frederic Schaer
Frederic Schaer a écrit :
[log in to unmask]" type="cite">Hi I sent
an email yesterday about the French CRLs that expired (subject :
[LCG-ROLLOUT] CNRS / Datagrid-fr CRLs out of date... )
The CRLs file is now up-to-date, but it appeared today that the web
server fails answering all queries for this file, since every machine
on the grid seems to download all CRLs at the same time... so I guess
(and I'm not sure there is only one problem) that what happened is that
the RB did not succeed in downloading the new and valid CRL... :(
Some machines might have suceeded in downloading the good files, others
not...
This is a general problem about the cron jobs that are set up : with
the new (LCG 2.3 - SL3) release, it seems that the setup puts a file in
/etc/cron.d/ called edg-fetch-crl which contains the following :
56 3,9,15,21 * * * root /opt/edg/etc/cron/edg-fetch-crl-cron >>
/var/log/edg-fetch-crl-cron.log 2>&1
So, it would be great that the cron tab times are randomly set up when
installed ...
Regards,
Frederic
P.S : lxn1177 seem to be OK while lxn1188 fails. We have a test RB in
France which fails the same way as does lxn1188 but has the good
Datagrid-fr CRL (but the CNRS-Projets CRL still is wrong), so we're
trying to find what else could be wrong...
P.S : what could be done ? Hemmm... we could wait, or upgrade the CRL
web server (under investigation), or ask all RB/CE/SE/UI (WN?) admins
to manually upgrade the CRLs... or pray ? ;)
Emanouil Atanassov a écrit :
I can still not authenticate to the
lxn1188.cern.ch resource broker,
the default one on my UI.
I have a valid Datagrid-fr certificate, and I get
the following error:
edg-gridftp-ls -v gsiftp://lxn1188.cern.ch/
error the server sent an error response: 535 535-FTPD GSSAPI error: GSS
Major Status: Authentication Failed
535-FTPD GSSAPI error: GSS Minor Status Error Chain:
535-FTPD GSSAPI error:
535-FTPD GSSAPI error: accept_sec_context.c:170:
gss_accept_sec_context: SSLv3 handshake problems
535-FTPD GSSAPI error: globus_i_gsi_gss_utils.c:881:
globus_i_gsi_gss_handshake: Unable to verify remote side's credentials
535-FTPD GSSAPI error: globus_i_gsi_gss_utils.c:854:
globus_i_gsi_gss_handshake: SSLv3 handshake problems: Couldn't do ssl
handshake
535-FTPD GSSAPI error: OpenSSL Error: s3_srvr.c:1816: in library: SSL
routines, function SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
535-FTPD GSSAPI error: globus_gsi_callback.c:351:
globus_i_gsi_callback_handshake_callback: Could not verify credential
535-FTPD GSSAPI error: globus_gsi_callback.c:477:
globus_i_gsi_callback_cred_verify: Could not verify credential
535-FTPD GSSAPI error: globus_gsi_callback.c:769:
globus_i_gsi_callback_check_revoked: Invalid CRL: The available CRL has
expired
535 FTPD GSSAPI error: accepting context
error the server sent an error response: 535 535-FTPD GSSAPI error: GSS
Major Status: Authentication Failed
535-FTPD GSSAPI error: GSS Minor Status Error Chain:
535-FTPD GSSAPI error:
535-FTPD GSSAPI error: accept_sec_context.c:170:
gss_accept_sec_context: SSLv3 handshake problems
535-FTPD GSSAPI error: globus_i_gsi_gss_utils.c:881:
globus_i_gsi_gss_handshake: Unable to verify remote side's credentials
535-FTPD GSSAPI error: globus_i_gsi_gss_utils.c:854:
globus_i_gsi_gss_handshake: SSLv3 handshake problems: Couldn't do ssl
handshake
535-FTPD GSSAPI error: OpenSSL Error: s3_srvr.c:1816: in library: SSL
routines, function SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
535-FTPD GSSAPI error: globus_gsi_callback.c:351:
globus_i_gsi_callback_handshake_callback: Could not verify credential
535-FTPD GSSAPI error: globus_gsi_callback.c:477:
globus_i_gsi_callback_cred_verify: Could not verify credential
535-FTPD GSSAPI error: globus_gsi_callback.c:769:
globus_i_gsi_callback_check_revoked: Invalid CRL: The available CRL has
expired
535 FTPD GSSAPI error: accepting context
However, I can authenticate, submit jobs and retrieve output using
lxn1177.cern.ch.
I can see that users trying to submit jobs to our CE ce001.grid.bas.bg
from lxn1188.cern.ch, are having authentication problems too:
Notice: 6: Got connection 137.138.152.217 at Wed Jan 5 11:27:44 2005
Failed reading length 0
GSS authentication failure
globus_gss_assist token :3: read failure: Connection closed
Failure: GSS failed Major:01090000 Minor:00000000 Token:00000003
Failure: GSS failed Major:01090000 Minor:00000000 Token:00000003
I explicitly allowed access for 137.138.152.217 through our firewall,
and I manually updated the CRLs.
What can be done about these problems?
Thanks in advance,
Emanouil Atanassov
BG01-IPP site administrator
[log in to unmask]