About Certificates and Public-Key Infrastructure

What is a certificate and what is it used for?

Let's start simply: By "certificate" we mean a digital identity certificate. A personal certificate identifies a person. Some trusted authority (more on this later) says: "I, being a trusted authority, certify that the person presenting this certificate is so-and-so." How does it work? The trusted authority relies on somebody it knows and trusts to know and trust the person who wants a certificate. Once it gets assurance of the person's identity, the authority bundles into a document known as a "certificate" the following information: a description of who the person is, who it (the authority) is, an identifier that they give to the person, and an electronic signature of all of these items. Along with a certificate, the person gets a device to encrypt and decrypt information. (Read more...)

The file containing your certificate and this device gets imported into your browser configuration, then when you try to access a private or otherwise "strengthened" computer service from your browser, the certificate identifies you to the service, and allows you to communicate with it securely. You can also use your certificate in your email client to send and receive signed and/or encrypted email messages.

Who are the "trusted authorities"? Certificates are issued by Certificate Authorities (abbreviated as CA). There are many CAs in the world, and a given service recognizes certificates issued by only those CAs it has been configured to trust.

Certificates can pertain to different types of entities: persons, hosts and services, and certificate authorities, so a more complete definition would say that a certificate is used by a computer service prior to access in order to verify the identity of the accessing entity.

Below, we discuss personal certificates and host/service certificates, and what you can use them for. Most people only need a personal certificate.

For those of you who want to know more:

• Helpful terms and concepts.
• Certificates implement Public Key Infrastructure (PKI).
• How do certificates relate to SSL?
• Take a look at David Youd's short, very informative cartoon intro to digital signatures and trust chains. It is well presented and easy to read.

Personal Certificates

Certificates for people are called personal certificates. Most people only need this kind. Depending on what you want to do, you may need to get your personal certificate from a particular CA. To be eligible for a certificate from a given CA, you need to be affiliated with one of the organizations it handles. For Fermilab users, the two available CAs are KCA and DOEGrids:

• To get a KCA certificate from Fermilab you need to have valid Kerberos credentials in the FNAL.GOV domain.
• To get a DOEGrids certificate, you must be affiliated with a DOE laboratory or project.

You may possess only one valid personal certificate at a time from a given CA. You may possess valid personal certificates from multiple CAs. You can use your personal certificate(s) in multiple applications.

The table below lists uses for KCA and DOEGrids personal certificates that Fermilab users are likely to encounter.

Host and Service certificates

Host and service certificates are used to authenticate hosts and services to other grid- and web-related programs, hosts and services. KCA certificates CANNOT be used for this purpose; use DOEGrids. Both ends of the connection need to trust the DOEGrids CA for authentication to succeed.

CA Certificates and Chain of Trust

Somebody has to issue you (or your host or service) 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, abbreviated CA. A CA, it turns out, also has its own certificate, called a CA certificate, in many cases issued to the CA by a higher-level CA. The acceptors (e.g., grid, web services, email clients) maintain lists of issuers (CAs) that they trust. In order to accept your certificate, the application has to find the corresponding CA certificate in its list, and that CA certificate's higher-level CA certificate if necessary, and so on, until it reaches the "root" CA certificate. Hence the chain of trust.

For optimal use of any application in which you use a personal certificate (e.g., to avoid annoying popups and possibly the occasional refusal of service), the CA's certificate should be installed in the application ahead of time to establish the trust chain. Some combinations of browser and remote site will not work unless the CA certificate chain is installed.

Notes:

• Installation of the CA certificate is not mandatory in a browser, just recommended.
• For signing/encrypting email, CA certificate installation in the email client is mandatory.
• For Windows users in the FERMI domain who use Microsoft tools (Internet Explorer, Outlook, Outlook Express), the collective domain updates take care of installing and updating the KCA CA certificate in these applications for you.
   

Do I need a certificate? If so, what kind?

First of all, do you need to accomplish any of the following tasks?

• Access a restricted website (requires Kerberos authentication)
• Access a restricted website (requires DOEGrids certificate)
• Send signed and/or encrypted email
• Exchange encrypted email
• Run a grid job
• Administer a restricted website/web server
• Administer a computer running grid software

If so, the answer is "yes". They all require a personal certificate; only the last two require a host/service certificate in addition.

Now, which "brand" of personal certificate do you need, KCA or DOEGrids? Consult the table under Personal Certificates that lists common uses for each to see which is better suited to your needs. You may want one of each.

To administer grid resources or a web server, also see the DOEGrids host/service certificate table.
 

Certificate Authorities

At Fermilab, we currently recognize two different "brands" of certificate (where a "brand" corresponds to a CA, and each "brand" may pertain to any type of entity). They both use Public Key Infrastructure (PKI) based on the X.509 standard. One "brand" is issued by Fermilab and is related to Kerberos authentication (KCA), the other is issued by the DOE (DOEGrids CA). For many applications, you can use either "brand", however some applications require either one or the other. Read more about the CAs .

Fermilab-specific KCA

Since Fermilab has a sitewide Kerberos credential system, we are able to tie that infrastructure to PKI to create certificates for all our users. We can generate short-lived (~7 days) PKI certificates that are useful for a number of purposes, e.g., grid work and web authentication. We can also generate grid proxies from the certificates.

The system that implements this is called the "KCA" (for Kerberized Certificate Authority) and comes from work done at the University of Michigan. A KCA X.509 certificate, issued by Fermilab's KCA is tied to the user's FNAL.GOV Kerberos principal, and requires that he or she possess current, valid Kerberos credentials. The KCA certificate lifetime is typically seven days, based on the maximum renewable lifetime of Kerberos credentials. The KCA certificate must therefore be renewed frequently. Due to this short life-time, KCA certificates are not usable or not recommended for some purposes. In particular, signing or encrypting e-mail should be done with a longer-lived certificate, e.g., a DOEGrids certificate.

Unless you need a DOEGrids certificate, using KCA may be more convenient. You avoid the trouble of registering with a CA and protecting your private key.

A KCA certificate is required by some web servers at Fermilab and assorted other applications (e.g., Nessus scanner) for which users must be valid Fermilab computer users, i.e., must possess a valid, current Fermilab ID number and FNAL.GOV Kerberos principal and password.

DOEGrids

A second kind of certificate is tied to your affiliation with a DOE lab or project, is issued by the DOE's CA, called DOEGrids. Fermilab computer services that require public key certificates but that are open to a wider audience than just Fermilab people typically recognize the DOEGrids CA. In addition, a DOEGrids certificate is required for DOE-related grid computing, for access to many restricted web sites related to DOE labs and/or projects, and may be used to digitally sign outgoing email.

DOEGrids also issues host/service certificates.

KCA vs. DOEGrids Personal Certificates

• Both "brands" of certificates, KCA and DOEGrids, are based on PKI and are in X.509 format.
• KCA certificates are available only for holders of Fermilab Kerberos principals (with currently valid Kerberos password). DOEGrids certificates are available to people associated with DOE-funded projects and laboratories.
• KCA authenticates on the basis of your FNAL.GOV Kerberos credentials. DOEGrids authenticates based on a DOE affiliation and your sponsor's knowledge of your identity, obtained from having met you in person.
• KCA issues only personal certificates. DOEGrids issues both personal and host/service certificates.
• A KCA certificate lasts only as long as the maximum renewable lifetime of your Kerberos credentials (seven days). A DOEGrids personal certificate lasts one year.
• The uses for the two "brands" of personal certificates are listed in the table above.

How do I get a certificate?

We provide instructions for requesting certificates from both KCA and DOEGrids, and for both personal and host/service certificates:

• KCA Personal Certificate (Read about KCA certificates first)

• DOEGrids Personal Certificate (Read about DOEGrids certificates first)

• DOEGrids Host/Service Certificate

Now that I have a certificate, what should I do with it?

• Try out our test page to check that your certificate is properly installed in your browser. Installation should happen automatically as part of the process of getting your certificate.
• If the test fails, your certificate did not get installed properly. Look at the Troubleshooting section. You'll probably have to install it manually.
• Consult the table under "Personal Certificates" that lists common uses for KCA and DOEGrids personal certificates. The links given for each task take you to information on how to set up and use your certificate for that task.
• If you wish to use your certificate in mulitple browsers or other applications, see How to Import and Export (Backup) a Personal Certificate into and from Applications to find out how to export (save) your certificate to a file so that you can then import it into other applications.
• If you export your certificate, please read about how to protect your private key.
• If you plan to use Globus tools for submitting jobs to a grid (from Linux), convert your certificate and private key to PEM format (KCA or DOEGrids).

What security measures do I need to take ?

I want a little background first.

Ideally, any files containing your private key should be kept only on removable media. When you first export your certificate, copy it to a local drive that is inaccessible to the network, import it into applications as necessary, then remove it and any related files from your machine after you're done.

The certificate files that need to be protected include those with any of the following extensions (formats described below). You probably won't have all types; it depends on what you do with your certificate.:

.pfx, .p12, .key, .pem, .cer, .crt, .cert

Please follow these security guidelines with regard to your private key and related files:

• DO NOT copy it to or store it in AFS space.
• DO NOT copy it to or store it in a directory that is accessible to the network.
• DO NOT copy it to or store it in a directory that is accessible by anyone besides yourself.

How do I renew my certificate?

KCA Personal Certificate

It's not really a question of renewing the same certificate, but rather of getting a new one. To get a new one, follow the same instructions as for your initial certificate. First authenticate to Kerberos. If you created a shortcut to the "get-cert" command, it's quite quick and easy, e.g., for Windows, just click on your shortcut and enter your password. For Linux run get-cert-sh -i; for Mac, run kx509, kxlist, and openssl.

DOEGrids Personal Certificate

See How to Renew a DOEGrids Personal Certificate

DOEGrids Host/Service Certificate

Currently host/service certificates are not renewable. The easiest way to get a new one when it expires is to use the (saved) original certificate request file (the .req or .REQ file) made by OpenSSL and to use it again to request a new host/service certificate.

How do I revoke my certificate?

For a KCA certificate -- No mechanism exists at this time. Since the KCA is a short-lived certificate (at most 7 days), it was decided that renewal was unnecessary. The KCA has a Certificate Revocation List (CRL) so that applications which need to find a CRL have one to reference, but the CRL is empty.

For a DOEGrids personal certificate: Go to the User Certificate Revocation page and follow the instructions. You can get to the same page by going to the https://pki1.doegrids.org/ page; select the Revocation tab.

For a DOEGrids host/service certificate, open a helpdesk ticket requesting that the RA (resident agent) revoke it. Provide identifying information for the certificate, e.g., the subject DN and validity dates.

What information is in a PKI X.509 certificate?

The specific fields included in a certificate varies from CA to CA. Here is a list of information that is included in virtually all personal certificates; it is not an exhaustive list:

• Subject of the certificate (the person or other entity to whom it was issued)
• Subject's public key
• Issuer (the Certificate Authority)
• Serial number (an integer that is unique to all certificates signed by the CA that issued this certificate)
• Extensions (subject's email address, subject type, policy information, etc.)
• Validity Period (start and end dates)
• Signature algorithm (the name of the algorithm used for signing; this is used to test for tampering)
• Netscape Cert Type (e.g., SSL client, SSL server, S/MIME, etc.)
• Key usage (what uses can the certificate be applied to)

Troubleshooting

If the browser test fails for a personal certificate ...

• Check that your certificate is installed properly. On the import/export instruction page, find instructions for your browser and follow them to the point where you can see if your certificate appears.

The browser test succeeds, but other sites fail ...

• Check that the trust chain is in place: Install the CA certificates if not yet done (this step is not always necessary, but may be for the site you want)

Your KCA certificate doesn't prompt you to renew it ...

Your certificate has been compromised (how do you know?) ...

• Revoke it and request a new one.

I forgot my encryption password and can't reimport my exported certificate ...

• Re-export it from the initial browser, and give it a new encryption password.

Trouble with signing/encrypting email messages.

The certificate store and file format

When your certificate is imported into a browser, it gets put in a location called a "certificate store", where the browser can access it. Depending on your OS, your browser and your email client, your email client may be able to access the certificate from the same certificate store. There's no need to import your certificate into more than one of the applications that share a store. The following pairs of applications share a store:

• Microsoft Internet Explorer and Outlook (or Outlook Express)
• Mozilla browser and email client
• Netscape browser and email client
• Macintosh native email clients and browsers use the keychain files

Firefox and Thunderbird do not share a store.

The file formats are:

.pfx

PKCS#12 format binary file on Windows, multi-part, contains certificate and private key

.p12

PKCS#12 format binary file on Unix/Linux/Windows, multi-part, contains certificate and private key

.key

often a binary file containing a private key

.pem

a Base-64 encoded file which may be a private key or an X.509 certificate, or some combination.

.cer and .crt

binary format certificate file

.cert

certificate in either binary format or, more usually, text dump of certificate

Browsers require a binary certificate format called PKCS#12 whereas grid software, Globus in particular, uses PEM format. KCA and DOEGrids issue certificates in PKCS#12 format. The PKCS#12 file contains both your certificate and your (encrypted) private key. The file extension is typically p12 if obtained through a browser on UNIX and pfx on Windows. If you plan to use grid software, you'll need to convert the format to PEM; instructions are specific to the CA: see KCA or DOEGrids.

Within your certificate, you are identified uniquely by your "distinguished name" or DN. A DN has several components which identify the issuing CA, your organization, you (and possibly other entities).

The KCA certificate format has Subject DNs of the form:

/DC=gov/DC=fnal/O=Fermilab/OU=People/CN=<your name> /UID=<your_principal>

e.g.,

/DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Joe Blow /UID=<joeblow>

The DOEGrids certificate format has Subject DNs of the form:

/DC = org/DC = doegrids/OU = People/ CN = <your name> <some 6-digit number>

e.g.,

/DC = org/DC = doegrids/OU = People/ CN = Joe Blow 123456

More information:

• David Youd's short, very informative cartoon intro to digital signatures and trust chains
• Everything you Never Wanted to Know about PKI but were Forced to Find Out (Peter Gutmann, U of Auckland). (PDF format) You don't actually need to know it all, but it's there if you're curious!
• The Globus Toolkit 4.0 Security Glossary defines many terms that pertain to certificates.
• Overview of Grid Computing (Fermilab)
• VOMRS v1_2 manual, Chapter 3 (Fermilab)
• http://www.nordugrid.org/documents/certificate_howto.html
• http://en.wikipedia.org/wiki/Public_key_certificate
• http://www.dartmouth.edu/~pkilab/pages/Using_PKI.html
• http://www.dartmouth.edu/~pkilab/pages/Using_SMIME_e-mail.html
• http://www.marknoble.com/tutorial/smime/smime.aspx
• http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/
• http://computer.howstuffworks.com/encryption.htm