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
- Taking Care of Keys
- Expiry and Revocation
- Use of Proxies
- Command Line Tools
- Error Messages
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 securityThe 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.
Import/exportCertificates 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 certificatesIf 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!
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.
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 securityA 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.
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.
Proxy lifetimesWhen 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.
DelegationSome 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.
MyProxyMyProxy 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 DelegationJob 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 RenewalAs 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.
The basic Globus tools (with fairly obvious meaning) are:
VOMS provides tools which duplicate the functionality of some of the Globus commands, but also provide extra options:
The MyProxy-related commands are:
Finally, there is a command openssl which allows many low-level operations, although it can be somewhat complex to use.
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.4.3