1. What is a root certificate?

A root certificate is a digital document that contains the public key portion of a certificate and that is self-signed. When a certificate is self-signed, it means that the name in the Issuer field is the same as the name in the Subject Field.

Creating a root certificate is a two step process. The first step involves the generation of the root cerificate’s public and private key pair. The second step is using the private key to create a certificate that contains the public key and the name of the institution.

In the case of the CREN CA root, for example, the root certificate is issued to the CREN CA by the CREN CA. The issuing of a root certificate is an important occasion that should be witnessed in some way.For the initial set-up of the CREN CA on November 17, 1999 there was a public ceremony witnessed by a group of nine people who gathered at MIT.

2. What about the process in setting up a campus CA? Do campus CAs also issue a root certificate?

Not usually. A campus does the first step, generating a campus specific public and private key pair. However instead of signing its own certificate, the campus creates a "Certificate Request Message." This message is similar to but not the same as a certificate. It contains the public key of the institution generated along with the name of the institution. It is then signed by the private key.

This Certificate Request Message is then sent to a Certifying Authority (which itself may be a root CA or a non-root CA) which uses the Certificate Request Message to create a certificate for the institution signed by its (the CA) key.

In this case the subject name of the institution+s certificate will be the name provided by the institution in the Certificate Request Message and the issuer name will be the name of the CA itself.

Some institutions may start out by issuing their own root certificate and then later obtain a certificate from a CA such as CREN. This can be done with either the same key or a different key.

3. It sounds as if there is more than one type of certificates? How many types are there?

The types of certificates can be almost unlimited. The types that we talk about mostly are of three types:

1. The root certificate of a hierarchy, such as CREN, VeriSign, GTE CyberTrust, etc
2. The campus Certifying Authority certificates, such as those issued to MIT, Georgia Tech, etc
3. The client certificates issued to users, such as faculty, staff and students.

Note: The certificate profile of each type of certificate is somewhat different. Thus, when discussing a certificate profile, it is useful to ask the question of a particular type of certificate. For example, if asking whether or not a certificate should include a url for finding a certificate policy, certificate practices statement, or certificate revocation list, it is good to ask it in the context of specific certificate. An example of this type of question is, "Should the profile of a campus CA certificate contain a url for a certificate revocation list?"

4. What is a trust path? Is that related to hierarchical root certificates, campus CA certificates and client certificates?

Applications are configured to trust some number of pre-configured roots. When presented with a certificate to verify they attempt to build a "path" of certificates from the presented certificate to one of the trusted roots.

For example JSTOR trusts the CREN Root Certificate. When presented with a client certificate issued by the University of Minnesota, the JSTOR server can see that it is signed by the University of Minnesota’s certificate. Using the University of Minnesota’s public key (obtained from its certificate) it verifies cryptographically the presented client certificate. It then proceeds to verify the University of Minnesota’s certificate using the CREN Root Certificate, which is listed as the issuer of the University of Minnesota’s certificate. It has now found a trusted root and the trust path is established.

5. I understand that a set of roots come pre-installed in my Netscape or Internet Explorer browser. Why is that important?

Yes, browsers generally have upwards of 75 roots pre-installed in the security module of these browsers. These roots are from vendors, such as VeriSign, Entrust, Digital Signature Trust, etc. This is important when a user uses an application on a server that has been secured with a web server certificate.

In these cases, users encountering these web servers are probably unaware that a trust dialogue is initiated that checks that a root certificate matching the web server certificate is in a user’s browser.

6. What about using web server certificates from CREN? Do my users need to download and install the CREN root into their browsers for those applications to work?

Yes, when a campus uses web server certificates from CREN to secure web server applications, users will need to download and install the CREN root into their browser. This process is fast and easy. It is similar to downloading a plug-in for other web applications. Campuses often just put a link on their web server to link directly to the url for the downloading of the CREN root.

See the one-pager on the downloading of the CREN root for more information about this process and some background information about how users can validate roots, if desired.

Please send comments/suggestions to cren@cren.net

1. What is the CREN root certificate?

The CREN root certificate is a digital document containing the public key portion of the CREN self-signed certificate.

2. Why do I want to know how to load the CREN root into my browser?

You want to know how to load the CREN root into your browser because it provides you with some control over which servers you authorize your browser to interact with. Your browser comes preloaded with dozens of root certificates in the Security Module. These certificates "certify" servers to your browser.

3. Is it hard to load the CREN root into my browser?

No. Downloading the CREN Root Certificate into your browser is very straightforward, similar to installing a plug-in. Here is how to do it.

• At www.cren.net, click on "Download the CREN Root to your Browser" link.

• In Netscape, the browser checks to see if the CREN root is already in your browser. If it is not, the browser presents a series of dialogue boxes that asks if you want to install this certificate into your browser Security Module. After clicking through the dialogue boxes, the Netscape browser presents a dialogue box that allows you to create a "User Friendly" name for the certificate. (We recommend that you use the name "CREN CA.").
• In Internet Explorer, the browser also presents a series of dialogue boxes. The one potentially confusing dialogue box presents the choice of opening the certificate file from the current location or saving it to disk. The recommended choice is to select the choice, "Open this file…." and click OK. Then click the "Install Certificate" button in the next window.

After you install the CREN CA root in your browser it appears in your list of CA Signers. To see the certificate, here is what to do:

• In Netscape, click on the Security Icon in the toolbar, click Signers and find the CREN CA in the list. You can then choose to "Verify" or "Delete" the certificate. An "Edit" button also allows you to check to enable the use of this certificate for three purposes, certifying network servers, certifying e-mail users, and certifying software developers.
• In Internet Explorer, click on Tools, Internet Options, Content and Certificates and choose the Trusted Root Certification Authorities. Look for the "Education and Research Client CA". This is the name assigned to the CREN Root in IE. To give it a "Friendly Name", you would have to click on the Details tab and choose Edit Properties. This is also where you will be able to change the intended use of this certificate.

Just as it is easy to see the CREN Root Certificate in your browser after you have downloaded it, it is also possible to verify that the certificate is the valid CREN root certificate. The way to do this is to check its fingerprint or thumbprint against the publicly distributed one.

6. Is the thumbprint or fingerprint of the CREN root Certificate posted anywhere else?

The best way to ensure that bogus certificates do not proliferate is to post the thumbprints/fingerprints of root certificates broadly. Thus, the thumbprint /fingerprint of the CREN root are or will soon be posted on other higher education sites.

7. Can I see screen shots of this process anywhere?

Yes. There are detailed step-by-step instructions with screen shots for this process for Internet Explorer and Netscape posted at www.cren.net/crenca. www.cren.net/crenca 8. Do users need the CREN root certificate installed in their browsers for the access of JSTOR using digital certificates?

No, the JSTOR server will have the CREN root certificate installed. Users will only need their digital certificate that has been issued to them by their institution and their digital certificate passphrase. However, users may need the CREN root installed in their browsers for using other web applications.

Please send comments/suggestions to cren@cren.net