Difference between revisions of "Grid Certificate"

From GridPP Wiki
Jump to: navigation, search
(No difference)

Revision as of 15:29, 14 May 2013

Certificate Overview

The gLite User Guide describes how certificates are used in the grid middle-ware.

Certificate Juju

A few notes about doing stuff with/to certificates:

Converting host certificates to omit the email addresses from DNs

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

Introduction

Email address components in the DN of host certificates cause chaos in the security system. The UK Certificate Authority (CA) now issues host certificates without email addresses, and the Grid Certificate Profile banned the use of email address components, since 2008. So grid sites are recommended to remove the email address components from any existing host certificates. This procedure describes a way to get replacement certificates.

This use case is called "de-emailing", to make it distinct from "renewal" or "apply for new". The procedure is not exactly a "renewal" because the existing certificate with the email-address part remains in force until it expires or is explicitly revoked. And it's not strictly a normal "apply for new" because a certificate for the host already exists (albeit with the email-address part in it).

This procedure will use the Certwizard tool. Its "apply for new" use case has been amended to make it possible to apply for a new certificate for a machine that already has a valid certificate in force. The new certificate will not have any email address component. In this way, both versions of the certificate will exist in force for the time being, until a new one is installed, after which the old ones can be revoked, or left to expire. The main feature of this use case is that the old certificate remains in force, giving time for the transition without needing downtime.

Steps

Start Certwizard

The Certwizard web page gives several options for starting up the Certwizard. Use one of them. These did not work for me straight away, so I did this instead (which works for Java 1.7x).

mkdir -p apps/cw
cd apps/cw
wget https://tools.ngs.ac.uk/ngstools/certwizard/currentdownload/dist.zip
mv dist.zip dist17.zip
unzip dist17.zip  
voms-proxy-init --voms dteam
java -jar dist/Certwizard.jar /user2/sjones/.globus/x509up_u460

As it starts up, it asks you some questions about the location for the key store. Also, you have to give a password for the key store, which you need to remember. When it first starts, it makes a new key store. If you are using the Certwizard for the first time, you should import your personal certificate into it at this time, e.g. click "Apply for/manage your certificate", click Import and go through the motions to bring in (e.g.) ~/.globus/usercert.p12 (it's probably encrypted so you'll have to give the password you used in the first place to do that).

Getting the replacement

This is the process to get one replacement "de-emailed" host certificate. You'll have to repeat it for all your host certificates. It's probably more efficient to do it in batches, but you have to be careful to keep track of what you've done, maybe in a table or something.

Click on the panel titled "Apply for/manage your certificate". You'll have to give it your key store password. This is not necessarily the same as your personal certificate password!

Select your personal certificate from the drop down box labelled "Certificates in my keystore". NB: You always have to have your personal certificate highlighted at this stage.

Click "Apply for cert", and click "Host" in the pop-up menu. Then fill out the resulting form. Tip: if doing batches, it is far easier to have all the details for the whole batch already accurately typed into a terminal in (say) vi, so that you can just pick up the fields and drop them into the boxes without any errors.

The Host Admin Email is stil required and should route back to you, or your group. But it will not appear in the replacement "de-emailed" host certificate.

Choose some PIN that is not necessarily the same as your personal certificate password, or your keystore password. In batches, it is easier to always use the same PIN, but you are free to use whatever you like. The alias can be anything meaningful.

Apply the form. Periodically click the Refresh button next to the "Certificates in my keystore" field, which polls the server to update all the details.

Behind the scenes

A process now occurs behind the scenes where the applied for replacement certificate goes through various states, including "in progress" and "issued". At some point, the a "Regional Authority" will have to approve the request. You may get email from him/her. Eventually, if it all works, you will find, on polling the server, that it moves to the VALID state. It is now ready to export and use.

Exporting and deploying the certificate

In the Certwizard, in the "Apply for/manage your certificates" panel, select the certificate you wish to export. Click export, and choose to export the private key and certificate in PEM format. Give no password (leave it blank). Make a mental note that you will need to secure the files later by removing read permissions from other users.

Surf to some logical location and save the certificate there with a unique name that indicates its contents - the default name was not suitable.

The resulting file contains both a certificate and a key in PEM format. You need them in separate files. Use a command such as the following example to do that:

awk '/BEGIN/{x="F"++i;}{print > x;}' someserver.pem  ;mv F1 hostkey_someserver.pem  ;mv F2 hostcert_someserver.pem 

Alternatively, if doing batches, use some script like this one (it also makes a little tarball out of the stuff):

[sjones apps]$ cat cw/splitup.sh 
#!/bin/bash

for n in hg90 hg91 hg92 hg93 hg94 hg95 hg96 hg97 hg98 hg2 hg3 hg4 hg5 hg6 hg9 hg10 hg11 hr1 hr2 hr3 hr4 hr5 hr6 hr7 hr8 hr9 hr10 hr11 hr12 hr13 hr14 hr15 ; do
  echo Doing: $n
  awk '/BEGIN/{x="F"++i;}{print > x;}' $n.pem  
  mv F1 hostkey_$n.pem 
  mv F2 hostcert_$n.pem 
  openssl x509 -in hostcert_$n.pem -text | egrep '(After)|(Subject: )'
done
tar -cf certsAndKeys.tar hostkey_h*.pem hostcert_h*.pem


You can then deploy the new certifcate(s) into your configuration control system and roll them out under the correct names (usually hostcert.pem, hostkey.pem). There are specific procedures for making the certificates active. These vary according to the node type and this is not covered here, but they basically consist of running some YAIM command and/or restarting some services.

And that's almost it - your site is de-emailed, and you'll have no more stupid "email address in DN" errors. Oh, don't forget to secure the all the files by removing read permissions from other users. Or get rid of them - they are in the key store anyway.

But finally, change all the entries in the GOCDB to contain the new DNs.

Unpacking a host certificate (from the exported/backed up .pfx/.p12 file you got from the CA)

Do this in /etc/grid-security

 # openssl pkcs12 -clcerts -nodes -in <CERT> -out hostkey.pem
 # chmod 400 hostkey.pem
 # openssl pkcs12 -clcerts -nokeys -in <CERT> -out hostcert.pem
 # chmod 444 hostcert.pem

Checking a host certificate

 # openssl x509 -in <CERT> -noout -text

N.B. A machine certificate has a common name (CN) which contains the hostname and the email of the certificate requester, e.g., CN=grid07.ph.gla.ac.uk/Email=g.stewart@physics.gla.ac.uk. A personal certificate has the common name of the user, e.g., CN=graeme stewart.

N.B. When requesting a server certificate for use within LCG do not select a Service Type (this is for Globus middleware only). Leave this as "none". These globus certificates can be identified because they have the service type in front of the hostname, e.g., CN=host/grid07.ph.gla.ac.uk/Email=g.stewart@physics.gla.ac.uk.

Converting a Certificate back into P12 Form

To renew a certificate you need to have it loaded into your browser. If you no longer have the host certificate loaded, then you can convert the X509 hostkey/cert pair back into PKCS12 format using this openssl command:

 openssl pkcs12 -export -in hostcert.pem -inkey hostkey.pem -out bundle.p12

You can add a passphrase if necessary. (Or add the option -passout pass: to suppress the passphrase dialogue.)

Private Key

The CA permits (or will permit shortly) three different types of private keys.

  1. Encrypted software keys (encrypted with a "strong" passphrase) - used for user keys. Proxies are used to "unlock" the key over a period of time.
  2. Unencrypted software keys - normally used for host keys, or for "softkey" robot certificates. As the key (file) itself is not protected by a passphrase, it must have other means of preventing being stolen or otherwise used in an unauthorised way.
  3. KeyTokens, a hardware module which protects the private key from theft.

This page is a Key Document, and is the responsibility of Rob Harper. It was last reviewed on 2013-05-14 when it was considered to be 0% complete. It was last judged to be accurate on (never).