Hi,

we don't have the CRL file

[root@wn-03-03-21-a ~]# ls -la /etc/grid-security/certificates/8a047de1*
-rw-r--r--  1 root root 1367 Oct  9 10:25 /etc/grid-security/ 
certificates/8a047de1.0
-rw-r--r--  1 root root   50 Oct  9 10:25 /etc/grid-security/ 
certificates/8a047de1.crl_url
-rw-r--r--  1 root root  264 Oct  9 10:25 /etc/grid-security/ 
certificates/8a047de1.info
-rw-r--r--  1 root root  435 Oct  9 10:25 /etc/grid-security/ 
certificates/8a047de1.namespaces
-rw-r--r--  1 root root 1259 Oct  9 10:25 /etc/grid-security/ 
certificates/8a047de1.signing_policy


that's what happened  to  a CMS job

debug: authenticating with gsiftp://ce06-lcg.cr.cnaf.infn.it/home/ 
cmsprd013/.lcgjm/globus-cache-export.k20160/cache_export_dir.tar
debug: fault on connection to gsiftp://ce06-lcg.cr.cnaf.infn.it/home/ 
cmsprd013/.lcgjm/globus-cache-export.k20160/cache_export_dir.tar:  
globus_ftp_control: gss_init_sec_context failed
debug: data callback, error globus_ftp_control: gss_init_sec_context  
failed, buffer 0x403da008, length 0, offset=0, eof=true
debug: operation complete

error: globus_ftp_control: gss_init_sec_context failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Invalid CRL: The available CRL is not yet  
valid
Source: gsiftp://ce06-lcg.cr.cnaf.infn.it/home/cmsprd013/.lcgjm/ 
globus-cache-export.k20160/
Dest:   file:///home/cmsprd013/globus-tmp.wn-03-08-19-a.16822.0/ 
globus-tmp.wn-03-08-19-a.16822.1/
   cache_export_dir.tar

this is the user's subject

[root@wn-03-08-19-a ~]# cat /home/cmsprd013/subject8112281
/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=wguan/CN=667815/CN=Wen  
Guan/CN=proxy/CN=proxy/CN=limited proxy


maybe the problem is not related with NECTEC CRL but it is quite  
evident a CRL issue

Ale



On Nov 6, 2007, at 7:25 PM, Maarten Litmaath, CERN wrote:

> On Tue, 6 Nov 2007, David Groep wrote:
>
>> Hi Alessandro,
>>
>> This message is not critical in itself (it just indicates that you  
>> run
>> fetch-crl without the default warning suppress option "-a 24"). The
>> failure to download the NECTEC CRL does not in itself result in a
>> critical condition -- until the CRL expires.
>> And then your problems will be limited to interactions with users and
>> services associated with the NECTEC CA (i.e. those being in or  
>> originating
>> from Thailand).
>>
>> BTW: at the moment I can happily retrieve this CRL from the URL  
>> mentioned.
>
> Hi David,
> at CERN we have not been able to get a successful download of that CRL
> since Jun 25:
>
> ---------------------------------------------------------------------- 
> ---------
> [root@ce101 certificates]# ll 8a047de1.*
> -rw-r--r--    1 root     root         1367 Oct  9 10:25 8a047de1.0
> -rw-r--r--    1 root     root           50 Oct  9 10:25  
> 8a047de1.crl_url
> -rw-r--r--    1 root     root          264 Oct  9 10:25 8a047de1.info
> -rw-r--r--    1 root     root          435 Oct  9 10:25  
> 8a047de1.namespaces
> -rw-r--r--    1 root     root         2509 Jun 25 14:00 8a047de1.r0
> -rw-r--r--    1 root     root         1259 Oct  9 10:25  
> 8a047de1.signing_policy
> ---------------------------------------------------------------------- 
> ---------
>
> I did not investigate it further, since nobody complained and  
> various CAs
> have had such instabilities in the past...
> I can get the CRL in my _browser_, but wget fails:
>
> ---------------------------------------------------------------------- 
> ---------
> $ wget http://gridca.hpcc.nectec.or.th/pub/crl/cacrl.crl
> --19:23:53--  http://gridca.hpcc.nectec.or.th/pub/crl/cacrl.crl
>            => `cacrl.crl'
> Resolving gridca.hpcc.nectec.or.th... failed: Temporary failure in  
> name resolution.
> ---------------------------------------------------------------------- 
> ---------
>
>> Are you sure there are no other local network issues? The error  
>> messages
>> mentioned and the inability to run jobs are (should be) unrelated.
>>
>> 	Cheers,
>> 	DavidG.
>>
>> Italiano Alessandro wrote:
>>> we are encountering the following problem
>>>
>>> fetch-crl[9108]: 20071106T182248+0100 processing
>>> '/etc/grid-security/certificates/8a047de1.crl_url'
>>> fetch-crl[9108]: 20071106T182318+0100 RetrieveFileByURL: download no
>>> data from http://gridca.hpcc.nectec.or.th/pub/crl/cacrl.crl
>>> fetch-crl[9108]: 20071106T182318+0100 downloaded file from
>>> http://gridca.hpcc.nectec.or.th/pub/crl/cacrl.crl is not a valid  
>>> CRL file
>>> fetch-crl[9108]: 20071106T182318+0100 Could not download any CRL  
>>> from
>>> /etc/grid-security/certificates/8a047de1.crl_url:
>>> fetch-crl[9108]: 20071106T182318+0100 download failed from
>>> 'http://gridca.hpcc.nectec.or.th/pub/crl/cacrl.crl'
>>> fetch-crl[9108]: 20071106T182318+0100 download for
>>> http://gridca.hpcc.nectec.or.th/pub/crl/cacrl.crl is not valid  
>>> and none
>>> of the URLs in '/etc/grid-security/certificates/8a047de1.crl_url' is
>>> operational
>>>
>>>
>>> All the jobs via GRID are failing
>>>
>>> is it a common problem ???
>>>
>>> Alessandro Italiano
>>
>>
>>