Loading the RULink Project CA Certificate

This page allows you to add the RULink Project to a list of known "certificate authorities." Doing this will let you use several secure web sites within Rutgers without getting security warning messages from your browser.

Note: The main RULink web pages currently use a commercial certificate. However certain internal portions of the RULink project do use certificates signed by this CA. RULink may change to using our own certificates for everything in the future.

How to be sure you're talking to the genuine RULink CA

This page itself should be accessed using SSL. That is, the URL shown in the "location" box should start with https://rulink.rutgers.edu. (Make sure it is https:, not http:) It should load without any warnings.

https://rulink.rutgers.edu currently uses a commercial certificate issued by Thwate. That gives at least some assurance that you have the real RULink.

If you want to be very careful, Netscape, Mozilla and the Windows version of IE have a little "lock" icon somewhere at the bottom of the window. If you click on it, they will let you look at the certificate. The certificate should be for the site rulink.rutgers.edu. It should be signed by Thwate Consulting. [Some other browsers have the lock icon, but clicking it doesn't do anything.]

Why would you want to load the RULink CA Certificate?

Many Rutgers web sites have purchased certificates from major commercial certificate authorities, such as Verisign or Thwate. That lets you use the sites without getting a warning message. However it costs several hundred dollars a year for the site to buy a commercial certificate.

The RULink Project provides a free alternative. However it's slightly less convenient for users, because the users must load the RULink Project's certificate. This page allows you to do that.

NOTE: You only need to load the RULink Project certificate once per browser. That will handle any site at Rutgers that uses the RULink Project to sign their certificate. This certificate lasts for 10 years. After that, you will need to load it again.

You may ask: so what's so bad about getting warning messages?
The whole point of digital certificates is to let you make sure you are talking to a legitimate site, and not to some hacker that is pretending to be the site you're looking for in order to steal your credit card number or password.
If you ignore warning messages, you may not be talking to the site you think you are. For this reason we urge users not to ignore security warnings.

How to load the RULink Project CA Certificate

For Internet Explorer, Netscape, and Mozilla, you can load the RULink Project CA by clicking the link below.

Load RULink Project CA Certificate, but check below for browser-specific notes before doing this.

This should trigger a dialog that will allow you to load the certificate into your brower's list of known authorities.

The dialog is different for different versions of the browser. It's not possible to document all of them, but see notes below for some of the common versions.

Testing to see whether it worked

WARNING: In the check below, if you get a warning message, you should not continue. If you continue, you may cause your browser to add the test page to its list of exceptions. In that case it's no longer a valid test of the Certificate Authority.

Browser-specific notes

Specific versions are listed, because those are the ones tested. Other versions of the same brower will probably work similarly.

General Windows Note

The instructions in other sections will result in the certificate being loaded into a certificate store that is associated with you. Other users using the system will need to load it themselves. If many users need it, or if you're running services on the system and they need the certificate, you probably want to load it into the system-wide certificate store. Here is the way to do that:

First go to the "Load RULink Project CA" link above and save the certificate to a file.
From the "Start" menu, choose "Run..". In the box, type "mmc" and click "OK." This will give you the "Microsoft Management Console."
In the MMC, pull down "File" and choose "Add/Remove Snap-in". Add the Certificate Management snap-in to "Computer Account" on "Local Computer".
The Console will now show "Certificates (Local Computer)". Expand that and right click on "Trusted Root Certificate Authorities". From the popup menu choose "All Tasks" and then "Import".
You'll now have the Certificate Import Wizard. Follow it through, loading the certificate from the file you saved in the first step.

Netscape and Mozilla

(I tested Netscape 7 and Mozilla 1.4 on OS X, and Netscape 4.8 on Windows. But I expect all versions of Netscape and Mozilla to work.)

When you click on the link above, you'll get a box giving you an option of several things for which you might trust the CA. I recommend choosing them all. Older versions of Netscape have a longer dialog, but you give the obvious answers.

Internet Explorer on Windows

(I tested Internet Explorer 6.)

Clicking the link above will give you a box asking whether you want to save or open the file. Say "open". You will next get a box asking whether you want to install it. Say "install certificate". This will get you the certificate install wizard. Take the defaults, and confirm that you do want to add it to the root store.

Older versions of IE don't give as complex a dialog, but you still want to say "open" when it asks save or open. In some versions you'll get a single box listing types of usage, with a general "enable certificate". I would enable all types of usage.

Internet Explorer 5.2.2 on Mac OS X

(I tested only version 5.2.2 on OS X, but there are indications that the same comments apply to all version 5's on the Mac.)

This works properly when you click on the certificate above. However you probably don't want to do it. Although it works, it will have an unfortunate sideeffect. In the process of loading the certificate, IE will require you to create a password for accessing certificates. You'll need to type the password the first time you access a secure site in any session (not just a site secured by RULink -- any site using SSL). This is enough of a pain that you probably don't want to load our certificate.

If you load the CA certificate on Mac IE, and decide later that you don't like typing passwords, you can get rid of it: Go into Preferences and choose security. Click on "Reset to defaults". This will delete all certificates that you have loaded, and remove the password.

Apple Safari

Apple's Safari version 1.0 does not have a facility for loading certificates. However you can still get the same result: Rather than having its own list of known authorities, Safari uses a system-wide list. So Safari users will want to load the RULink CA certificate into the system list.

There are two ways to do this. The simplest is to use Apple's Keychain Access utility. This is in Applications/Utilities. This will be called automatically when you open a certificate file. So here's the approach:

Save the RULink Project CA Certificate, text format, .crt file to a file, by right-clicking on the link and saving it to a file called cacert.crt. (Obviously you can use a different name. However the name should end in .crt, so that the system will recognize it as a certificate.)
Double click the file.
This will bring up the Keychain Access utility, with a box asking whether you want to add this. The box will have a list labelled "Keychain:" to let you select where it goes. I recommend putting it in the system-wide X509 Anchors. Two X509 anchors will be listed. One is your own, in ~/Library. The other is in /System/Library. You want the second one. For me it was the second on the list, and it was "X509 Anchors" rather than "X509Anchors", i.e. it had a space in it. But this could be specific to Panther. If you get the right one it will ask for a password. As far as I know there's no harm to adding it to the first one. The only difference is whether it applies just to you or the whole system. So if it doesn't ask for a password, I'd just exit Keychain Access, double-click the file again, and choose the other one.

The other approach uses the command line. It's slightly longer, but at least makes sure you know which of the X509 Anchors you're using. Here are the instructions:

Save the RULink Project CA Certificate, text format to a file, by right-clicking on the link and saving it to a file called cacert.txt. (Obviously you can use a different name. However if you do, you'll need to use that name instead of cacert.txt in the instructions below.)
Open a terminal window
Do the following commands in the terminal window:
- more cacert.txt
- cp /System/Library/Keychains/X509Anchors ~/Library/Keychains
- certtool i cacert.txt k=X509Anchors
- sudo cp ~/Library/Keychains/X509Anchors /System/Library/Keychains/X509Anchors

The purpose of the "more" command is just to make sure you have the file where you think you do. By default it probably downloads to your Desktop. Try "more Desktop/cacert.txt". It that's where it is, you can do "cd Desktop" to move to the Desktop.

Sudo will require you to type the root password, or the password of a privileged user.

At least with OS X version 10.2.6, the last command gives you warnings about memory allocation errors. But it does work.

NOTE: You will need to exit Safari and restart it for this to take effect.

Other browers

Feel free to try the link for other browsers as well. Unfortunately some open-source browsers don't seem to support this kind of automatic loading of certificates.

For some other browsers, you may need to load the CA certificate yourself. Here it is in several different forms:

ca-bundle.crt is a file that seems to be present in some Linux distributions. It contains the certificates for all the standard CA's, in a single file. You can add ours at the beginning or end. (Order doesn't matter.) I've seen other installations of openssl where /usr/local/ssl/cert.pem is in the same format and needs the same change. To get PHP to access the server using SSL, you often need to modify /usr/local/etc/openldap/ldap.conf, and add the line

TLS_CACERT /usr/local/ssl/cert.pem

using the name of the file to which you added the certificate. This may be true for browsers based on openssl as well.

If you run a web server and want to use the RULink Project CA

We are willing to sign certificates for any department at Rutgers. This will let you avoid paying Verisign. But if we sign your certificate, you will want to get your users to come to this page to load our CA certificate.

You should generate a certificate signing request just as you would for a commercial authority. Email the request to rulink-ca@rutgers.edu.

Before signing the request, we will want to verify who it is from. While we aren't quite as formal as Verisign, we need better assurance than an email request. If you have registered a PGP key, please sign your request. Please identity the department you are with. We may well go through your main department office to get to you.

We strongly recommend generating certificates with a lifetime of a year. The CA cert has a 10-year lifetime, so your users won't have to reload it for quite some time. But it's safest to renew individual server certificates more often.

I attempt to run this service as medium assurance. That means that I need to identify the person requesting the service. Email is not sufficient. Neither is any service associated with a normal Rutgers netid and password, because netids and passwords are not managed at the medium assurance level. Normally I will make contact with you at your department's listed phone number, but if I know you, I may be able to use some other approach.

Our CA is not as secure as Verisign's, although we try to be careful. If you are handling credit card information, medical data, or other highly confidential information, we recommend using a commercial certificate.