Re: [gt-user] Globus ³strict mode² coming March 2016 - Action Required

[Basney, Jim]

Hi,

Did this change happen as planned? Is the transition going OK for everyone?

In my role as CA operator, I know we've been issuing a lot of host certs
with multiple subjectAltNames in preparation for this transition, so
hopefully everyone has the certs they need.

-Jim

On 2/4/16, 5:21 PM, Stuart Martin wrote:
>Hi All,
>
>Here is a reminder about this deadline and upcoming change.
>
>Admins should check their host certificates and update them if necessary.
> Replace any incompatible certificates by Mar 1, 2016.
>
>To allow a bit of a buffer between the service-side certificate update
>deadline and clients beginning to use strict mode, updates will be made
>to the Globus Toolkit to default the client-side algorithm to strict mode
>on Tuesday, April 5, 2016.
>
>- The Globus Team
>
>> On Dec 1, 2015, at 2:50 PM, Stuart Martin  wrote:
>> 
>> Dear All,
>> 
>> Globus is planning to change the default client-side algorithm for
>>checking the server¹s identity used by GridFTP, MyProxy, GSI-OpenSSH,
>>and GRAM.  The new algorithm performs identity matching as described in
>>section 3.1 of RFC 2818
>>(https://tools.ietf.org/html/rfc2818#section-3.1), the standard
>>describing TLS use with HTTP.   This involves a change in the
>>globus-gssapi-gsi library, and will apply to any application that uses
>>the updated library.
>> 
>> The new ³strict mode² algorithm will be more strict in its enforcement,
>>checking that the server¹s certificate identity matches the hostname
>>that the client uses to contact the service.  Once clients are
>>configured for strict mode, client authentication (of any Globus
>>service) would fail if the service is using a certificate that does not
>>match the hostname that the client used to contact the service.
>> 
>> This change will bring our identity checking algorithm in line with RFC
>>2818, and will also close the door to reverse DNS lookup related attack
>>vectors. As an example of why relying on reverse DNS for making security
>>related decisions is not recommended, see this link:
>>https://cwe.mitre.org/data/definitions/350.html.
>> 
>> The Globus team has checked the host certificates used for a number of
>>GridFTP endpoints and found that many are _not_ RFC 2818 compatible.
>>These incompatible certificates will need to be replaced prior to
>>clients defaulting to the new strict mode algorithm.
>> 
>> We are reaching out to request that Globus service admins check their
>>host certificates and update them if necessary.  We are asking admins to
>>replace any incompatible certificates by Mar 1, 2016.  After March 1, we
>>will release updated Globus Toolkit components that will change the
>>default client authorization algorithm to strict mode.  At that time,
>>the Globus.org transfer service will also update its identity checking
>>algorithm.  This should ensure no service disruptions for the Globus
>>community.
>> 
>> Note: Globus Connect Server installations that use the Globus provided
>>certificate are not affected and do not have to make any changes to
>>their Globus Connect Server endpoint(s).
>> 
>> We have created a page where additional details about this change will
>>be communicated:
>>  https://docs.globus.org/security-bulletins/2015-12-strict-mode/
>> The above page includes common reasons for incompatibilities and how to
>>check for compatibility.
>> 
>> If you have any questions or concerns regarding this planned change,
>>please contact us at supp...@globus.org.
>> 
>> - The Globus team

Re: [gt-user] trust roots in Mac OS

[Basney, Jim]

OK sorry my guess didn't help. Maybe someone else on the list has another 
idea...

-Jim

On 1/26/16, 6:32 PM, José Luis Gordillo Ruiz wrote:
version 1.x on both of them:

Linux: $ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

MacOS: $ openssl version
OpenSSL 1.0.1i 6 Aug 2014


saludos,

José Luis Gordillo Ruiz
Coordinación de Supercómputo - DGTIC


On mar, ene 26, 2016 at 6:28 p.m., Basney, Jim 
mailto:jbas...@illinois.edu>> wrote:
Does one system have OpenSSL version 1.x and the other have OpenSSL version 
0.x? The hashes are different for the different OpenSSL versions. Some details 
at: 
http://www.cilogon.org/openssl1<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cilogon.org_openssl1&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=X-ngvEywj1r-yPTxcarA51KnpKNQOkBmvkP2StSnkJY&m=v0wghE3ea74IhF5BKwwOUAMTpTP41pMTw8r7chc7FWQ&s=8QYdbx2q3tg36922xVt3NeqYMPPCWgBzX0F9WoXlnXE&e=>

On 1/26/16, 6:21 PM, José Luis Gordillo Ruiz wrote:
Hi,

I’m trying to setup some globus clients on a Mac OS (el capitan).

Initially, I’ve nothing on /etc/grid-security/certificates nor 
.globus/certificates

$ myproxy-get-trustroots -s condor -v
MyProxy v6.1 Jan 2016 PAM OCSP
Attempting to connect to 132.248.83.81:7512
Successfully connected to condor:7512
Expecting non-standard server DN 
"/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx"
using trusted certificates directory /Users/jlgr/.globus/certificates
no valid credentials found -- performing anonymous authentication
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gss_assist: Error during context initialization
OpenSSL Error: 
/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_clnt.c:998:
 in library: SSL routines, function SSL3_GET_SERVER_CERTIFICATE: certificate 
verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Untrusted self-signed certificate in chain with hash 63167cb

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
———

so, I know I have to run it con ‘-b’ option. However, my concern is that when I 
run the same command on a Linux box (under the same circumstances, with the 
same user certificate) I got:

$ myproxy-get-trustroots -s condor -v
MyProxy v6.1 Dec 2015 PAM SASL KRB5 LDAP VOMS OCSP
Attempting to connect to 132.248.83.81:7512
Successfully connected to condor:7512
Expecting non-standard server DN 
"/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx"
using trusted certificates directory /home/staff/jlgr/.globus/certificates
no valid credentials found -- performing anonymous authentication
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gss_assist: Error during context initialization
OpenSSL Error: s3_clnt.c:1172: in library: SSL routines, function 
SSL3_GET_SERVER_CERTIFICATE: certificate verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Untrusted self-signed certificate in chain with hash a6589a6c

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
———

So, you can se that the ‘untrusted self-signed’ certificates have different 
hashes, but the request was made to the same my-proxy server

Why could be that?

My real concern is that I can’t run globus clientes (globus-ftp, globusrun, 
etc) from MacOS but I can from Linux (with same user certificate, same servers, 
etc). I’ve been tracking down differences bt the clients and I found this 
difference in setting trust roots.


saludos,

José Luis Gordillo Ruiz
Coordinación de Supercómputo - DGTIC

Re: [gt-user] trust roots in Mac OS

[Basney, Jim]

Does one system have OpenSSL version 1.x and the other have OpenSSL version 
0.x? The hashes are different for the different OpenSSL versions. Some details 
at: http://www.cilogon.org/openssl1

On 1/26/16, 6:21 PM, José Luis Gordillo Ruiz wrote:
Hi,

I’m trying to setup some globus clients on a Mac OS (el capitan).

Initially, I’ve nothing on /etc/grid-security/certificates nor 
.globus/certificates

$ myproxy-get-trustroots -s condor -v
MyProxy v6.1 Jan 2016 PAM OCSP
Attempting to connect to 132.248.83.81:7512
Successfully connected to condor:7512
Expecting non-standard server DN 
"/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx"
using trusted certificates directory /Users/jlgr/.globus/certificates
no valid credentials found -- performing anonymous authentication
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gss_assist: Error during context initialization
OpenSSL Error: 
/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_clnt.c:998:
 in library: SSL routines, function SSL3_GET_SERVER_CERTIFICATE: certificate 
verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Untrusted self-signed certificate in chain with hash 63167cb

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
———

so, I know I have to run it con ‘-b’ option. However, my concern is that when I 
run the same command on a Linux box (under the same circumstances, with the 
same user certificate) I got:

$ myproxy-get-trustroots -s condor -v
MyProxy v6.1 Dec 2015 PAM SASL KRB5 LDAP VOMS OCSP
Attempting to connect to 132.248.83.81:7512
Successfully connected to condor:7512
Expecting non-standard server DN 
"/O=Grid/OU=GlobusTest/OU=simpleCA-condor.super.unam.mx/CN=condor.super.unam.mx"
using trusted certificates directory /home/staff/jlgr/.globus/certificates
no valid credentials found -- performing anonymous authentication
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gss_assist: Error during context initialization
OpenSSL Error: s3_clnt.c:1172: in library: SSL routines, function 
SSL3_GET_SERVER_CERTIFICATE: certificate verify failed
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Untrusted self-signed certificate in chain with hash a6589a6c

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
———

So, you can se that the ‘untrusted self-signed’ certificates have different 
hashes, but the request was made to the same my-proxy server

Why could be that?

My real concern is that I can’t run globus clientes (globus-ftp, globusrun, 
etc) from MacOS but I can from Linux (with same user certificate, same servers, 
etc). I’ve been tracking down differences bt the clients and I found this 
difference in setting trust roots.


saludos,

José Luis Gordillo Ruiz
Coordinación de Supercómputo - DGTIC

[gt-user] GridFTP CEDPS Logging format

[Basney, Jim]

Hi,

I'm looking for a reference on the GridFTP logging format.
http://toolkit.globus.org/toolkit/docs/latest-stable/gridftp/admin/ points
to http://cedps.net/index.php/LoggingBestPractices for "more details on
the CEDPS Logging format" but that site seems to no longer be for the
Center for Enabling Distributed Petascale Science but is now for Computer
Experience and Development of Personal Skills which seems to be mostly
about links to VPN services.

Is there an updated GridFTP CEDPS Logging format reference I can use?

Thanks,
Jim

Re: [gt-user] gsisshd and X11 forwarding

[Basney, Jim]

Hi Matteo,

I suggest:

1. Check the server's debug output for any X11-related messages. (See
http://grid.ncsa.illinois.edu/ssh/ts_server.html for instructions.) You
may find an error related to xauth indicating that you need to pass a
./configure --with-xauth option when compiling from source.

2. Do you see the same problem using server binaries from Globus or do you
only see the problem when compiling the server from source?

3. Do you see the same problem using our latest GSI-OpenSSH pre-release
from https://github.com/globus/gsi-openssh/releases? Any help testing our
pre-release is much appreciated.

-Jim

On 1/25/16, 5:53 AM, Lanati, Matteo wrote:
>Hi all,
>
>I¹ve a gsissh server compiled from sources version 6.0.1433516164.
>In the config file of the daemon I set ŒX11Forwarding' to Œyes'.
>However, when I connect from my machine and I try to start a graphical
>application, I get the following error
>
>xterm Xt error: Can't open display:
>xterm:  DISPLAY is not set
>
>If I set the variable, (i.e., connecting via ssh and getting a display),
>things work as expected.
>The daemon is using the correct config file, since in the verbose output
>of the client I see
>
>X11 forwarding request accepted on channel 0
>
>while, if the X11Forwarding option were disabled, I¹d expect the message
>"X11 forwarding request failed on channel 0².
>The behaviour doesn¹t depend on the client platform, I tested it on OSX
>and on Debian (both Globus 6, precompiled from the official repository).
>Are there further suggestions?
>Thanks in advance,
>
>Matteo

Re: [gt-user] Problems with MyProxy and VOMS support

[Basney, Jim]

I agree. MyProxy offers 3 options for adding VOMS attributes to the
credential:

1. adding the VOMS attributes via myproxy-init by calling voms-proxy-init
2. adding the VOMS attributes via myproxy-server using the VOMS APIs
   (as requested by myproxy-logon -m)
3. adding the VOMS attributes via myproxy-logon by calling voms-proxy-init

If I understand correctly, the problem is that option #2 is not working in
GT 6.0, so myproxy-logon is trying option #3 as a fall-back, but we want
to get option #2 working again. Of the 3 options, only option #2 requires
linking with the VOMS libraries, because options #1 and #3 just call
voms-proxy-init. As Matteo explains, the nice thing about option #2 is it
doesn't require a client-side VOMS install.

I'm working on re-establishing my VOMS test environment so I can help
further with the diagnosis. Thanks Matteo for confirming that the problem
is with all GT 6.0 versions but not with GT 5.2.4 and GT 5.2.5. That
should help in finding the cause.

Regards,
Jim

On 6/24/15, 10:34 AM, gt-user-boun...@lists.globus.org on behalf of
Lanati, Matteo wrote:
>Hi Jan,
>
>I see your point (upload a VOMS enabled proxy, generated locally), but I
>want to store on MyProxy a plain proxy (without signature) and retrieve a
>credential with a VO extension. It's MyProxy that should contact the VOMS
>server to get the signature. The goal is to avoid to install (and
>configure) the VOMS utils on the client, since it is a tedious task.
>
>I think that when I do a "myproxy-logon -m esr", myproxy-logon realises
>that it received a proxy without the signature, then it tries to add it
>looking for voms-proxy-init, as a fallback. I want MyProxy to do the
>dirty work for me and for my users ;-) . It used to work on GT
>5.2.4/5.2.5. As explained by Jim in the previous mail, something changed
>in the meanwhile.
>
>All the best,
>
>Matteo
>
>
>
>> On 24 Jun 2015, at 17:11, Jan Just Keijser  wrote:
>> 
>> Hi,
>> 
>> the error is on the client side:
>> 
>> Enter MyProxy pass phrase:
>> failed to run voms-proxy-init: No such file or directory
>> A credential has been received for user Š
>> 
>> 
>> when you run
>> myproxy-logon -m esr
>> the myproxy-logon command tries to launch 'voms-proxy-init -voms esr
>>.' and it fails to find voms-proxy-init.
>> 
>> FWIW:
>> I've download globus_toolkit-6.0.1433516164, built myproxy with voms
>>support and launched a MyProxy server. It listed VOMS supported, and
>>indeed, when I upload a vomsified proxy to it the proxy is stored.
>>Delegated proxies (e.g. run 'myproxy-get-delegation' without listing a
>>voms server) included the VOMS info from the original upload.
>> 
>> 
>> cheers,
>> 
>> JJK / Jan Just Keijser
>> Nikhef
>> Amsterdam
>> 
>
>
>
>Matteo Lanati
>Distributed Resources Group
>Leibniz-Rechenzentrum (LRZ)
>Boltzmannstrasse 1
>85748  Garching b. München (Germany)
>Phone: +49 89 35831 8724

Re: [gt-user] Problems with MyProxy and VOMS support

[Basney, Jim]

Hi Matteo,

Sorry for the slow response. Unfortunately I don't have easy access to a
VOMS environment to try to reproduce the problem you've reported.

I think the "VOMS AC doesn't verify" message is not a symptom of the
problem. I think you should also see that message from your working GT
5.2.4 install. I think that debug message is always printed for proxies
stored in the MyProxy repository when adding VOMS attributes. Reviewing
the code, I'd expect to see some other error thrown by the myproxy-server
if it failed to insert the VOMS attributes.

There was some re-organization of the VOMS code in the MyProxy v6.1.6
release that may have introduced a bug, but that's just an unsubstantiated
suspicion on my part. I assume you're seeing this behavior with
globus_toolkit-6.0.1421093009.tar.gz from
http://toolkit.globus.org/ftppub/gt6/installers/src. It would be helpful
to know if the same problem occurs with the original GT 6.0 tarball
(globus_toolkit-6.0.tar.gz) from September 2014 before the MyProxy v6.1.6
updates.

I opened https://github.com/globus/globus-toolkit/issues/31 to track this
issue.

Regards,
Jim

On 6/19/15, 10:00 AM, Lanati, Matteo wrote:
>Hi all,
>
>I compiled MyProxy with VOMS support from the latest source tarball
>available, linking it against voms version 2.0.10 and openssl 1.0.1h.
>I think the result is fine:
>- if I do a $GLOBUS_LOCATION/sbin/myproxy-server -V I see "myproxy-server
>version MYPROXYv2 (v6.1 Jun 2015 PAM VOMS OCSP)², meaning that VOMS
>support is there
>- if I look at the executable, I see the dependency from libvomsapi,
>"libvomsapi.so.1 => /opt/voms/lib/libvomsapi.so.1².
>Unfortunately, when I try to retrieve a proxy that I uploaded earlier and
>ask MyProxy to sign it for me, it fails. The proxy is issued, but without
>the VO signature.
>On the client I do
>
>myproxy-logon -m esr
>
>and I see 
>
>Enter MyProxy pass phrase:
>failed to run voms-proxy-init: No such file or directory
>A credential has been received for user Š
>
>Of course I don¹t have voms-proxy-init on my client, that¹s the whole
>point of using MyProxy for this task.
>
>On the server side I see
>
>...
>Passphrase matches credentials, and PAM config is "sufficient";
>authentication succeeds without checking PAM.
>  Owner: matteo
>  Location: /var/myproxy_test/ ...
>  Max. delegation lifetime: 43200 seconds
>Sending OK response to client /C=...
>retrieving proxy
>Stored Credential is Proxy. VOMS AC doesn't verify.
>retrieving VOMS User Information.
>Retrieve esr VO
>Contact to VOMS Server: voms.grid.sara.nl
>Delegating credentials for /C=... lifetime=43200
>Sending OK response to client /C=...
>Client /C=... disconnected
>
>Is the message "Stored Credential is Proxy. VOMS AC doesn't verify² the
>symptom of a problem?
>In the config file I defined
>
>allow_voms_attribute_requests true
>voms_userconf /etc/vomses
>
>and it seems that my VO (esr) and the VOMS server have been identified.
>
>The whole setup used to work with GT 5.2.4 (compiled from scratch).
>Is there any suggestion?
>
>Best,
>
>Matteo
>
>
>
>
>Matteo Lanati
>Distributed Resources Group
>Leibniz-Rechenzentrum (LRZ)
>Boltzmannstrasse 1
>85748  Garching b. München (Germany)
>Phone: +49 89 35831 8724

Re: [gt-user] hostname in job contact string

[Basney, Jim]

Hi José,

My guess is that you want to set the GLOBUS_HOSTNAME environment variable [1] 
to the desired hostname when starting up the globus-gatekeeper, i.e., add 
"export GLOBUS_HOSTNAME=hostname" in your /etc/init.d/globus-gatekeeper script 
or "env = GLOBUS_HOSTNAME=hostname" in your /etc/xinetd.d/globus-gatekeeper 
file. According to [2] the globus-gatekeeper has honored the GLOBUS_HOSTNAME 
environment variable for a few years now.

-Jim

[1] http://toolkit.globus.org/toolkit/docs/latest-stable/ccommonlib/pi/
[2] https://globus.atlassian.net/browse/GRAM-134

On 7/30/14, 7:26 PM, j...@super.unam.mx wrote:
Hi,

I'm pretty sure this question has been answered in the past, but I couldn't 
find the answer

I have a GRAM service running on a "login-node" in a cluster. As usually 
happens, this node has two network interfaces.
I can successfully submit jobs  to the node, however, the contact string 
returned is built using the hostname of the internal network interface.

Is there a way to change that?

thank you in advance,


saludos,

José Luis Gordillo Ruiz
Coordinación de Supercómputo
UNAM

Re: [gt-user] myproxy-logon timed out

[Basney, Jim]

Do you have a myproxy-server running on tirex?

If you run 'telnet tirex 7512' do you see
'Connected to tirex" or 'Connection timed out'?

What do the myproxy-server logs contain?

On 7/13/14, 1:57 PM, ti-...@tiscali.it wrote:
>Hi,
>
>I've encountered the following error while attempting login:
>
>[quser@tirex ~]$ myproxy-logon -s tirex
>Unable to connect to 212.52.82.27:7512
>Unable to connect to tirex
>Connection timed out
>
>(Globus toolkit 5.2.5 on Fedora 19)
>
>Could someone help me to fix this?
>
>Thanks a lot.
>
>Tiziano Re

Re: [gt-user] gsissh error

[Basney, Jim]

Great! Looks like doing 'export GLOBUS_LOCATION' solved the problem.

-Jim

On 4/16/14, 3:18 PM, "Steven M Clark"  wrote:
>$ echo $GLOBUS_LOCATION
>/var/condor/Globus/globus-5.2.5
>$ $GLOBUS_LOCATION/setup/gsi_openssh_setup/setup-openssh -verbose
> 
>Set GLOBUS_LOCATION before running this script
>
>Interesting.
>
>$ export GLOBUS_LOCATION
>$ $GLOBUS_LOCATION/setup/gsi_openssh_setup/setup-openssh -verbose
>Configuring gsi_openssh
>
>Executing...
>Generating ssh host keys...
>Linking ssh host keys...
>/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_host_rsa_key already
>exists... skipping.
>/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_host_rsa_key.pub already
>exists... skipping.
>/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_host_dsa_key already
>exists... skipping.
>/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_host_dsa_key.pub already
>exists... skipping.
>Fixing paths in sshd_config...
>/var/condor/Globus/globus-5.2.5/etc/ssh/sshd_config already exists...
>skipping.
>Copying ssh_config and moduli to their proper location...
>/var/condor/Globus/globus-5.2.5/etc/ssh/ssh_config already exists...
>skipping.
>/var/condor/Globus/globus-5.2.5/etc/ssh/moduli already exists... skipping.
>/var/condor/Globus/globus-5.2.5/sbin/SXXsshd already exists... skipping.
>
>Notes:
>
>  o Privilege separation is off.
>  o GSI-OpenSSH website is .
>
>Finished configuring gsi_openssh.
>
>$ gsissh  
>usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
>   [-D [bind_address:]port] [-e escape_char] [-F configfile]
>   [-I pkcs11] [-i identity_file]
>   [-L [bind_address:]port:host:hostport]
>   [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p
>port]
>   [-R [bind_address:]port:host:hostport] [-S ctl_path]
>   [-W host:port] [-w local_tun[:remote_tun]]
>   [user@]hostname [command]
>
>
>---
>Steven Clark
>Application Engineer for Scientific Computing
>
>- Original Message -
>From: "Jim Basney" 
>To: "Steven M Clark" 
>Cc: "globus toolkit" 
>Sent: Wednesday, April 16, 2014 2:58:24 PM
>Subject: Re: [gt-user] gsissh error
>
>What is the output of running the following command?
>
>$GLOBUS_LOCATION/setup/gsi_openssh_setup/setup-openssh -verbose
>
>On 4/16/14, 2:48 PM, "Steven M Clark"  wrote:
>>Almost.  I have 
>>
>>   o Privilege separation is off.
>>
>>---
>>Steven Clark
>>Application Engineer for Scientific Computing
>>
>>- Original Message -
>>From: "Jim Basney" 
>>To: "Steven M Clark" 
>>Cc: "globus toolkit" 
>>Sent: Wednesday, April 16, 2014 2:32:29 PM
>>Subject: Re: [gt-user] gsissh error
>>
>>Steven,
>>
>>When you installed GT 5.2.5, did you see the following in the output?
>>
>>-
>>/var/condor/Globus/globus-5.2.5/sbin/gpt-postinstall
>>running 
>>/var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup/setup-openssh..[
>>Changing to /var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup ]
>>Configuring gsi_openssh
>>
>>Executing...
>>
>>Notes:
>>
>>  o Privilege separation is on.
>>  o GSI-OpenSSH website is .
>>
>>Finished configuring gsi_openssh.
>>-
>>
>>The setup-openssh script is what creates the needed
>>$GLOBUS_LOCATION/etc/ssh directory.
>>
>>-Jim
>>
>>On 4/16/14, 2:25 PM, "Steven M Clark"  wrote:
>>>After doing a basic gt5.2.5 installation from downloaded tarball the
>>>gsissh command fails.
>>>
>>> $ . globus-user-env.sh
>>> $  which gsissh
>>>   /var/condor/Globus/globus-5.2.5/bin/gsissh
>>> $ gsissh -help
>>>   /etc/gsissh not found.
>>>
>>>
>>>---
>>>Steven Clark
>>>Application Engineer for Scientific Computing

Re: [gt-user] gsissh error

[Basney, Jim]

What is the output of running the following command?

$GLOBUS_LOCATION/setup/gsi_openssh_setup/setup-openssh -verbose

On 4/16/14, 2:48 PM, "Steven M Clark"  wrote:
>Almost.  I have 
>
>   o Privilege separation is off.
>
>---
>Steven Clark
>Application Engineer for Scientific Computing
>
>- Original Message -
>From: "Jim Basney" 
>To: "Steven M Clark" 
>Cc: "globus toolkit" 
>Sent: Wednesday, April 16, 2014 2:32:29 PM
>Subject: Re: [gt-user] gsissh error
>
>Steven,
>
>When you installed GT 5.2.5, did you see the following in the output?
>
>-
>/var/condor/Globus/globus-5.2.5/sbin/gpt-postinstall
>running 
>/var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup/setup-openssh..[
>Changing to /var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup ]
>Configuring gsi_openssh
>
>Executing...
>
>Notes:
>
>  o Privilege separation is on.
>  o GSI-OpenSSH website is .
>
>Finished configuring gsi_openssh.
>-
>
>The setup-openssh script is what creates the needed
>$GLOBUS_LOCATION/etc/ssh directory.
>
>-Jim
>
>On 4/16/14, 2:25 PM, "Steven M Clark"  wrote:
>>After doing a basic gt5.2.5 installation from downloaded tarball the
>>gsissh command fails.
>>
>> $ . globus-user-env.sh
>> $  which gsissh
>>   /var/condor/Globus/globus-5.2.5/bin/gsissh
>> $ gsissh -help
>>   /etc/gsissh not found.
>>
>>
>>---
>>Steven Clark
>>Application Engineer for Scientific Computing

Re: [gt-user] gsissh error

[Basney, Jim]

Steven,

When you installed GT 5.2.5, did you see the following in the output?

-
/var/condor/Globus/globus-5.2.5/sbin/gpt-postinstall
running 
/var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup/setup-openssh..[
Changing to /var/condor/Globus/globus-5.2.5/setup/gsi_openssh_setup ]
Configuring gsi_openssh

Executing...

Notes:

  o Privilege separation is on.
  o GSI-OpenSSH website is .

Finished configuring gsi_openssh.
-

The setup-openssh script is what creates the needed
$GLOBUS_LOCATION/etc/ssh directory.

-Jim

On 4/16/14, 2:25 PM, "Steven M Clark"  wrote:
>After doing a basic gt5.2.5 installation from downloaded tarball the
>gsissh command fails.
>
> $ . globus-user-env.sh
> $  which gsissh
>   /var/condor/Globus/globus-5.2.5/bin/gsissh
> $ gsissh -help
>   /etc/gsissh not found.
>
>
>---
>Steven Clark
>Application Engineer for Scientific Computing

Re: [gt-user] MyProxy CA with LDAP

[Basney, Jim]

Hello Fabio,

Please try the following command as root on your MyProxy CA server:

pamtester myproxy fabio authenticate

You may need to first do 'yum install pamtester'.

This will determine if the problem is due to myproxy-server or pam_ldap. If you 
experience slow authentication and timeouts with pamtester, the problem is with 
the pam_ldap configuration or the Active Directory server.

-Jim

On 2/18/14, 6:54 AM, "Fabio Moreira" 
mailto:souza.fab...@gmail.com>> wrote:
Hi,

I have built a MyPoxy CA v5.9 server with authentication integrated with an 
Active Directory Server through PAM/LDAP to made the authentication of our grid 
environment. Although the certificate is issued, this authentication has been 
very slow with many time out before issuing the certificate. For instance:


Feb 18 09:26:39 globus myproxy-server[18245]: Connection from 10.0.0.1
Feb 18 09:26:39 globus myproxy-server[18245]: Authenticated client 
Feb 18 09:26:42 globus myproxy-server[18245]: Received GET request for username 
fabio
Feb 18 09:27:02 globus myproxy-server[18245]: pam_ldap: ldap_result Timed out
Feb 18 09:27:02 globus myproxy-server[18245]: pam_ldap: ldap_result Timed out
Feb 18 09:27:02 globus myproxy-server[18245]: pam_ldap: ldap_result Timed out
Feb 18 09:27:22 globus myproxy-server[18245]: PAM authentication succeeded for 
fabio
Feb 18 09:27:22 globus myproxy-server[18245]: Got a cert request for user 
"fabio", with pubkey hash "0x87696e4", and lifetime "43200"
Feb 18 09:27:22 globus myproxy-server[18245]: Issued certificate for user 
"fabio", with DN 
"/O=Grid/OU=Globus/OU=simpleCA-globus.mydomain.com/OU=local/GN=fabio/CN=FABIO
 MOREIRA DE SOUZA", lifetime "43200", and serial number "0x22"
Feb 18 09:27:22 globus myproxy-server[18245]: Client  disconnected


The server is a CentOS 6.5 with PAM configured into the file /etc/pam_ldap.conf 
as following:

host ldapcluster.mydomain.com
ldap_version 3
base dc=mydomain,dc=com
binddn CN=admin,OU=service account,OU=IT,DC=mydomain,DC=com
bindpw mypass
pam_filter objectclass=User
pam_login_attribute sAMAccountName
ssl no


and the openldap settings into the file /etc/openldap/ldap.conf:

TLS_REQCERT allow
TLS_CHECKPEER no


The configurations from /etc/myproxy-server.config are:

pam  "sufficient"
sasl "sufficient"
certificate_issuer_cert /home/globus/.globus/simpleCA/cacert.pem
certificate_issuer_key /home/globus/.globus/simpleCA/private/cakey.pem
certificate_issuer_key_passphrase "mypass"
certificate_serialfile /home/globus/.globus/simpleCA/serial
certificate_out_dir /home/globus/.globus/simpleCA/newcerts
certificate_mapfile /etc/grid-security/grid-mapfile
cert_dir /etc/grid-security/certificates
pam_id "myproxy"
certificate_mapapp /usr/local/sbin/myproxy-mapapp-ldap


and the file /etc/pam.d/myproxy:

auth required pam_ldap.so
account   required pam_ldap.so

I'd like to ask some help because sometimes this delay reaches more than 2 
minutes.

Best Regards,

Fabio Souza

Re: [gt-user] sudden client rejection

[Basney, Jim]

Karen,

Sorry, I can't explain it. I don't know why oa4mp would log that the
client has not been approved when the corresponding clientApprovals data
file contains "true". My only other idea is
to try restarting your oa4mp server, if you haven't tried that already.
Please submit a bug report at https://gateways.atlassian.net/browse/OAUTH
with full details (oa4mp version, config file, log file, clientApprovals
data file).

-Jim

On 7/19/13 2:03 PM, "Karen M. Fernsler"  wrote:
>Thanks again Jim, 
>
>Correct me if I'm misunderstanding, but in this case I think we're
>looking at the latter possibility (#2) if the client id in the
>error message 
>
>  a) matches the client id with (true) in
> the clientApprovals/dataPath file and
>  b) also matches the client id in the clients/dataPath file
>
>I have confirmed they all indeed match.
>
>I have opened a ticket with globusonline.
>
>-k
>
>On Fri, Jul 19, 2013 at 05:57:22PM +, Basney, Jim wrote:
>> Karen,
>> 
>> I don't know about the "Json parse unterminated string" message. I
>>suspect
>> that's coming from Globus Online, not oa4mp. Maybe you should submit a
>> request at https://support.globusonline.org/ about that.
>> 
>> Since you're using oa4mp's fileStore you can check for the Globus client
>> in your fileStore path. In the clientApprovals/dataPath subdirectory you
>> should see a file containing the oauth_consumer_key in question (i.e.,
>> matching the client identifier from the error message you quoted in your
>> original message) along with:
>> 
>> true
>> 
>> You should also see a file containing the same oauth_consumer_key in the
>> clients/dataPath subdirectory. They're just XML text files, so you can
>> grep/cat them.
>> 
>> It seems to me the only possibilities are either 1) something changed in
>> your fileStore path for the Globus client or 2) Globus Online is using a
>> different OAuth client identifier than it was before (i.e., different
>>from
>> what you approved). Hopefully matching the client identifier from the
>> error message to the oauth_consumer_key in clientApprovals/dataPath will
>> diagnose the problem.
>> 
>> -Jim
>> 
>> On 7/19/13 12:40 PM, "Karen M. Fernsler"  wrote:
>> >Hi Jim,
>> >
>> >Thanks for your response.
>> >
>> >We're using fileStore.
>> >
>> >In web.xml, oa4mp:server.config.file is pointing to the server
>> >config file that was fed to oa4mp-approver.jar in the attempt
>> >to re-approve.  This config file only has one config in it
>> >"myconfig".
>> >
>> >I was able to set up a test client and approve it with this setup.
>> >
>> >The globus client which is now "unapproved" was approved at one
>> >point and we were able to use it with the oauth server to do transfers
>> >with gridftp.
>> >
>> >One thing we have noticed -- at the point where globusonline tries to
>> >redirect the user to the oauth server for authentication we have
>> >seen a pink error box pop up briefly posting:
>> >"Json parse unterminated string" (it's a really brief pop up and it
>> >doesn't always display the text).
>> >
>> >thanks,
>> >-k
>> >
>> >On Fri, Jul 19, 2013 at 01:26:14AM +, Basney, Jim wrote:
>> >> Hi Karen,
>> >> 
>> >> My only guess is that your oa4mp server is configured to look in a
>> >> different store for your clients and clientApprovals than where you
>> >>wrote
>> >> the clientApprovals using oa4mp-approver.jar. What are the contents
>>of
>> >>the
>> >> OA4MP config file pointed to by the oa4mp:server.config.file property
>> >>and
>> >> is that the same config file you're using with oa4mp-approver.jar to
>> >> approve the client? Are you using mysql, postgresql, fileStore, or
>> >> memoryStore for clients and clientApprovals?
>> >> 
>> >> I'm Ccing Jeff Gaynor who may be able to provide additional
>>assistance.
>> >> 
>> >> Documentation references:
>> >> 
>> 
>>>>http://grid.ncsa.illinois.edu/myproxy/oauth/server/configuration/server
>>>>-c
>> >>on
>> >> figuration-file.xhtml
>> >> 
>>http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd.xhtml
>> >> 
>> 
>>>>http://grid.ncsa.il

Re: [gt-user] sudden client rejection

[Basney, Jim]

Karen,

I don't know about the "Json parse unterminated string" message. I suspect
that's coming from Globus Online, not oa4mp. Maybe you should submit a
request at https://support.globusonline.org/ about that.

Since you're using oa4mp's fileStore you can check for the Globus client
in your fileStore path. In the clientApprovals/dataPath subdirectory you
should see a file containing the oauth_consumer_key in question (i.e.,
matching the client identifier from the error message you quoted in your
original message) along with:

true

You should also see a file containing the same oauth_consumer_key in the
clients/dataPath subdirectory. They're just XML text files, so you can
grep/cat them.

It seems to me the only possibilities are either 1) something changed in
your fileStore path for the Globus client or 2) Globus Online is using a
different OAuth client identifier than it was before (i.e., different from
what you approved). Hopefully matching the client identifier from the
error message to the oauth_consumer_key in clientApprovals/dataPath will
diagnose the problem.

-Jim

On 7/19/13 12:40 PM, "Karen M. Fernsler"  wrote:
>Hi Jim,
>
>Thanks for your response.
>
>We're using fileStore.
>
>In web.xml, oa4mp:server.config.file is pointing to the server
>config file that was fed to oa4mp-approver.jar in the attempt
>to re-approve.  This config file only has one config in it
>"myconfig".
>
>I was able to set up a test client and approve it with this setup.
>
>The globus client which is now "unapproved" was approved at one
>point and we were able to use it with the oauth server to do transfers
>with gridftp.
>
>One thing we have noticed -- at the point where globusonline tries to
>redirect the user to the oauth server for authentication we have
>seen a pink error box pop up briefly posting:
>"Json parse unterminated string" (it's a really brief pop up and it
>doesn't always display the text).
>
>thanks,
>-k
>
>On Fri, Jul 19, 2013 at 01:26:14AM +, Basney, Jim wrote:
>> Hi Karen,
>> 
>> My only guess is that your oa4mp server is configured to look in a
>> different store for your clients and clientApprovals than where you
>>wrote
>> the clientApprovals using oa4mp-approver.jar. What are the contents of
>>the
>> OA4MP config file pointed to by the oa4mp:server.config.file property
>>and
>> is that the same config file you're using with oa4mp-approver.jar to
>> approve the client? Are you using mysql, postgresql, fileStore, or
>> memoryStore for clients and clientApprovals?
>> 
>> I'm Ccing Jeff Gaynor who may be able to provide additional assistance.
>> 
>> Documentation references:
>> 
>>http://grid.ncsa.illinois.edu/myproxy/oauth/server/configuration/server-c
>>on
>> figuration-file.xhtml
>> http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd.xhtml
>> 
>>http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd-content
>>-t
>> ags.xhtml
>> 
>>http://grid.ncsa.illinois.edu/myproxy/oauth/server/manuals/manually-appro
>>vi
>> ng-clients.xhtml
>> 
>> -Jim
>> 
>> On 7/18/13 8:12 PM, "Karen M. Fernsler"  wrote:
>> >Hi,
>> >
>> >A few weeks ago we approved globusonline as a client for use with our
>> >oauth server.
>> >
>> >Up until very recently it was working just fine, but suddenly the
>>server
>> >appears to be 
>> >claiming that the client isn't approved:
>> >
>> >Jul 18, 2013 6:04:35 PM
>>edu.uiuc.ncsa.security.core.util.MyLoggingFacade
>> >error
>> >SEVERE: oa4mp(Thu Jul 18 18:04:35 PDT 2013): INTERNAL ERROR: Error: The
>> >client with identifier "myproxy:oa4mp,2012:/client/[]" has not been
>> >approved. Request rejected. Please contact your administrator.
>> >Jul 18, 2013 6:04:35 PM
>>edu.uiuc.ncsa.security.core.util.MyLoggingFacade
>> >error
>> >SEVERE: oa4mp(Thu Jul 18 18:04:35 PDT 2013):
>> >edu.uiuc.ncsa.security.delegation.server.UnapprovedClientException:
>> >Error: The client with identifier "myproxy:oa4mp,2012:/client/[ ... ]"
>> >has not been approved. Request rejected. Please contact your
>>administrator
>> >
>> >
>> >Has anyone run into this before?
>> >Any ideas what to look for?
>> >
>> >We have tried re-approving the client to no avail.
>> >
>> >thanks,
>> >-k

Re: [gt-user] sudden client rejection

[Basney, Jim]

Hi Karen,

My only guess is that your oa4mp server is configured to look in a
different store for your clients and clientApprovals than where you wrote
the clientApprovals using oa4mp-approver.jar. What are the contents of the
OA4MP config file pointed to by the oa4mp:server.config.file property and
is that the same config file you're using with oa4mp-approver.jar to
approve the client? Are you using mysql, postgresql, fileStore, or
memoryStore for clients and clientApprovals?

I'm Ccing Jeff Gaynor who may be able to provide additional assistance.

Documentation references:
http://grid.ncsa.illinois.edu/myproxy/oauth/server/configuration/server-con
figuration-file.xhtml
http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd.xhtml
http://grid.ncsa.illinois.edu/myproxy/oauth/server/dtd/server-dtd-content-t
ags.xhtml
http://grid.ncsa.illinois.edu/myproxy/oauth/server/manuals/manually-approvi
ng-clients.xhtml

-Jim

On 7/18/13 8:12 PM, "Karen M. Fernsler"  wrote:
>Hi,
>
>A few weeks ago we approved globusonline as a client for use with our
>oauth server.
>
>Up until very recently it was working just fine, but suddenly the server
>appears to be 
>claiming that the client isn't approved:
>
>Jul 18, 2013 6:04:35 PM edu.uiuc.ncsa.security.core.util.MyLoggingFacade
>error
>SEVERE: oa4mp(Thu Jul 18 18:04:35 PDT 2013): INTERNAL ERROR: Error: The
>client with identifier "myproxy:oa4mp,2012:/client/[]" has not been
>approved. Request rejected. Please contact your administrator.
>Jul 18, 2013 6:04:35 PM edu.uiuc.ncsa.security.core.util.MyLoggingFacade
>error
>SEVERE: oa4mp(Thu Jul 18 18:04:35 PDT 2013):
>edu.uiuc.ncsa.security.delegation.server.UnapprovedClientException:
>Error: The client with identifier "myproxy:oa4mp,2012:/client/[ ... ]"
>has not been approved. Request rejected. Please contact your administrator
>
>
>Has anyone run into this before?
>Any ideas what to look for?
>
>We have tried re-approving the client to no avail.
>
>thanks,
>-k

Re: [gt-user] Old-style proxies support

[Basney, Jim]

I don't think this is an OpenSSL 1.0 problem. I see the same error with a fresh 
GT 5.0.4 install on MacOS 10.6.8 when using a legacy proxy:

$ openssl version
OpenSSL 0.9.8r 8 Feb 2011
$ grid-proxy-init -q
Enter GRID pass phrase:
$ globus-url-copy /tmp/one gsiftp://localhost/tmp/two
$ grid-proxy-init -q -old
Enter GRID pass phrase:
$ globus-url-copy /tmp/one gsiftp://localhost/tmp/two
error: globus_ftp_client: the server responded with an error
530 530-globus_xio: Authentication Error
530-OpenSSL Error: 
/SourceCache/OpenSSL098/OpenSSL098-35.1/src/ssl/s3_srvr.c:2602: in library: SSL 
routines, function SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
530-globus_gsi_callback_module: Could not verify credential
530-globus_gsi_callback_module: Can't get the local trusted CA certificate: 
Cannot find trusted CA certificate with hash 164e606c in 
/etc/grid-security/certificates
530 End.

I get the same error from MyProxy and GSI-OpenSSH when using legacy proxies, so 
it seems to be in the underlying GSI libraries.

On Dec 5, 2011, at 10:46 AM, Joseph Bester wrote:
> Could this be a different OpenSSL version (1.0 vs 0.9.x) requiring a 
> different CA hash? If so, 
> there's a tool in GT5 to work around that.
> 
> See http://www.globus.org/toolkit/docs/5.0/5.0.4/security/gsic/pi/#id2578254
> 
> Joe
> 
> On Dec 5, 2011, at 8:58 AM, Sebastian Czechowski wrote:
> 
>> Hello,
>> 
>> Does anyone has an answer to this one?
>> 
>> Regards,
>> Sebastian
>> 
>>  Original Message 
>> Subject: [gt-user] Old-style proxies support
>> Date:Mon, 14 Nov 2011 10:18:05 +0100
>> From:Sebastian Czechowski 
>> To:  gt-user@lists.globus.org 
>> 
>> 
>> 
>> Hello all,
>> 
>> Dennis van Dok from IGE Project has sent a the following question:
>> 
>> Will old-style proxies remain supported in current and upcoming Globus
>> products? Currently it seems that they aren't (see below).
>> 
>> 
>> There is a failure in the authentication layer of the client-server
>> interaction between a recent version of the globus client tools and a
>> recent version of the globus services, when using classic (globus) proxies.
>> 
>> Example: voms classic proxy, globus-url-copy from globus-gass-copy-5.7-1
>> on Ubuntu 11.04, with globus-gridftp-server-progs-3.28-3.el5 on CentOS 5.
>> 
>> $ voms-proxy-info -all
>> subject   : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok/CN=proxy
>> issuer: /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
>> identity  : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
>> type  : proxy
>> strength  : 1024 bits
>> path  : /user/dennisvd/ige-voms-proxy-classic
>> timeleft  : 11:47:33
>> === VO ige-project.eu extension information ===
>> VO: ige-project.eu
>> subject   : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
>> issuer:
>> /C=DE/O=GermanGrid/OU=TU-Dortmund/CN=host/vomrs01.grid.tu-dortmund.de
>> attribute : /ige-project.eu/Role=NULL/Capability=NULL
>> timeleft  : 11:47:33
>> uri   : vomrs01.grid.tu-dortmund.de:15011
>> 
>> $ globus-url-copy gsiftp://ve.nikhef.nl/etc/grid-security/grid-mapfile
>> `pwd`/
>> 
>> error: globus_ftp_client: the server responded with an error
>> 530 530-globus_xio: Authentication Error
>> 530-OpenSSL Error: s3_srvr.c:2518: in library: SSL routines, function
>> SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
>> 530-globus_gsi_callback_module: Could not verify credential
>> 530-globus_gsi_callback_module: Can't get the local trusted CA
>> certificate: Cannot find trusted CA certificate with hash 8d759796 in
>> /etc/grid-security/certificates
>> 530 End.
>> 
>> Copying the same proxy file to a machine with a gLite 3.2.8 installation
>> (globus-url-copy -version says globus-url-copy: 3.23) and repeating the
>> command works.
>> 
>> Initiating the voms proxy to use an RFC style proxy also works:
>> 
>> $ voms-proxy-init --bits 1024 --rfc --voms ige-project.eu
>> 
>> $ voms-proxy-info -all
>> subject   : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok/CN=122854297
>> issuer: /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
>> identity  : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
>> type  : RFC compliant proxy
>> strength  : 1024 bits
>> path  : /private/home/dennis/src/globustest/ige-voms-proxy-rfc
>> timeleft  : 11:43:07
>> === VO ige-project.eu extension information ===
>> VO: ige-project.eu
>> subject   : /O=dutchgrid/O=users/O=nikhef/CN=Dennis van Dok
>> issuer:
>> /C=DE/O=GermanGrid/OU=TU-Dortmund/CN=host/vomrs01.grid.tu-dortmund.de
>> attribute : /ige-project.eu/Role=NULL/Capability=NULL
>> timeleft  : 11:43:06
>> uri   : vomrs01.grid.tu-dortmund.de:15011
>> 
>> Best regards,
>> Sebastian Czechowski, IGE Project
>> 
>> -- 
>> Sebastian Czechowski   sebastian.czechow...@gridwisetech.com
>> IT Project Coordinator
>> GridwiseTechoffice/fax: +48 12 294 71 20
>> 
>> The Scalability Speciali

Re: [gt-user] auth problem in gt421

[Basney, Jim]

http://globus.org/toolkit/docs/4.2/4.2.1/security/gsic/admin/#id2533449

On Nov 22, 2011, at 11:44 AM,  wrote:
> I did a myproxy-init in a non-root session, but whit the myproxy service
> running in root session:
> 
> --
> www-data@cliente:/tmp$ myproxy-init -C cert.pem -y key.pem -l admin_ca
> --
> 
> this was the output:
> 
> -
> Your identity: "my subjectDN"
> 
> Creating proxy
>  Done
> Proxy Verify OK
> Your proxy is valid until: Fri Nov 25 13:16:35 2011
> Error authenticating: GSS Major Status: Authentication Failed
> GSS Minor Status Error Chain:
> globus_gss_assist: Error during context initialization
> globus_gsi_gssapi: Unable to verify remote side's credentials
> globus_gsi_gssapi: Unable to verify remote side's credentials: Couldn't
> verify the remote certificate
> OpenSSL Error: s3_pkt.c:1102: in library: SSL routines, function
> SSL3_READ_BYTES: sslv3 alert bad certificate SSL alert number 42
> 
> 
> whit the correspondent /var/log/syslog output:
> 
> --
> Nov 18 13:16:33 cliente myproxy-server[3699]: Connection from 127.0.1.1
> Nov 18 13:16:35 cliente myproxy-server[3699]: Error authenticating client:
> GSS Major Status: Authentication Failed GSS Minor Status Error Chain:
> globus_gsi_gssapi: SSLv3 handshake problems OpenSSL Error: s3_srvr.c:2602:
> in library: SSL routines, function SSL3_GET_CLIENT_CERTIFICATE: no
> certificate returned globus_gsi_callback_module: Could not verify
> credential globus_gsi_callback_module: Can't get the local trusted CA
> certificate: Cannot find trusted CA certificate with hash 52edec22 in
> /etc/grid-security/certificates
> Nov 18 13:16:35 cliente myproxy-server[3699]: Exiting: authentication failed
> 
> 
> why myproxy is creating a hash of the certificate from which I want to
> obtain a proxy certificate, and searching this hash in
> /etc/grid-security/certificates ?!