While you are using computer systems that are scattered all over the world, the administrators of all those machines will want to know who is using their machines and storage. In the past, you had to contact each site administrator separately, and you would get a username and a password for every new site. By providing this combination, the administrator could be sure who was using the system. But the user was obliged to remember as many passwords as there were sites. This cumbersome way of working is not suitable for the Grid, where you will be accessing many different sites without you even knowing.
On the Grid, you will be using a certificate. This certificate binds together your identity (name, affiliation, etc.) and a unique piece of digital data called a public key
that is explained below. A third party that is trusted by all sites in the Grid digitally signs
the combination of your name and the public key
ALICE Grid tutorial: how to get a certificate
- the tutorial will take place on Monday, 22nd of February 2010 from 10 am to 3 pm in the GSI IT Schulungsraum
Public key cryptography
The use of a public key to authenticate yourself is based on a special mathematical trick, called public key cryptography. If you would pick two large (prime) numbers and multiply them, it is virtually impossible to factorise the product into the two numbers again. The individual prime numbers are used to generate an encryption and a decryption function
and the product of the two, then the two numbers are destroyed. If you only have the encryption function, it is impossible to derive the decryption functions from it (and vice versa). So, if you distribute the encryption function called public key widely
(e.g. you put it on the web) but keep the decryption function called the private key secret
, everyone can send you encrypted messages, but only you can read them and even the sender cannot get the message back!
This method is quite useful if you want to authenticate yourself to a remote site without revealing any personal information: if the remote site knows your public key, it can encrypt a challenge (e.g. a random number) using this key and ask you to decrypt it. If you can, you obviously own the private key and therefore you are who you say you are but still the remote site has to know all the public keys of every one of its customers.
Associating public keys with identities
It all becomes simpler if we introduce a trusted third party
, a human that can authenticate people in persons called a Certification Authority (CA)
. When you go to a CA you bring along your public key and an identifier your full name and possibly an affiliation. Now the CA has to make sure by some other means that you are indeed who you claim to be. The CA may ask for a passport or drivers license, it could contact your boss to verify your affiliation, make a phone call to your office, etc. When the CA is reasonably convinced of your identity, it will take your public key and your identifier
and put those together in a certificate
. As a proof of authentication, the CA will then calculate a digest (hash) of the combination of the two and encrypt it with the private key of the CA. Everyone can recalculate the digest, decrypt the signature using the public key of the CA and verify that these two are the same. If you show up at a remote site that only knows your name (identifier) and trust the CA that you got your certificate from, the site known that whoever can decrypt the challenge sent corresponds to the name they have in their list of allowed users.
The association of a public key with its owner is typically done by protocols implementing a public key infrastructure. In Grid the ITU-T X.509
standard is commonly used as format for public key certificates and a certificate path validation algorithm. In this system the certificate binds the public key to a Distinguished Name (DN), which intends to identify a particular person (entity) uniquely
. The relative Distinguished Name (sometimes called subject name) consist of attribute-value pairs representing a path within the tree like structure of a public key infrastructure.
Certificates in Grid
Grid Security Infrastructure (GSI) extends X.509 Identity Certificates to support some important features like delegation and mutual authentication.
Grid certificates have a limited lifetime of one year to minimize the risk of compromised credentials. Certificates contain a wide range of information: issuer, valid dates, subject, and some crypto stuff (the public key of the user and a digital signature of the issuing CA).
Mutual authentication simply means that in GSI, both parts of a secure conversation must be authenticated.
In other words, when A wants to communicate with B, A must trust B and B must trust A. Remember that 'trust' (in this context) means that A must have the certificate of the CA that signed B's certificate, and vice versa. Otherwise, A won't trust B (and vice versa). Credential delegation and single sign-on are one of the most interesting features of GSI, and are possible thanks to something called proxy certificates.
subcommand is the entry point for retrieving this information. Using the
option will give you the full breadth of information.
openssl x509 -text -in $HOME/.globus/usercert.pem
openssl x509 -text -in /etc/grid-security/hostcert.pem
Show the hash value
openssl x509 -noout -in /etc/grid-security/hostcert.pem -hash
Display the identity of the owner, his Distinguished Name (DN)
openssl x509 -in $HOME/.globus/usercert.pem -noout -subject
openssl x509 -in /etc/grid-security/hostcert.pem -subject
Verify certificates using trusted CAs:
openssl verify \
-CApath /etc/grid-security/certificates \
openssl verify \
-CApath /etc/grid-security/certificates \
Single sign-on is supported from GSI by using proxy certificates, with a very shot lifetime (less then 12 hours). They will be signed with the users certificate (the private key) and have their own, new public/private key pair.
The goal is to reduce security risks (the users private key can't be exposed after the proxy has been signed) and to enable delegation.
user certificate file
signing|------------------ private key encrypted
| by a pass phrase
user proxy certificate file
delegated next-level proxy
on a remote server
By default you can find proxy certificates in
stored in a local file. The private key of the proxy isn't encrypted but should be only readable by the owner. To read a proxy-certificate:
openssl x509 -in /tmp/x509up_u$UID -text
They are created using the
commad. The user will be asked to enter his pass phrase, which is used to decrypt his private key. Delegation
allows remote processes to authenticate on behalf of the user. This is achieved by creation of a next-level proxy from a proxy.Therefor a server remotely generates an new key pair which will be singed the clients proxy certificate.
Obtain a user certificate via GSI
At present you need to have access to the interactive Linux nodes (lxi001-015) at GSI. Before generating an certificate request initialize the correct environment like:
shell> source /usr/local/grid/GT/2.4.3/globuslogin.sh
Create a certificate
Now, to request a user certificate, simply run
. Please leave a "space" between "first name" and "last name"
shell> grid-cert-request -cn "<first name> <last name>"
As part of the output you will see your Distinguished Name:
A private key and a certificate request has been generated
with the subject:
/O=GermanGrid/OU=GSI/CN=<first name> <last name>
will ask for a password to protect your key, and give you a set of instructions for how to e-mail your request to the CA. When you run the
command, it will generate three files. One file is the request that you need to send to the CA, named
. Another one is the key that corresponds to that request, named
. The last one is
, which is an empty file. This is not your certificate! It is merely a placeholder that helps to remind you where to put your certificate when the CA responds to your request.
By default the private key
and the certificate request
containing the public will be stored in the home directory
. Please double-check the contents of
at this time. The subject name should look something like:
$ cat $HOME/.globus/usercert_request.pem
/O=GermanGrid/OU=GSI/CN=<first name> <last name>
Get your certificate signed by a trusted third person
Now that you have double-checked your subject, you need to send the request to the CA.
will output the location of the request. We recommend using your regular e-mail agent to do this. Address an e-mail to firstname.lastname@example.org
to the e-mail.
Alternatively it's also possible to send a mail directly from the shell.
shell> mail -s "user-cert-request" email@example.com < $HOME/.globus/usercert_request.pem
You may be contacted via e-mail or phone before receiving the certificate. The certificate request file has to be signed by the local CA responsible person (currently: Kilian Schwarz). Before having the request signed please hand out a copy of your passport or "Personalausweis" to the local CA responsible.
This copy will be kept in a folder for security reasons.
The certificate will be sent to you via e-mail. When it arrives, read the contents of the e-mail and you may save the entire e-mail to
. In the end, you will have a
directory. Only you have a copy of your key file. Do not lose this file, and do not forget your password.
shell> cp <somewhere>/usercert.pem ~/.globus/usercert.pem
Keep your private key protected
Regard the protection set on your private key file
The access privileges are very restrictive and are set for one reason: your possession of the private key is the only proof remote sites have that they are indeed talking to you. If you would give that key to someone else (or if it gets stolen), you will be held liable for any damage that may be done to the remote site! In any case, if the user key is world readable or worse, is cannot be used by the Grid.
shell> ls -al $HOME/.globus
-r--r--r-- 1 user group 4.9k Jul 22 2004 usercert.pem
-r-------- 1 user group 963 Jul 19 2004 userkey.pem
It is very important to keep the private key protected!!!
Pay attention to the permissions:
userkey.pem contains your private key and must be readable just by yourself (400)
usercert.pem contains your public key, which should be readable also from outside (444)
Import your certificate into your browser
To complete the registration process your certificate must be loaded into your web browser. Browsers (including Internet Explorer, Firefox and Safari) use a different format for certificates then PEM. It is necessary to convert
into another certificate container called PKCS12. Use
to do so:
shell> openssl pkcs12 -export \
-in $HOME/.globus/usercert.pem \
-inkey $HOME/.globus/userkey.pem \
You can find a small guide
for loading the PKCS12 certificate into your browser on the web pages from SARA. Additionally is very useful to load also the certificate from you local CA to the browser. You can find an example
for the GermanGrid CA at Forschungszentrum Karlsruhe.
Grid users must belong to a Virtual Organization (VO) which represents a group of users belonging to a collaboration.
Each VO has their common usage guidelines which users have to sign to join. Certificates are used to authenticate users whereas the VOMS is used to controlle the authorization of users. Authorization defines who is allowed to do what.
The registration to the VO needs to be done only once. The VOs are registered in the Grid and each particular site or resource decide which VOs to support. The consequence in this model is to avoid the necessity tho register users directly on each site.
Virtual Organisation Membership Service
Since the Virtual Organisation Membership Service (VOMS) is used in Grid to authorize users it is possible to be part of multiple VOs with aggregate rights.
Each VO can have groups with different rights for each and roles which could be assigned to specific people like administrators.
The additional attributes representing groups membership, roles and capabilities will be carried by the proxy certificate generated using
. They are expressed in a format that bounds them together called Fully Qualified Attribute Name (FQAN)
. Proxy certificates extended with attributes are sometimes called as Attribute Certificates (AC).
Create a proxy certificate with VOMS extention
The users contacts the VOMS server requesting his authorization information. Therefore the host certificate of the server needs to be in
or wherever the
environment variable points to (owned by exactly root:root). To discover the server a contact string should be in
0644). Here some examples:
"GSI" "grid22.gsi.de" "15000" "/O=GermanGrid/OU=GSI/CN=host/grid22.gsi.de" "GSI"
Create a proxy for a specific VO using the
voms-proxy-init --voms <VO_NAME>
After contacting the server authorization information (group memberships/roles) will be retrieved to the client to be includes in the proxy certificate, you can look into these attributes with:
- Mar 2005 - Oct 2006