Certificate Hints & Tips

The use and management of certificates and proxies can cause problems because the details are complex and things are not always clear to non-experts, so this page has a collection of useful information in various categories. The information here assumes that you already understand the basic concepts. If you would like anything added to this page please contact the Documentation Officer.

Web Browsers

Most web browsers have built-in support for certificate management, but different browsers, and sometimes different versions of the same browser, do it in different ways, which makes it very difficult to give general instructions. The CA supports some common browsers and gives instructions for their use, but otherwise you may need to read the browser documentation to find out how to do things. Browsers may also have idiosyncrasies which prevent certain things working.

For MS Internet Explorer certificate management is via Tools/Internet Options/Content. One useful thing to remember is the "Clear SSL State" button, which makes IE forget the certificate in use and allows you to choose another one the next time a site requests it.

For Firefox certificate management is via Tools/Options/Advanced/Encryption.

Key security

The most important issue is that the browser stores your private key internally. The private key needs to be kept secret, as anyone who steals it can impersonate you completely. Browsers normally allow the key to be password-protected, but this varies and may not be the default (it is not with Internet Explorer). The most secure mode is one in which every use of the private key needs the password to be entered, but this can cause problems as some web sites ask for the certificate many times. If the key is not password-protected you need to take care that no-one else can get access to a browser session.


Certificates can be saved from the browser as a file, or imported into it from a file. This file also contains the private key and hence should be password-protected, and also read-protected if you store it on a shared machine, e.g. a UI. Be aware that if there is no password required for export, someone with a floppy or a USB drive with access to your machine could potentially get a copy of your certificate and key in less than a minute.

CA root certificates

If you connect to a secure (https) web site where the server certificate was issued by a Grid CA you may get warning messages about the certificate being untrusted. Also to use the UK e-Science CA web site, e.g. to get or renew a certificate, the CA certificate needs to be trusted. Web browsers can generally import a trusted certificate in various ways, but the easiest is to do it from a suitable web site, e.g. the UK CA. The full set of approved Grid CA certificates can be obtained from the TACAR repository - see this FAQ page for more information. When you do this make sure that you are downloading from the correct web site as you are giving your trust to any certificates issued by those CAs.

Try not to get into the habit of just hitting "OK" on any warning box, especially if you use internet banking or the like. Untrusted certificates on commercial sites are likely to indicate that the site is not what you think!

Taking Care of Keys

Your private key is the core of your Grid identity. Anyone who steals it can impersonate you, and if you lose it you can no longer do anything, so taking care of it is vital. Certificates are issued to you personally, and you should never allow someone else to use your key. Key security in browsers is discussed in the previous section.

To use the Grid you must agree to an Acceptable Use Policy, which among other things requires you to keep your private key secure. In particular you must not allow anyone else to use your private key.

Proxies also have private keys, and although these are less important as the lifetime of a proxy is short it's still important to look after them.

Key storage

On a Linux UI the certificate and private key are stored in two files. Typically they are in a directory called ~/.globus and are named usercert.pem and userkey.pem, although this can be changed. The certificate is public and can be world-readable, although there is usually no need for it, but the key should only be readable by the owner (some tools will check this and refuse to work if the permissions are wrong). Ideally the key should be stored on a disk local to the UI rather than e.g. an NFS-mounted disk, although this is not always possible.

If your private key is stored under afs, e.g. on lxplus at CERN, be aware that access is controlled by the afs ACLs rather than the normal file permissions, so make sure that it is not in a public area.

You should take care not to lose your private key, as you will then lose all access to the Grid and have to start registration again from scratch. This generally means having several copies in different places - this is often useful anyway, e.g. to use the certificate from a web browser and several UI machines. However, you must make sure that all copies are stored securely.


The private key is normally also encrypted, so you have to type a passphrase whenever you use it. You should never store a key without a passphrase. The passphrase should follow similar rules to any computer passwords, but in general should if anything be longer and harder to guess as it gives access to a much larger set of resources than usual. Note this comment from the UK CA website: "Please note that our policy states that the passphrase must be at least 16 characters long and contain upper and lower case letters". You usually only have to type the passphrase once or twice a day to create a proxy, so having a long passphrase is not a major overhead. Be aware of the usual risks, like people watching you type or transmitting the passphrase over an insecure link.

Be aware that if you forget the passphrase there is no way to recover the private key, in which case you will have to re-register (see below). However, if you keep any record of the passphrase you must ensure that it is secure.

Proxy security

A proxy, which includes its own private key, can be stored anywhere but is typically under /tmp (note that this is usually a local area, so when using systems like lxplus with many front-end machines, sessions in different windows may not all see the same /tmp). The file name is usually x509up_u1234 where 1234 is your uid, but again this can vary. In any event, like the user key a proxy should only be readable by the owner. However, there is no passphrase protection.

Expiry, Revocation and Renewal

Certificates are normally valid for one year from issue, and have to be renewed so the CA can verify that you are still entitled to have it. You should get an email from the CA well in advance to remind you. It's important to renew in time; if your certificate expires you won't be able to do anything on the Grid. The renewal process can be done entirely online; you visit the CA web site to request a renewal, and visit again once the request is approved to collect the new certificate.

You will normally have to change your private key on renewal, but the Subject Name usually stays the same, although there are circumstances where it may be forced to change, especially if you move to another institution.

If you lose your private key or let the certificate expire you will normally be allowed to re-register for a new certificate with the same Subject Name. However, you will be required to go through the full registration process, usually involving a personal visit with a photo ID to prove that you are the same person who applied for the original certificate.

Under some circumstances a certificate can be revoked by the CA, although this is a fairly rare event. It would usually only apply if your private key has been stolen. As with key loss this a drastic circumstance which will mean that you lose access to the Grid and have to re-register.

Each CA distributes information about revoked certificates as a Certificate Revocation List (CRL). These have a lifetime, usually of a few days, and to ensure security many services will refuse authorisation if the CRL is not up to date. The CRLs are normally updated regularly with a cron job, but if this fails for some reason then failures may be seen - the symptoms are failures with some remote services but not others, and only for users with certificates issued by particular CAs.

You will also probably be required to renew your VO membership on a regular basis, although the details vary between VOs. You will generally get an email telling you that you need to re-register. If your Subject Name changes, e.g. if you move to a new institution, you may be able to register the new name as an alias to your existing VO identity - consult the VO documentation for details.

Use of Proxies

For most purposes you use a proxy and not the certificate directly. The main exception is with web browsers, which don't currently support proxies. Commands have to be able to find the proxy, which is usually stored in a standard place as described above; otherwise you can usually specify an alternate location with a command argument or environment variable.

Proxy lifetimes

When you create a proxy the default lifetime is 12 hours, but you can specify any lifetime up to the life of the certificate. However, in most circumstances a long-lived proxy is a security risk; proxies can't be revoked, so if one is stolen you might be banned from the Grid until it expires! Services may soon start imposing a limit and rejecting any proxy which has too long a lifetime; it is likely that the official Grid policy will soon mandate an upper limit of 24 hours. VOMS servers also impose a limit (typically 24 hours) on the life of the Attribute Certificates they issue.


Some things just use the proxy directly to talk to a remote service, but in many cases the proxy has to be given to the service so that it can do things on your behalf, a process known as delegation. There are generally two ways that this is done, either by putting a proxy in a storage service called MyProxy where another service can retrieve it, or by directly sending the proxy to the service.


MyProxy is a special service which stores a long-lived proxy, and can then issue a short-lived proxy derived from it. This should be the only exception to the rule about creating proxies with a long lifetime, although even here you should only use the lifetime you need. Also you should destroy the local copy of the proxy after copying it to the MyProxy server.

Depending on its configuration, MyProxy can issue a proxy either to something posessing an existing proxy or controlled with a password, and can also be restricted to services running on specific known machines. It's important to be sure that you trust the MyProxy servers you use, so you should only use ones run by trusted local sites (e.g. RAL in the UK) or by central laboratories like CERN. More information about using MyProxy can be found on this page.

The RAL MyProxy server is called lcgrbp01.gridpp.rl.ac.uk.

Direct Delegation

Job submission, among other things, uses direct delegation, i.e. the proxy is copied to the Resource Broker when you submit the job. This is safe as long as the transfer and storage of the proxy are done securely. When the broker sends a job to an execution site it creates a new proxy derived from the existing one, with a special Subject Name which identifies it as a "restricted proxy". This means that the "power" of the proxy is limited; it will be accepted by some services, e.g. for file transfer, but it cannot be used to submit further jobs. Thus if someone manages to steal such a proxy the damage they can do is somewhat limited. This also means that you can't have recursive jobs which spawn other jobs, which could potentially run away and fill the whole system.

Proxy Renewal

As mentioned above, proxies normally have a limited lifetime of 12-24 hours. However, Grid jobs or other tasks may often need more time than this (even short jobs may be queued for a long time). The solution to this is to use MyProxy to store a long-lived proxy. Services like the Resource Brokers can then contact the MyProxy server when the current proxy is close to expiring, present the existing proxy or a password, and retrieve a new short-lived proxy. Services do this in various ways, and you should consult the documentation to see how to use MyProxy in each case. In some cases, e.g. for use with cron jobs, you may also want to use MyProxy directly.

If you have any reason to think a proxy or password has been stolen you should delete any long-term proxies from MyProxy servers to prevent them being renewed.

Command Line Tools

There are various command-line tools which are used to manipulate certificates and proxies. They are not described in detail here, but they are covered in other documentation and generally have man pages and inline help.

The basic Globus tools (with fairly obvious meaning) are:

  • grid-cert-info
  • grid-proxy-info
  • grid-proxy-init
  • grid-proxy-destroy
  • grid-change-pass-phrase

VOMS provides tools which duplicate the functionality of some of the Globus commands, but also provide extra options:

  • voms-proxy-info
  • voms-proxy-init
  • voms-proxy-destroy

The MyProxy-related commands are:

  • myproxy-info
  • myproxy-init
  • myproxy-destroy
  • myproxy-change-pass-phrase
  • myproxy-get-delegation

Finally, there is a command openssl which allows many low-level operations, although it can be somewhat complex to use.

Error Messages

The security system is complex, and there are many things which can go wrong. The error messages you get for such things are better than average for the Grid, but that isn't saying a great deal. Bear in mind that the problem may be at the remote end, if the error says "certificate expired" it might be your certificate (or proxy), or it might be the host certificate of the machine you're talking to (or it might be that the clocks on the two machines aren't in step and the remote machine thinks that your proxy starts in the future!).

In general start by checking the obvious things, i.e. that you have a certificate and proxy and that they haven't expired. If possible try with more than one remote site/service to see which end has the problem. Beyond that you probably have to ask for help.

Last modified Mon 26 September 2011 . View page history
Switch to HTTPS . Website Help . Print View . Built with GridSite 1.7.25