National Center for Supercomputing Applications MyProxy Credential Management Service University of Illinois at Urbana-Champaign

[Valid HTML 4.01]
[Valid CSS]
[Valid Atom 1.0]

(OSI Certified)

Trust roots are the configured set of entities that form the basis of trust in the security system and are used for bootstrapping trust relationships with other entities in the system. In the Grid Security Infrastructure (GSI), trust roots include Certificate Authorities (CAs), which are responsible for binding names to public keys in signed certificates, enabling secure (authenticated, private) communication between named parties. CAs are responsible for certifying both people and services, and the set of trusted CAs determines which certificates for those people and services can be trusted. In practice, it is necessary to trust the CAs that certify the people and services you communicate with. As CAs and their configurations can change over time, it is necessary to actively manage the trust root configuration.

MyProxy includes a basic mechanism for managing the trust root configuration in the Globus trusted CA directory located by the X509_CERT_DIR environment variable or found in $HOME/.globus/certificates, /etc/grid-security/certificates, or $GLOBUS_LOCATION/share/certificates. Globus software will use the first directory found in this search list. MyProxy server administrators can maintain a trust root configuration on behalf of their users, which users can install and update via myproxy-get-trustroots or the myproxy-logon -T option. The Java MyProxyLogon client also supports trust root management.

For an example of using this capability on the TeraGrid, see Single Sign-on with MyProxy and GSISSH on TeraGrid.

Contents

Considerations for Server Administrators

Prior to MyProxy v5.4 (22 Apr 2011), the myproxy-server would by default send the trust root configuration it was currently using (i.e., the contents of $X509_CERT_DIR, $HOME/.globus/certificates, /etc/grid-security/certificates, or $GLOBUS_LOCATION/share/certificates) to clients that request trust roots. In MyProxy v5.4 and later, the myproxy-server no longer sends trust roots by default, so administrators must set the cert_dir option in the myproxy-server.config file to enable this capability.

Starting with v2.0, the myproxy-server can be configured to send trust roots to clients that request it. The myproxy-server administrator can set the cert_dir option in the myproxy-server.config file to specify a trust root directory to send to clients. Server administrators should ensure that all files in this directory are world-readable, because the the myproxy-server will not send read-protected files to clients (as a protective measure). Server administrators should keep the directory up-to-date, via automated mechanisms such as the gx-map gx-ca-update command or the VDT certificate authority packages and the Fetch CRL utility.

For information about configuring a myproxy-server to send trust roots for both OpenSSL 0.x and 1.x clients, see http://www.cilogon.org/openssl1.

It is particularly important that the directory not include expired CRL files, as that will cause all certificates from the associated CA to be untrusted. Administrators will need to compare the added security of CRLs with their potential to cause problems when they expire. To avoid the problems of expired CRLs, administrators may decide not to include them.

Support for the myproxy-get-trustroots command was added starting in v4.6 of the myproxy-server.

Considerations for Client Users

To use MyProxy to keep your trust roots up-to-date, run myproxy-get-trustroots or myproxy-logon -T periodically. MyProxy will download CA certificates, CRLs, signing policy files, and any other configuration data to the directory specified by the X509_CERT_DIR environment variable or to $HOME/.globus/certificates (when running as non-root) or /etc/grid-security/certificates (when running as root) if X509_CERT_DIR is not defined. For example:

$ myproxy-logon -T -l username
Enter MyProxy pass phrase:
A credential has been received for user username in /tmp/x509up_u25555.
Trust roots have been installed in /home/username/.globus/certificates/.
$ myproxy-get-trustroots
Trust roots have been installed in
/home/username/.globus/certificates/.

If you have no trust roots installed, the MyProxy commands (v3.9 and later) will "bootstrap" your trust root configuration based on the MyProxy server's certificate. For example:

$ myproxy-logon -T -l username
Bootstrapping MyProxy server root of trust.
Enter MyProxy pass phrase:
A credential has been received for user username in /tmp/x509up_u25555.
Trust roots have been installed in /home/username/.globus/certificates/.
$ myproxy-get-trustroots
Bootstrapping MyProxy server root of trust.
Trust roots have been installed in
/home/username/.globus/certificates/.

If you have trust roots installed, but the CA that signed the myproxy-server's certificate is not trusted, the myproxy-logon or myproxy-get-trustroots commands will fail with an error:

$ myproxy-logon -T
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain: globus_gss_assist: Error during context initialization
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 9b95bbf2

The CA that signed the myproxy-server's certificate is untrusted.
If you want to trust the CA, re-run with the -b option.
$ myproxy-get-trustroots
Error authenticating: GSS Major Status: Authentication Failed
GSS Minor Status Error Chain: globus_gss_assist: Error during context initialization
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 9b95bbf2

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

In this case, you can use the -b option (in MyProxy 5.0 and later) to bootstrap trust in the myproxy-server's certificate:

$ myproxy-logon -b
Bootstrapping MyProxy server root of trust.
Enter MyProxy pass phrase:
A credential has been received for user username in /tmp/x509up_u501.
Trust roots have been installed in /home/username/.globus/certificates/.
$ myproxy-get-trustroots -b
Bootstrapping MyProxy server root of trust.
Trust roots have been installed in /home/username/.globus/certificates/.

If your system administrator is already keeping an up-to-date trust root directory in /etc/grid-security/certificates on your system, it is best to use myproxy-logon without the -T option, so as not to override the existing directory. The myproxy-logon -T option is for cases when you don't already have such an existing directory.

System administrators can run myproxy-get-trustroots to maintain /etc/grid-security/certificates. When run as root, the myproxy-get-trustroots command updates /etc/grid-security/certificates by default rather than $HOME/.globus/certificates. A sample cron job is provided at $GLOBUS_LOCATION/share/myproxy/myproxy-get-trustroots.cron. Also, a cron job customed for TeraGrid/XSEDE is available at myproxy-get-trustroots-teragrid.cron.

Troubleshooting

MyProxy v3.9 and later clients will automatically recover from CRL problems.

Updating CRLs using myproxy-logon

If you experience errors with out of date CRLs, causing "Invalid CRL" or similar error messages, run myproxy-logon -T again to update your CRL files. If the myproxy-logon command fails with an "Invalid CRL" error, remove your existing CRL files with the following command and then run myproxy-logon -T again.

$ rm -f ~/.globus/certificates/*.r*

You should also run the above command if you decide to discontinue using myproxy-logon -T and will not be using a replacement method for keeping your CRL files up-to-date.

Checking for expired certificates and CRLs

In the Globus trusted CA directory ($X509_CERT_DIR or $HOME/.globus/certificates or /etc/grid-security/certificates), you can find files of the following types:

  • *.0 - CA certificates typically valid for decades
  • *.signing_policy - specifies the "namespace" of the CA
  • *.r0 - certificate revocation lists (CRLs) typically valid for days/weeks

Your user certificate is stored separately in /tmp/x509up_u$UID or $X509_USER_PROXY or ~/.globus/usercert.pem or $X509_USER_CERT.

To check expiration times, use openssl x509 or openssl crl. For example:

$ openssl x509 -text < /tmp/x509up_u$UID | grep "Not After"
Not After : Jun 29 05:46:50 2012 GMT
$ openssl x509 -text < /etc/grid-security/certificates/9b95bbf2.0 | grep "Not After"
Not After : Apr 24 19:23:18 2027 GMT
$ openssl crl -text < /etc/grid-security/certificates/9b95bbf2.r0 | grep "Next Update"
Next Update: Jul 12 06:04:01 2012 GMT

A common mistake is to copy /etc/grid-security/certificates from another system and let the *.r0 CRL files expire. Potential solutions include:

  • Keep your trust roots up-to-date with myproxy-get-trustroots.cron or myproxy-logon -T as described elsewhere on this page.
  • Install a fresh /etc/grid-security/certificates directory using a CA distribution from IGTF or XSEDE or another trusted source.
  • Remove the old *.r0 files (though this adds risk that revoked certificates will be accepted).

References

Tom Barton, Jim Basney, Tim Freeman, Tom Scavo, Frank Siebenlist, Von Welch, Rachana Ananthakrishnan, Bill Baker, Monte Goode, and Kate Keahey. Identity Federation and Attribute-based Authorization through the Globus Toolkit, Shibboleth, Gridshib, and MyProxy. 5th Annual PKI R&D Workshop, April 2006.

Bruce Beckles, Von Welch, and Jim Basney. Mechanisms for Increasing the Usability of Grid Security. International Journal of Human Computer Studies, Special Issue on HCI Research in Privacy and Security, Volume 63, Issues 1-2, July 2005, pages 74-101.

Jim Basney and Von Welch. GridLogon: A Grid Service for Security Usability. Dec 1, 2003.

Last modified 06/14/13.
©2000-2016 Board of Trustees of the University of Illinois.