The Grid utilizes public key or asymmetric cryptography for authentication of users, resources and services (about cryptography see the RSA FAQ). According to the basics of public-key cryptography, each resources on the Grid has a key pair, a public and a private key. The public key is made public while the private key must be kept secret. Encryption and authorization is performed using the public key while decryption and digital signature is performed with the private key. It is important to notice that generating a key pair does not automatically provide you access to the Grid resources. A trusted authority of the Grid, called the Certificate Authority (CA) needs to sign your key pair this way confirming your identity. This signing procedure of the CA is often referred as issuing a certificate.
In the Grid era the key file (userkey.pem) and the certificate file (usercert.pem) correspond to the key pair of the public-key cryptography. The userkey.pem file (or resourcekey.pem) contains the private key encrypted with your password (called pass phrase by some tools). The certificate file (usercert.pem) contains your public key together with additional important informations such as the subject name of the holder of the certificate, the name of the signing CA, and the digital signature of the CA. The important role of the CA is to establish a trustful connection between the identity of the user and the public key in the certificate file. The digital signature of the CA in the user's certificate file officially declares that the public key in the file belongs to the specific user (subject name). The certificate files are encoded with the x.509 format.
In order to obtain a valid "passport" to the Grid you need to create a key pair and submit your public key to the CA (this process is called as a certificate request) for a signature. The CA will follow its certificate policy and upon successful evaluation of your request your public key will be signed and posted back to you. As it was mentioned before all resources (i.e. gatekeepers, users, services) require a CA-signed key pair to be able to operate on the Grid.
Please always remember that a "Grid passport" (credentials) consists of two files, the private key file called by default userkey.pem and the public certificate file usercert.pem; you need to have both of them. The certificate file (usercert.pem) alone is not enough for the Grid. If you loose one of your credential files, you'd need to request a new certificate. File names can be changed, and most client tools can operate with arbitrary credential file names (but not arbitrary permissions, see below).
Certificate requests (e.g. those created by globus-certreq or grid-cert-request tools) create an unsigned key pair; they are often placed in your ~/.globus directory, as this is the default location for many Grid tools. If you used a web interface to create a certificate request, make sure to follow all instructions on how to obtain the key pair. The userkey.pem holds your private key encoded with your pass phrase (you are prompted to supply this pass phrase during the key pair generation). This file must only be readable by its owner. The usercert_request.pem is created only if you used a command line tool (e.g. grid-cert-request): this file contains your unsigned public key together with your subject name and the name of your intended CA. This file should be mailed to the CA. The command line tools create an empty usercert.pem file as well; you must later save your final CA-signed certificate into this file.
You can use the OpenSSL cryptography toolkit and the Globus provided commands to create, check, convert between different formats, manipulate your certificate files (actually the Globus commands are just a friendlier interface to the OpenSSL toolkit). For further information please read the OpenSSL, verify and x509 man pages, or use the Globus commands with the -help option.
Command line tools grid-cert-request and grid-cert-info are a part of the Globus Toolkit and are distributed in the globus-gsi-cert-utils-progs package. It is possible to create certificate requests using native OpenSSL means, but they are even less user-friendly.
Many modern Grid systems use proxy certificates in order to delegate your rights to Grid services, which can then act on your behalf (copying files etc.). Proxy certificates, or proxies, are similar to your public certificate, but they are not protected by a password and therefore have very limited life time, in order to minimise potential damage should the proxy be stolen.
Proxies can contain extensions carrying additional information about users, such as e.g. their affiliations with Virtual Organisations, roles therein, and so on.
ARC offers a simple tool to create various proxies, arcproxy. Typical usage examples are:
See arcproxy man page for more options and details.