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