"What is a Certificate?" and Related Topics
What is a certificate and what is it used for?
A certificate is a mechanism used to verify an identity on a computer and/or over a computer network. You might call it a "digital identity certificate". Certificates can identify different types of entities, e.g., persons, hosts and services. Many restricted-access computer services are configured to identify potential users via certificates, and allow or deny access according to the certificate contents. Typical computer services that require certificate identification by users (persons) include secure web sites, grid services, and email signing and encryption.Most people only need a personal certificate.
At Fermilab, most restricted services currently recognize one or both of two "brands" of certificate: the Kerberos Certificate Authority (KCA) is run by Fermilab and is related to Kerberos authentication. The other, the DOEGrids Certificate Authority, is run by the DOE.
A personal certificate identifies a person, and is issued by a trusted authority (called a Certificate Authority, or CA; more on this below). The authority 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 verify the identity of the person requesting 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, a unique identifier that it gives to the person, and an electronic signature of all of these items. Along with a certificate, the person gets a program to encrypt and decrypt information. Read more about security concepts and encryption.
The file containing your certificate and this device gets imported into your browser configuration. When you try to access a private or otherwise "strengthened" computer service from your browser, the certificate identifies you to the service, and, if trusted, 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 organizations called Certificate Authorities (abbreviated as CA). There are many CAs in the world. To be eligible for a certificate from a given CA, a person needs to be affiliated with one of the organizations it handles. Furthermore, a given service recognizes certificates issued by only those CAs it has been configured to trust. Read about CA certificates and the chain of trust.
At Fermilab, most restricted services currently recognize one or both of two CAs, (and certificates from either may pertain to any type of entity), both of which implement Public Key Infrastructure (PKI) based on the X.509 standard. One CA, the Kerberos Certificate Authority (KCA) is run by Fermilab and is related to Kerberos authentication. The other, the DOEGrids Certificate Authority, is run by the DOE.
For those of you who want to know more:
First of all, do you need to accomplish any of the following tasks?
Now, which do you need: a Fermilab Kerberos or a DOEGrids personal certificate? 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 a web server or grid resources, also see the DOEGrids host/service certificate table.
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 a Kerberos or a DOEGrids personal certificate. Most Fermilab users are eligible for both:
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 Kerberos and DOEGrids personal certificates that Fermilab users are likely to encounter.
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.
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 (a specialized service certificate), in many cases issued to the CA by a higher-level CA. The acceptors (e.g., grid services, 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.
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.
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.
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:
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:
Firefox and Thunderbird do not share a store.
The file formats are:
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> /CN=UID:<your_principal>
/DC=gov/DC=fnal/O=Fermilab/OU=People/CN=Joe Blow /CN=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>
/DC = org/DC = doegrids/OU = People/ CN = Joe Blow 123456