Difference between revisions of "Grid Certificate"

From GridPP Wiki
Jump to: navigation, search
 
(How to send signed email from command line)
 
(24 intermediate revisions by 8 users not shown)
Line 3: Line 3:
 
The [https://edms.cern.ch/file/722398/1.4/gLite-3-UserGuide.pdf gLite User Guide] describes how certificates are used in the grid middle-ware.
 
The [https://edms.cern.ch/file/722398/1.4/gLite-3-UserGuide.pdf gLite User Guide] describes how certificates are used in the grid middle-ware.
  
−
= Certificate Juju =
+
Many certificate applications and renewals can be carried out using the [http://www.ngs.ac.uk/ukca/certificates/certwizard UK e-Science CA's 'CertWizard'] tool (in Java); there is also a [https://portal.ca.grid-support.ac.uk/caportal CA portal] which uses javascript; it requires that the generated private key be stored in a file until the certificate is issued and they can be recombined and saved as PKCS#12.
  
 +
There is also the [http://www.ngs.ac.uk/ukca/pecr 'PeCR'] bulk system, which you can use to make requests for multiple certificates from the command line. It also supports [[SubjectAltName]].
  
−
A few notes about doing stuff with/to certificates:
+
Systems administrators may also be interested in the commandline [https://github.com/sfayer/cert_sorcerer CertSorcerer] tool.
  
−
==Converting host certificates to omit the email addresses from DNs==
+
= Certificate Juju =
  
−
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
+
A few notes about doing stuff with/to certificates:
−
 
+
−
=== 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)==
Line 138: Line 17:
 
Do this in <tt>/etc/grid-security</tt>
 
Do this in <tt>/etc/grid-security</tt>
  
−
   # openssl pkcs12 -clcerts -nodes -in <CERT> -out hostkey.pem
+
   # openssl pkcs12 -nocerts -nodes -in <CERT> -out hostkey.pem
 
   # chmod 400 hostkey.pem
 
   # chmod 400 hostkey.pem
 
   # openssl pkcs12 -clcerts -nokeys -in <CERT> -out hostcert.pem
 
   # openssl pkcs12 -clcerts -nokeys -in <CERT> -out hostcert.pem
Line 147: Line 26:
 
   # openssl x509 -in <CERT> -noout -text
 
   # 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., <tt>CN=grid07.ph.gla.ac.uk/Email=g.stewart@physics.gla.ac.uk</tt>. A personal certificate has the common name of the user, e.g., <tt>CN=graeme stewart</tt>.
+
N.B. A machine certificate has a common name (CN) which contains the hostname e.g., <tt>CN=grid07.ph.gla.ac.uk</tt>. A personal certificate has the common name of the user, e.g., <tt>CN=graeme stewart</tt>.
  
−
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 <tt>"none"</tt>. These globus certificates can be identified because they have the service type in front of the hostname, e.g., <tt>CN=host/grid07.ph.gla.ac.uk/Email=g.stewart@physics.gla.ac.uk</tt>.
+
See also [[SubjectAltName|Subject Alternative Name]] for host certificates.
  
 
==Converting a Certificate back into P12 Form==
 
==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
 
   openssl pkcs12 -export -in hostcert.pem -inkey hostkey.pem -out bundle.p12
Line 165: Line 42:
 
# 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.
 
# 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.
 
# [[KeyTokens]], a hardware module which protects the private key from theft.
 
# [[KeyTokens]], a hardware module which protects the private key from theft.
 +
 +
= Sending mail with a certificate =
 +
 +
Normally you can use your MUA to sign mail (with your private key) so that the recipient can verify the signature with your certificate. This provides (1) integrity protection and (2) sender origin authentication.  This normally works only with a personal certificate (or robot), which have email addresses in them.
 +
 +
However, there are two use cases for sending email on the command line. One is sending automated messages with a robot certificate which are signed with the robot certificate. The other is that your certificate has expired, and you cannot use CertWizard for some reason, so you need to send a signed PIN to the CA to renew the certificate.
 +
 +
Assuming that your unsigned message is in <tt>msg.txt</tt>, and your cert/key are in <tt>usercert.pem</tt> and <tt>userkey.pem</tt> respectively,
 +
 +
  openssl smime -sign -in msg.txt -inkey userkey.pem -signer usercert.pem -to joe@example.com \
 +
  -from me@example.com -subject "signed mail"|sendmail -t
 +
 +
This setup assumes that your local MTA provides a <tt>sendmail</tt> interface.  Obviously you should alter the email addresses accordingly, and the linebreak is for readabililty.
  
  
 
[[Category:X509]]
 
[[Category:X509]]
−
{{KeyDocs|responsible=Rob Harper|reviewdate=2013-05-14|accuratedate=(never)|percentage=0}}
+
{{KeyDocs|responsible=David Crooks|reviewdate=2018-01-16|accuratedate=2018-01-16|percentage=90}}

Latest revision as of 10:57, 22 February 2021

Certificate Overview

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

Many certificate applications and renewals can be carried out using the UK e-Science CA's 'CertWizard' tool (in Java); there is also a CA portal which uses javascript; it requires that the generated private key be stored in a file until the certificate is issued and they can be recombined and saved as PKCS#12.

There is also the 'PeCR' bulk system, which you can use to make requests for multiple certificates from the command line. It also supports SubjectAltName.

Systems administrators may also be interested in the commandline CertSorcerer tool.

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 -nocerts -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 e.g., CN=grid07.ph.gla.ac.uk. A personal certificate has the common name of the user, e.g., CN=graeme stewart.

See also Subject Alternative Name for host certificates.

Converting a Certificate back into P12 Form

 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.

Sending mail with a certificate

Normally you can use your MUA to sign mail (with your private key) so that the recipient can verify the signature with your certificate. This provides (1) integrity protection and (2) sender origin authentication. This normally works only with a personal certificate (or robot), which have email addresses in them.

However, there are two use cases for sending email on the command line. One is sending automated messages with a robot certificate which are signed with the robot certificate. The other is that your certificate has expired, and you cannot use CertWizard for some reason, so you need to send a signed PIN to the CA to renew the certificate.

Assuming that your unsigned message is in msg.txt, and your cert/key are in usercert.pem and userkey.pem respectively, 

 openssl smime -sign -in msg.txt -inkey userkey.pem -signer usercert.pem -to joe@example.com \
 -from me@example.com -subject "signed mail"|sendmail -t

This setup assumes that your local MTA provides a sendmail interface. Obviously you should alter the email addresses accordingly, and the linebreak is for readabililty.

This page is a Key Document, and is the responsibility of David Crooks. It was last reviewed on 2018-01-16 when it was considered to be 90% complete. It was last judged to be accurate on 2018-01-16.

Retrieved from "https://www.gridpp.ac.uk/w/index.php?title=Grid_Certificate&oldid=20766"