|
|
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)== |
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.
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:
You can add a passphrase if necessary. (Or add the option -passout pass: to suppress the passphrase dialogue.)
The CA permits (or will permit shortly) three different types of private keys.