Bug 892 - GET_HOST_CERT_FILENAME and X509_USER_CERT, X509_USER_KEY settings
: GET_HOST_CERT_FILENAME and X509_USER_CERT, X509_USER_KEY settings
Status: RESOLVED FIXED
: GSI C
Authentication
: 2.0
: PC Linux
: P2 question
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2003-04-16 09:12 by
Modified: 2008-08-11 15:16 (History)


Attachments
(161.20 KB, text/plain)
2003-05-30 07:05, Gerardo GANIS
Details
Small program reproducing the problem / patched globus_gsi_system_config.c (161.93 KB, text/plain)
2003-10-16 09:17, Gerardo GANIS
Details
Fixes bug that test prog shows (425 bytes, patch)
2003-10-23 17:27, Sam Meder
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-04-16 09:12:45
Hello,

  I am running GTK 2.2.3 on Linux RH7.3 (kernel 2.4.18-27.7.x.cern) and
  encountered the problem below and I would like to understand if it is
  due to misuse from my part or it is a feature. 
  I was not able to find anything related on your previous bug reports;
  also, looking at the relevant code in version 2.2.4 it does not seem
  that it should behave differently, but of course I could be wrong.

  I have recently (January) introduced in my application the possibility
  to authenticate to a remore server using Globus certificates. 
  Everything seemed to work fine until when I have decided to improve the
  flexibility of the service by allowing the user to choose on the fly the 
  relevant certificates. I have done this making use of the environment
  variables X509_USER_CERT and X509_USER_KEY. But then I've suddendly got
  unwanted features; if the two variables are both set, even to the their
  default values, ie

       setenv  X509_USER_CERT $HOME/.globus/usercert.pem
       setenv  X509_USER_KEY  $HOME/.globus/userkey.pem

  the program is unable to find valid proxies and requires always to 
  reinitialize them.

  Luckly enough I was able to reproduce the problem with my test standalone
  program, and digging a bit inside the called functions I have found the 
  place from where the problem originates: it is in the function

       globus_gsi_sysconfig_get_host_cert_filename_unix
  
  It seems that this function is always called, even if we are dealing with
  user certificates: this is not a problem by itself, since there is the way
  to distinguish between a good user and a good host certificate; but this 
  check is not performed if both X509_USER_CERT and X509_USER_KEY are defined 
  and point to valid cert and key PEM files.
  If I modify the logic of the function accordingly the problem disappears. 

  But I am not sure that this is what one has to do. My worry is that I am 
  doing something wrong in other places, though I am running out of ideas, 
  especially for my standalone program, which is very essential.

  I would appreciate very much your opinion.

  Thanks in advance.

  Gerardo Ganis  
  LCG/FZK
------- Comment #1 From 2003-05-29 18:50:28 -------
It is a sort of a feature. The page 

http://www.globus.org/security/config.html

describes how credentials are acquired (look for  Credential Acquisition Rules
towards the bottom of the page). The problem is that we have overloaded the
environment variables you are using so that they can be used for host/service
credential acquisition as well as user credential acquisition. And since the
host/service cert acquisition is tried before the proxy, your approach will run
into the problem you describe.

Given the above, is there any reason why you can't unset the variables before
acquiring the proxy?
------- Comment #2 From 2003-05-30 07:05:01 -------

  Dear Dr Meder, 

  Probably I did not explain myself properly.

  First, I try to answer to your question:

> is there any reason why you can't unset the variables before
> acquiring the proxy?
 
  The fact is that within my application I may need to access two or more 
  different remote accounts, and therefore to initialize different proxies 
  using certificates and private key files both located in a different 
  directory from the default one; the natural way to do this is (I believe) to 
  change the proxy, usercert and userkey files setting properly the X509_USER_PROXY,
  X509_USER_CERT and X509_USER_KEY variables. 

  Now, going back to the problem I have encountered, I am still convinced 
  that this is not a feature; at least there is some inconsistency, because 
  if you overload X509_USER_CERT only or X509_USER_KEY only everything works 
  fine, the problem appearing only when you overload both at the same time ...

  Let me go into details.

  The validity of the host cert and key files is done inside this conditional 
  scope (in function globus_gsi_sysconfig_get_host_cert_filename_unix, file 
  globus_gsi_system_config.c):


   ...

    /* now check installed location for host cert */
    if(!(*host_cert) || !(*host_key))
    {
        globus_location = getenv("GLOBUS_LOCATION");

        if(globus_location)
        {
            result = globus_i_gsi_sysconfig_create_cert_string(
                host_cert,
                & installed_host_cert,
                & status,
                "%s%s%s%s%s%s",
                globus_location,
                FILE_SEPERATOR,
                X509_INSTALLED_CERT_DIR,
                FILE_SEPERATOR,
                X509_HOST_PREFIX,
                X509_CERT_SUFFIX);
            if(result != GLOBUS_SUCCESS)
            {
                GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT(
                    result,
                    GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_CERT_STRING);
                goto done;
            }

            result = globus_i_gsi_sysconfig_create_key_string(
                host_key,
                & installed_host_key,
                & status,
                "%s%s%s%s%s%s",
                globus_location,
                FILE_SEPERATOR,
                X509_INSTALLED_CERT_DIR,
                FILE_SEPERATOR,
                X509_HOST_PREFIX,
                X509_KEY_SUFFIX);
            if(result != GLOBUS_SUCCESS)
            {
                GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT(
                    result,
                    GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING);
                goto done;
            }

            if((*host_cert) && !(*host_key))
            {
                GLOBUS_GSI_SYSCONFIG_ERROR_RESULT(
                    result,
                    GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING,
                    ("Host certificate is at: %s, but a host cert "
                     "coult not be found at: %s",
                     *host_cert, installed_host_key));
                free(*host_cert);
                goto done;
            }

            if((*host_key) && !(*host_cert))
            {
                GLOBUS_GSI_SYSCONFIG_ERROR_RESULT(
                    result,
                    GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING,
                    ("Host key is at: %s, but a host certificate "
                     "could not be found at: %s",
                     *host_key, installed_host_cert));
                free(*host_key);
                goto done;
            }
        }
    }

    ...


    The problem is that if both X509_USER_CERT and X509_USER_KEY are 
    overloaded, both *host_cert and *host_key will be != NULL and the 
    instructions within the scope will never be executed, while if 
    at least one of the two variables is not overloaded the validity checks
    are executed.

    In my patched version I have separated the validity checks like this:

    /* now check validity of files found (if any) */
    if( *host_cert )
    {
        result = globus_i_gsi_sysconfig_create_cert_string(
            host_cert,
            & default_host_cert,
            & status,
            "%s%s%s%s",
            X509_DEFAULT_CERT_DIR,
            FILE_SEPERATOR,
            X509_HOST_PREFIX,
            X509_CERT_SUFFIX);
        if(result != GLOBUS_SUCCESS)
        {
            GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT(
                result,
                GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_CERT_STRING);
            goto done;
        }
    }
    if( *host_key )
    {
        result = globus_i_gsi_sysconfig_create_key_string(
            host_key,
            & default_host_key,
            & status,
            "%s%s%s%s",
            X509_DEFAULT_CERT_DIR,
            FILE_SEPERATOR,
            X509_HOST_PREFIX,
            X509_KEY_SUFFIX);
        if(result != GLOBUS_SUCCESS)
        {
            GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT(
                result,
                GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING);
            goto done;
        }
    }        

     /* now check default locations for valid filenames */
    if(!(*host_cert) || !(*host_key))
    {
        if((*host_cert) && !(*host_key))
        {
            GLOBUS_GSI_SYSCONFIG_ERROR_RESULT(
                result,
                GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING,
                ("Host certificate is at: %s, but a host cert "
                 "coult not be found at: %s",
                 *host_cert, default_host_key));
            free(*host_cert);
            goto done;
        }
        
        if((*host_key) && !(*host_cert))
        {
            GLOBUS_GSI_SYSCONFIG_ERROR_RESULT(
                result,
                GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING,
                ("Host key is at: %s, but a host certificate "
                 "could not be found at: %s",
                 *host_key, default_host_cert));
            free(*host_key);
            goto done;
        }
    }

    This solves perfectly my problem (I can initiate proxies for all the 
    users I want without exiting my application) and I don't see which 
    bad side effect this could have on the rest. 

    I hope I have explained better myself this time.

    I attach my patched version of globus_gsi_system_config.c in case of need.

    With kind regards,

    Gerardo Ganis



On Thu, 29 May 2003 bugzilla-daemon@mcs.anl.gov wrote:

> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892
> 
> meder@mcs.anl.gov changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |ANSWERED
> 
> 
> 
> ------- Additional Comments From meder@mcs.anl.gov  2003-05-29 18:50 -------
> It is a sort of a feature. The page 
> 
> http://www.globus.org/security/config.html
> 
> describes how credentials are acquired (look for  Credential Acquisition Rules
> towards the bottom of the page). The problem is that we have overloaded the
> environment variables you are using so that they can be used for host/service
> credential acquisition as well as user credential acquisition. And since the
> host/service cert acquisition is tried before the proxy, your approach will run
> into the problem you describe.
> 
> Given the above, is there any reason why you can't unset the variables before
> acquiring the proxy?
> 
> 
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> 
------- Comment #3 From 2003-05-30 08:05:01 -------
On Fri, 30 May 2003, bugzilla-daemon@mcs.anl.gov wrote:

> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892
> 
> 
> 
> 
> 
> ------- Additional Comments From Gerardo.Ganis@cern.ch  2003-05-30 07:05 -------
> 
> 
>   Dear Dr Meder, 
> 
>   Probably I did not explain myself properly.
> 
>   First, I try to answer to your question:
> 
> > is there any reason why you can't unset the variables before
> > acquiring the proxy?
>  
>   The fact is that within my application I may need to access two or more 
>   different remote accounts, and therefore to initialize different proxies 
>   using certificates and private key files both located in a different 
>   directory from the default one; the natural way to do this is (I believe) to 
>   change the proxy, usercert and userkey files setting properly the X509_USER_PROXY,
>   X509_USER_CERT and X509_USER_KEY variables. 

Right, I still don't see the problem though. Why can't you do the following: 
 
setenv(X509_USER_CERT, "/first/usercert.pem", 1); 
setenv(X509_USER_KEY, "/first/userkey.pem", 1); 
 
load certificate/key 
 
unsetenv(X509_USER_CERT); 
unsetenv(X509_USER_KEY) 

create & load proxy

setenv(X509_USER_CERT, "/second/usercert.pem", 1);  
setenv(X509_USER_KEY, "/second/userkey.pem", 1);

load certificate/key 
 
unsetenv(X509_USER_CERT); 
unsetenv(X509_USER_KEY) 

create & load proxy

etc.

More comments below:

> 
>   Now, going back to the problem I have encountered, I am still convinced 
>   that this is not a feature; at least there is some inconsistency, because 
>   if you overload X509_USER_CERT only or X509_USER_KEY only everything works 
>   fine, the problem appearing only when you overload both at the same time ...
> 
>   Let me go into details.
> 
>   The validity of the host cert and key files is done inside this conditional 
>   scope (in function globus_gsi_sysconfig_get_host_cert_filename_unix, file 
>   globus_gsi_system_config.c):
> 
> 
>    ...
> 
>     /* now check installed location for host cert */
>     if(!(*host_cert) || !(*host_key))


Ok, this if statement is a little stupid (should really be something like
if(!(*host_cert) && !(*host_key))  (that's what it was changed to in 2.4).

>     {
>         globus_location = getenv("GLOBUS_LOCATION");
> 
>         if(globus_location)
>         {
>             result = globus_i_gsi_sysconfig_create_cert_string(
>                 host_cert,
>                 & installed_host_cert,
>                 & status,
>                 "%s%s%s%s%s%s",
>                 globus_location,
>                 FILE_SEPERATOR,
>                 X509_INSTALLED_CERT_DIR,
>                 FILE_SEPERATOR,
>                 X509_HOST_PREFIX,
>                 X509_CERT_SUFFIX);
>             if(result != GLOBUS_SUCCESS)
>             {
>                 GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT(
>                     result,
>                     GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_CERT_STRING);
>                 goto done;
>             }
> 
>             result = globus_i_gsi_sysconfig_create_key_string(
>                 host_key,
>                 & installed_host_key,
>                 & status,
>                 "%s%s%s%s%s%s",
>                 globus_location,
>                 FILE_SEPERATOR,
>                 X509_INSTALLED_CERT_DIR,
>                 FILE_SEPERATOR,
>                 X509_HOST_PREFIX,
>                 X509_KEY_SUFFIX);
>             if(result != GLOBUS_SUCCESS)
>             {
>                 GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT(
>                     result,
>                     GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING);
>                 goto done;
>             }
> 
>             if((*host_cert) && !(*host_key))
>             {
>                 GLOBUS_GSI_SYSCONFIG_ERROR_RESULT(
>                     result,
>                     GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING,
>                     ("Host certificate is at: %s, but a host cert "
>                      "coult not be found at: %s",
>                      *host_cert, installed_host_key));
>                 free(*host_cert);
>                 goto done;
>             }
> 
>             if((*host_key) && !(*host_cert))
>             {
>                 GLOBUS_GSI_SYSCONFIG_ERROR_RESULT(
>                     result,
>                     GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING,
>                     ("Host key is at: %s, but a host certificate "
>                      "could not be found at: %s",
>                      *host_key, installed_host_cert));
>                 free(*host_key);
>                 goto done;
>             }
>         }
>     }
> 
>     ...
> 
> 
>     The problem is that if both X509_USER_CERT and X509_USER_KEY are 
>     overloaded, both *host_cert and *host_key will be != NULL and the 
>     instructions within the scope will never be executed, while if 
>     at least one of the two variables is not overloaded the validity checks
>     are executed.
> 
>     In my patched version I have separated the validity checks like this:
> 
>     /* now check validity of files found (if any) */
>     if( *host_cert )

To be equivalent to the above this should be if( !*host_cert )

/Sam

>     {
>         result = globus_i_gsi_sysconfig_create_cert_string(
>             host_cert,
>             & default_host_cert,
>             & status,
>             "%s%s%s%s",
>             X509_DEFAULT_CERT_DIR,
>             FILE_SEPERATOR,
>             X509_HOST_PREFIX,
>             X509_CERT_SUFFIX);
>         if(result != GLOBUS_SUCCESS)
>         {
>             GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT(
>                 result,
>                 GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_CERT_STRING);
>             goto done;
>         }
>     }
>     if( *host_key )
>     {
>         result = globus_i_gsi_sysconfig_create_key_string(
>             host_key,
>             & default_host_key,
>             & status,
>             "%s%s%s%s",
>             X509_DEFAULT_CERT_DIR,
>             FILE_SEPERATOR,
>             X509_HOST_PREFIX,
>             X509_KEY_SUFFIX);
>         if(result != GLOBUS_SUCCESS)
>         {
>             GLOBUS_GSI_SYSCONFIG_ERROR_CHAIN_RESULT(
>                 result,
>                 GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING);
>             goto done;
>         }
>     }        
> 
>      /* now check default locations for valid filenames */
>     if(!(*host_cert) || !(*host_key))
>     {
>         if((*host_cert) && !(*host_key))
>         {
>             GLOBUS_GSI_SYSCONFIG_ERROR_RESULT(
>                 result,
>                 GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING,
>                 ("Host certificate is at: %s, but a host cert "
>                  "coult not be found at: %s",
>                  *host_cert, default_host_key));
>             free(*host_cert);
>             goto done;
>         }
>         
>         if((*host_key) && !(*host_cert))
>         {
>             GLOBUS_GSI_SYSCONFIG_ERROR_RESULT(
>                 result,
>                 GLOBUS_GSI_SYSCONFIG_ERROR_GETTING_KEY_STRING,
>                 ("Host key is at: %s, but a host certificate "
>                  "could not be found at: %s",
>                  *host_key, default_host_cert));
>             free(*host_key);
>             goto done;
>         }
>     }
> 
>     This solves perfectly my problem (I can initiate proxies for all the 
>     users I want without exiting my application) and I don't see which 
>     bad side effect this could have on the rest. 
> 
>     I hope I have explained better myself this time.
> 
>     I attach my patched version of globus_gsi_system_config.c in case of need.
> 
>     With kind regards,
> 
>     Gerardo Ganis
> 
> 
> 
> On Thu, 29 May 2003 bugzilla-daemon@mcs.anl.gov wrote:
> 
> > http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892
> > 
> > meder@mcs.anl.gov changed:
> > 
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >              Status|NEW                         |RESOLVED
> >          Resolution|                            |ANSWERED
> > 
> > 
> > 
> > ------- Additional Comments From meder@mcs.anl.gov  2003-05-29 18:50 -------
> > It is a sort of a feature. The page 
> > 
> > http://www.globus.org/security/config.html
> > 
> > describes how credentials are acquired (look for  Credential Acquisition Rules
> > towards the bottom of the page). The problem is that we have overloaded the
> > environment variables you are using so that they can be used for host/service
> > credential acquisition as well as user credential acquisition. And since the
> > host/service cert acquisition is tried before the proxy, your approach will run
> > into the problem you describe.
> > 
> > Given the above, is there any reason why you can't unset the variables before
> > acquiring the proxy?
> > 
> > 
> > 
> > ------- You are receiving this mail because: -------
> > You reported the bug, or are watching the reporter.
> > 
> 
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> 

------- Comment #4 From 2003-05-30 14:05:02 -------

  Hello,

  I may be totally wrong, but I don't believe the problem is solved with the 
  version:
  

On Fri, 30 May 2003 bugzilla-daemon@mcs.anl.gov wrote:

> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892
> 
> 
> Right, I still don't see the problem though. Why can't you do the following: 
>  
> setenv(X509_USER_CERT, "/first/usercert.pem", 1); 
> setenv(X509_USER_KEY, "/first/userkey.pem", 1); 
>  
> load certificate/key 
>  
> unsetenv(X509_USER_CERT); 
> unsetenv(X509_USER_KEY) 
> 
> create & load proxy
> 
> setenv(X509_USER_CERT, "/second/usercert.pem", 1);  
> setenv(X509_USER_KEY, "/second/userkey.pem", 1);
> 
> load certificate/key 
>  
> unsetenv(X509_USER_CERT); 
> unsetenv(X509_USER_KEY) 
> 
> create & load proxy
> 
> etc.

  That's exactly what I was doing but it does not work ...

> >     /* now check installed location for host cert */
> >     if(!(*host_cert) || !(*host_key))
> 
> 
> Ok, this if statement is a little stupid (should really be something like
> if(!(*host_cert) && !(*host_key))  (that's what it was changed to in 2.4).

  But this will not work either! I have just checked with version 2.4 ...

  Because the condition for this scope to be executed is that both 
  variables ( X509_USER_CERT and X509_USER_KEY ) are not overloaded! 

  If at least one of the two is overloaded (in the way you suggest above) 
  the validity test is not performed, the functions assumes that these 
  are *good host and key* files and then it fails ...

  The following may work:

  if( (*host_cert) || (*host_key) )

  but then you may have problems when one is of the two is not defined ...
  I have not checked. I think that performing separate checks is more natural 
  ...


> >     In my patched version I have separated the validity checks like this:
> > 
> >     /* now check validity of files found (if any) */
> >     if( *host_cert )
> 
> To be equivalent to the above this should be if( !*host_cert )

  I don't agree, because if you want to use the same variables for user and host
  certificates, in the function for host files you must check the validity 
  of the certificate when the variable is overloaded, that is when 
  *host_cert is TRUE ...
  The same holds for the key file.


  The patched version that I have sent to you may not be the most elegant, but 
  it works in all possible combinations. 
  The new version in 2.4 is not working at all, since it does not even allow 
  to change one of the two files ... Of course it works with defaults, when you 
  do not touch (overload) the two environment variables. 

  

  Gerardo Ganis 


------- Comment #5 From 2003-06-02 08:33:44 -------
Ok, I'll have to check into why my suggested solution is not working. Is the
scenario I describe exactly what you want to do btw? Can I ask what function you
are using to acquire credentials? gss_acquire_cred() or globus_gsi_cred_read()?

/Sam
------- Comment #6 From 2003-06-02 09:05:00 -------

On Mon, 2 Jun 2003 bugzilla-daemon@mcs.anl.gov wrote:

> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892
> 
> meder@mcs.anl.gov changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|ANSWERED                    |
> 
> 
> 
> ------- Additional Comments From meder@mcs.anl.gov  2003-06-02 08:33 -------
> Ok, I'll have to check into why my suggested solution is not working. 
> Is the scenario I describe exactly what you want to do btw? 
  Yes, I think you have understood what I would like to do and what you 
  propose is exactly what I have tried first following the documentation ...

> Can I ask what function you are using to acquire credentials? 
> gss_acquire_cred() or globus_gsi_cred_read()?

  I am calling 

              globus_gss_assist_acquire_cred

  as suggested in 

              http://www.globus.org/security/gss_assist.html


  Thanks for your reply.

  Gerardo



------- Comment #7 From 2003-10-16 09:17:29 -------
Created an attachment (id=223) [details]
Small program reproducing the problem / patched globus_gsi_system_config.c

As already stated, the problem mentioned in bug #892 is still present in 
GTK version 2.4.3 .
The atteched program testCred.c (compiled as shown in testCred.Mk) allows to
reproduce the problem. This is teh sequence of my actions and the corresponding
results:

  1) grid-proxy-init
Your identity:
/O=Grid/OU=GlobusTest/OU=simpleCA-arthux.cern.ch/OU=cern.ch/CN=ganis
globus_gsi_cred_read_key: enter: keyfile:/home/ganis/.globus/userkey.pem
Enter GRID pass phrase for this identity:
Creating proxy ................................ Done
Your proxy is valid until: Fri Oct 17 04:00:32 2003

   2) testCred
 GSS: acquiring host credentials ...

   3) Overload certificate and key files with defaults

      setenv X509_USER_KEY $HOME/.globus/userkey.pem
      setenv X509_USER_KEY $HOME/.globus/usercert.pem

   4) testCred
 GSS: acquiring host credentials ...
 gss_assist_acquire_cred host: Error
GSS Major Status: General failure
GSS Minor Status Error Chain:

acquire_cred.c:123: gss_acquire_cred: Error with GSI credential
globus_i_gsi_gss_utils.c:1308: globus_i_gsi_gss_cred_read: Error with gss
credential handle
globus_gsi_credential.c:490: globus_gsi_cred_read: Error reading host
credential
globus_gsi_credential.c:1109: globus_gsi_cred_read_key: Error reading user
credential: Can't read credential's private key from PEM 
OpenSSL Error: pem_lib.c:434: in library: PEM routines, function PEM_do_header:
bad password read
OpenSSL Error: pem_lib.c:666: in library: PEM routines, function PEM_read_bio:
no start line

   Unsetting any of the two environment variable the program works again as it
   should.

   I have included again a patched version of globus_gsi_system_config.c, which

   is however not different from the one already sent (attachment #129 [details]).

   Thanks for your attention.

   Gerardo Ganis
------- Comment #8 From 2003-10-23 17:27:56 -------
Created an attachment (id=225) [details]
Fixes bug that test prog shows
------- Comment #9 From 2003-10-23 17:30:18 -------
2.2.3 has a problem in the credential reading code where it does not clear the
openssl error before checking whether the key is password protected. This has
been  fixed in later versions. The patch that does so is attached. With this
patch your test program works fine. Let me know if you have anymore problems.

/Sam
------- Comment #10 From 2003-11-05 10:05:03 -------

  Hello,

  Sorry for the late reply.
  Yes, it works now.
  Thanks a lot for your help.

  Gerardo Ganis

-- 
+--------------------------------------------------------------------------+
  Gerardo GANIS    HIK  - ForschungZentrum Karlsruhe   
        address    CERN / EP-SFT , CH 1211 Geneve 23  
                   room: 32-RC-017, tel / fax: +412276 76439 / 79425
         e-mail    gerardo.ganis@cern.ch
+--------------------------------------------------------------------------+

On Thu, 23 Oct 2003 bugzilla-daemon@mcs.anl.gov wrote:

> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=892
> 
> meder@mcs.anl.gov changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|REOPENED                    |RESOLVED
>          Resolution|                            |FIXED
> 
> 
> 
> ------- Additional Comments From meder@mcs.anl.gov  2003-10-23 17:30 -------
> 2.2.3 has a problem in the credential reading code where it does not clear the
> openssl error before checking whether the key is password protected. This has
> been  fixed in later versions. The patch that does so is attached. With this
> patch your test program works fine. Let me know if you have anymore problems.
> 
> /Sam
> 
> 
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>