Difference between revisions of "Grid Certificate"

From GridPP Wiki
Jump to: navigation, search
(Private Key)
(Delete entire section on de-emailing old form hostcerts since we are long since done with it.)
Line 7: Line 7:
  
 
A few notes about doing stuff with/to certificates:
 
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 [http://www.ogf.org/documents/GFD.125.pdf 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  [http://www.ngs.ac.uk/use/tools/certwizard 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 [http://www.ngs.ac.uk/use/tools/certwizard 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).
 
 
<pre>
 
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
 
</pre>
 
 
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:
 
 
<pre>
 
awk '/BEGIN/{x="F"++i;}{print > x;}' someserver.pem  ;mv F1 hostkey_someserver.pem  ;mv F2 hostcert_someserver.pem
 
</pre>
 
 
Alternatively, if doing batches, use some script like this one (it also makes a little tarball out of the stuff):
 
 
<pre>
 
[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
 
</pre>
 
 
 
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 <tt>.pfx/.p12</tt> file you got from the CA)==
 
==Unpacking a host certificate (from the exported/backed up <tt>.pfx/.p12</tt> file you got from the CA)==

Revision as of 16:44, 27 February 2015

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:

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 2014-04-29 when it was considered to be 90% complete. It was last judged to be accurate on 2014-04-29.