Software Links
Getting Started
- A Globus Primer
- Globus Is Modular!
- Quickstart
- Installing GT
- Platform Notes
- GT Developer's Guide
- GT User's Guide
- Migrating Guides
Reference
Manuals
Common Runtime
Security
- GSI C
- GSI Java
- Java WS A&A
- C WS A&A (coming soon)
- CAS
- Delegation Service
- MyProxy
- GSI-OpenSSH
- SimpleCA
Data Mgt
WS MDS
Execution Mgt
Table of Contents
For a list of common errors in GT, see Error Codes.
The following are some common problems that may cause clients or servers to report that credentials are invalid:
For a list of common errors in GT, see Error Codes.
Table 1. Credential Errors
| Error Code | Definition | Possible Solutions |
|---|---|---|
Your proxy credential may have expired | Your proxy credential may have expired. | Use grid-proxy-info to check whether the proxy credential has actually expired. If it has, generate a new proxy with grid-proxy-init. |
The system clock on either the local or remote system
is wrong. | This may cause the server or client to conclude that a credential has expired. | Check the system clocks on the local and remote system. |
Your end-user certificate may have
expired | Your end-user certificate may have expired | Use grid-cert-info to check your certificate's expiration date. If it has expired, follow your CA's procedures to get a new one. |
The permissions may be wrong on your proxy
file | If the permissions on your proxy file are too lax (for example, if others can read your proxy file), Globus Toolkit clients will not use that file to authenticate. | You can "fix" this problem by changing the permissions on
the file or by destroying it (with grid-proxy-destroy) and
creating a new one (with grid-proxy-init).
Important: However, it is still possible that someone else has made a copy of that file during the time that the permissions were wrong. In that case, they will be able to impersonate you until the proxy file expires or your permissions or end-user certificate are revoked, whichever happens first. |
The permissions may be wrong on your private key
file | If the permissions on your end user certificate private key file are too lax (for example, if others can read the file), grid-proxy-init will refuse to create a proxy certificate. | You can "fix" this by changing the permissions on the
private key file. Important: However, you will still have a much more serious problem: it is possible that someone has made a copy of your private key file. Although this file is encrypted, it is possible that someone will be able to decrypt the private key, at which point they will be able to impersonate you as long as your end user certificate is valid. You should contact your CA to have your end-user certificate revoked and get a new one. |
The remote system may not trust your
CA | The remote system may not trust your CA | Verify that the remote system is configured to trust the CA that issued your end-entity certificate. See Installing GT 4.2.0 for details. |
You may not trust the remote system's
CA | You may not trust the remote system's CA | Verify that your system is configured to trust the remote CA (or that your environment is set up to trust the remote CA). See Installing GT 4.2.0 for details. |
There may be something wrong with the remote
service's credentials | There may be something wrong with the remote service's credentials | It is sometimes difficult to distinguish between errors reported by the remote service regarding your credentials and errors reported by the client interface regarding the remote service's credentials. If you cannot find anything wrong with your credentials, check for the same conditions on the remote system (or ask a remote administrator to do so) . |
The grid-cert-diagnostics program checks prints diagnostics about the user's certificates, and host security environment.
%grid-cert-diagnostics-p
openssl verify -CApath /etc/grid-security/certificates -purpose sslclient ~/.globus/usercert.pem
openssl s_client -ssl3 -cert ~/.globus/usercert.pem -key
~/.globus/userkey.pem -CApath /etc/grid-security/certificates
-connect <host:port>Here <host:port> denotes the
server and port you connect to.
If it prints an error and puts you back at the command prompt, then it typically means that the server has closed the connection, i.e. that the server was not happy with the client's certificate and verification. Check the SSL log on the server.
If the command "hangs" then it has actually opened a telnet style (but secure) socket, and you can "talk" to the server.
You should be able to scroll up and see the subject names of the server's verification chain:
depth=2 /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/CN=ESnet Root CA 1
verify return:1
depth=1 /DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1
verify return:1
depth=0 /DC=org/DC=doegrids/OU=Services/CN=wiggum.mcs.anl.gov
verify return:1
In this case, there were no errors. Errors would give you an extra line next to the subject name of the certificate that caused the error.
The following are some common problems that may cause clients or servers to report that user are not authorized:
For a list of common errors in GT, see Error Codes.
Table 2. Gridmap Errors
| Error Code | Definition | Possible Solutions |
|---|---|---|
The content of the grid map file does not conform to the expected format | The content of the grid map file does not conform to the expected format | Run grid-mapfile-check-consistency to make sure that your gridmap file conforms to the expected format. |
The grid map file does not contain a entry for your DN | The grid map file does not contain a entry for your DN | Use grid-mapfile-add-entry to add the relevant entry. |