Jim, Mike, thank you for your help. Effectively, using globes-update-certificate-dir with -subject_hash_old solve the hashes issue, and also I’m now able to use clients from Mac OS El Capitan.
saludos, José Luis Gordillo Ruiz Coordinación de Supercómputo - DGTIC On mar, ene 26, 2016 at 7:59 p.m., Michael Link <ml...@mcs.anl.gov> wrote: Jim's guess was right, though it isn't readily apparent. We build the Mac GT binaries to the 10.6 SDK, which includes openssl 0.9.8. (You can see in the error that it's not using El Capitan's standard version: /BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59/src/ssl/s3_clnt.c:998). You can find the correct hashes with the commands: openssl x509 -in <file> -noout -hash openssl x509 -in <file> -noout -subject_hash_old The Mac GT tools will need the -subject_hash_old names. There is a tool in the package, globus-update-certificate-dir, that will add symlinks of your certs with the correct hash name. In this case you'll want to edit it and modify the openssl command to use -subject_hash_old instead of -hash. Mike On 1/26/2016 6:40 PM, Basney, Jim wrote: > 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 <jbas...@illinois.edu > <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 >
