Print

Print



   Hi,

   Thanks for reporting these issues.
   I am fixing the error reports and the obvious bug for ca:0, self-signed CA.

   However, even without these fixes, I was not able to reproduce your start-up failure with a self-signed CA.
   You should get some additional verbosity by adding '-d:3' in the 'sec.protocol' directive. Does that give any
   hint? Can you post the full log you get in such a case?

   G. Ganis

On 6/28/12 2:35 PM, Иван Кадочников wrote:
[log in to unmask]" type="cite"> Hi all,

I'm trying to use sec.protocol gsi with the server certificate signed by a self-signed CA for testing purposes, however I'm having trouble getting the server to start.
3.1 hanged on some operation with XrdSutCache while starting, updating to 3.2.2 fixed the issue.

Now the server fails to start with the error "failed to initialized CRL for issuing CA" in XrdSecProtocolgsi::GetCA. Setting "crl:0" did not help. I did create an empty crl to see if it resolved it, but it seems the problem lies elsewhere.

I looked into the source and found the following.
In XrdSecProtocolgsi::GetCA neither "CRL is expired" nor "CRL is missing" messages are displayed in my case, but the return value is obviously 2 (because the CRL error is displayed). So the variable ok = 0. That probably means verified = 0.
This brings me to the first problem: shouldn't the message when CA verification fails be different from when CRL fails to initialize?

Looking into XrdSecProtocolgsi::VerifyCA, I found another problem: if CA is self-signed and CACheck = 0, CA is not checked, but the variable "verified" is never set either and remains 0. Which means when option ca:0 is used, self-signed CA is rejected outright. Is it the intended behavior?

I set ca:1, but nothing changed in the server output. Third problem: the certificate chain verification functions don't seem to produce any debugging output so I don't know what the actual problem with my CA certificate is.

I think I'll try using a certificate from a "real" CA instead. But I wanted to report these possible problems so that they can be resolved in the future versions.

Thanks.
 
Ivan Kadochnikov


Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1



-- 
+--------------------------------------------------------------------------+
  Gerardo GANIS    CERN, PH Dept, SFT group, CH 1211 Geneve 23  
                   room: 32-RC-017, tel: +41 22 7676439
                   email: [log in to unmask], fax: +41 22 7669133
+--------------------------------------------------------------------------+


Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1