A brief guide on certificate and certificate management

Introduction

By "certificate", we mean an X509 digital identity certificate, an electronic or digital signature that a computer program or service may require prior to access in order to authenticate the person (e.g., you), computer or program that is trying to access it.

Now, somebody has to issue you a certificate, and somebody else must decide whether to accept your certificate when you present it. This implies that there must be a "chain of trust" such that the acceptor trusts the issuer. The issuer of a certificate is an organization called a Certificate Authority (CA). A CA will only issue you a certificate upon verification by somebody it already knows and trusts. The acceptors (e.g., grid services), in turn, maintain lists of CAs that they trust.

A little about the technology

Digital certificates are based on Public Key Infrastructure (PKI) technology, an arrangement which provides for third-party vetting of, and vouching for, user identities. PKI uses a pair of cryptographic keys (public and private) to encrypt and decrypt information securely. To be precise, an X509 credential consists of two parts, the public certificate (which includes a public key) and a private key.

A central principle to this technology is that the person requesting a certificate generates the public/private key pair and the private key stays with that person and never shared or made available for others to copy it. Private keys are usually encrypted so that only the owner, who knows the passphrase for the encryption, can use the private key. By keeping the private key private, communications to third parties can be trusted as having originated with the holder of the private key.

Any piece of information cryptographically signed with the private key can be verified with the public certificate (using its included public key). In turn, the public certificate is cryptographically signed by the CA so that when the CA is trusted, the recipient is assured of the identity of the person holding the private key.

Who and what needs a certificate?

Certificates can pertain to different types of End Entities: persons, hosts and services, and CAs. Host and service certificates are used to authenticate hosts and services to other grid- and web-related programs, hosts and services. Personal certificates are sometimes called grid certificates because standard grid software requires authentication via certificates, but use of certificates is not restricted to grid computing. Other common uses include signing email messages and administering/accessing restricted web sites.

Uses of a PERSONAL certificate in Grid systems

The primary uses of certificates in Grid systems is for initiating grid computing transactions. The credential is typically stored in your ~/.globus directory, the public certificate in a file called usercert.pem and the private key in a file called userkey.pem. To get one of these credentials it is most convenient to use the comandline tools in the cert-scripts package mentioned below.

Methods for getting a personal certificate

To get one of these credentials it is necessary to follow the instruction provided by your national Certification Authority.

Commonly, the public/private key pair is generated in your web browser and the signed certificate, when issued, is downloaded into your (same) web browser, matched with the private key and then can be used to authenticate with SSL web sites. Depending upon your client you may or may not have to export your credential into a PKCS12 file from your web browser and convert PKCS12 format credentials to PEM format files for globus.

Methods to convert a PKCS12 file

We show the stages one should follow in order to convert your PKCS12 personal certificate to PEM files. We assume you have a valid PKCS12 certificate (.p12 file) under a .globus directory.

Create and enter in .globus directory:

griduser> mkdir .globus
griduser> cd .globus/

check for your pkcs12:

griduser> ls -la
total 12
drwxr-xr-x  2 griduser griduser 4096 2007-12-20 17:15 .
drwxr-xr-x 56 griduser griduser 4096 2007-12-20 16:20 ..
-rwx------  1 griduser griduser 3824 2007-11-06 16:41 cert.p12

Create your userkey.pem file:

griduser> openssl pkcs12 -nocerts -in cert.p12 -out userkey.pem
Enter Import Password: (insert your certificate password)
MAC verified OK
Enter PEM pass phrase: (insert your Enter PEM pass phrase)
Verifying - Enter PEM pass phrase: (reinsert your Enter PEM pass phrase)

Create your usercert.pem file:

griduser> openssl pkcs12 -clcerts -nokeys -in cert.p12 -out usercert.pem
Enter Import Password: (insert your certificate password)
MAC verified OK
griduser@gridx:~/.globus$ 

Change the .pem files permission, in particular:

griduser> chmod 400 userkey.pem 
griduser> chmod 644 usercert.pem 
griduser> ls -la
total 20
drwxr-xr-x  2 griduser griduser 4096 2007-12-20 17:28 .
drwxr-xr-x 56 griduser griduser 4096 2007-12-20 16:20 ..
-rwx------  1 griduser griduser 3824 2007-11-06 16:41 cert.p12
-rw-r--r--  1 griduser griduser 1770 2007-12-20 17:28 usercert.pem
-r--------  1 griduser griduser 1915 2007-12-20 17:25 userkey.pem

Tips on certificate management

Sometimes it is necessary to extract some relevant information from a certificate. You can operate as follows:

Print certificate validity dates:

griduser> openssl x509 -in thecertificate.pem -noout -dates 

Print Certificate Subject

griduser> openssl x509 -in thecertificate.pem -noout -subject

Print Certificate Purpose

griduser> openssl x509 -in thecertificate.pem -noout -purpose

Print Certificate full text

griduser> openssl x509 -in thecertificate.pem -noout -text

Print Certificate issuer

griduser> openssl x509 -noout -in thecertificate.pem -issuer

Print Certificate hash value

griduser> openssl x509 -noout -in thecertificate.pem -hash

Print Certificate MD5 fingerprint

griduser> openssl x509 -noout -in thecertificate.pem -fingerprint

Change private key password

griduser> openssl rsa -in theprivatekey.pem  -des3

-- TaffoniGiuliano - 12 Aug 2008