Digital certificates

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

• ALICEGridtutorial.ppt: slides about how to get a certificate

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.

X.509 Certificates

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.

The openssl x509 subcommand is the entry point for retrieving this information. Using the -text 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 \
   $HOME/.globus/usercert.pem

openssl verify \
   -CApath /etc/grid-security/certificates \
   /etc/grid-security/hostcert.pem

Proxy 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
   usercert.pem
          |
          |
   signing|------------------ private key encrypted  
          |                     by a pass phrase    
          |                        userkey.pem     
          |
user proxy certificate file                    
   /tmp/x509up_u$UID 
          |     
          |
   signing|
          |
          |
delegated next-level proxy
   on a remote server

By default you can find proxy certificates in /tmp 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 grid-proxy-init or voms-proxy-init 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

• prefered method: Web Interface of GridKa Ca

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 grid-cert-request. 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>

grid-cert-request 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 grid-cert-request command, it will generate three files. One file is the request that you need to send to the CA, named usercert_request.pem. Another one is the key that corresponds to that request, named userkey.pem. The last one is usercert.pem, 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 userkey.pem and the certificate request usercert_request.pem containing the public will be stored in the home directory $HOME/.globus. Please double-check the contents of usercert_request.pem at this time. The subject name should look something like:

$ cat $HOME/.globus/usercert_request.pem
[...]
Certificate Subject:

    /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. grid-cert-request will output the location of the request. We recommend using your regular e-mail agent to do this. Address an e-mail to k.schwarz@gsi.de and attache ~/.globus/usercert_request.pem to the e-mail.

Alternatively it's also possible to send a mail directly from the shell.

shell> mail -s "user-cert-request" k.schwarz@gsi.de < $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 $HOME/.globus/usercert.pem. In the end, you will have a userkey.pem and usercert.pem in your $HOME/.globus 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 userkey.pem. 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
total 16k
-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 usercert.pem into another certificate container called PKCS12. Use openssl to do so:

shell> openssl pkcs12 -export \
 -in $HOME/.globus/usercert.pem \
 -inkey $HOME/.globus/userkey.pem \
 -out $HOME/.globus/usercert.p12

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.

Virtual Organizations

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 voms-proxy-init. 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 /etc/grid-security/vomsdir or wherever the X509_VOMS_DIR environment variable points to (owned by exactly root:root). To discover the server a contact string should be in /opt/glite/etc/vomses or in ~/.glite/vomses (Permission: ~/.glite/ 0755, ~/.glite/vomses 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 command:

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:

voms-proxy-info --all

-- VictorPenso - Mar 2005 - Oct 2006