If you have used any SSL encrypted services on the servers that I administer, you have probably encountered errors related to untrusted certificates. These errors can be silenced by teaching your browser to trust the so-called "certificate authority" that I have created. This is a sort of "master certificate" that I use to sign the certificates granted to individual servers, such as "webmail.singingtree.com", "imap.dci.pomona.edu", etc.

• Click here to download the singingtree CA certificate.
• Click here to download the current Certificate Revocation List (last changed 25 Aug 03)

Now that you've clicked on the link, your browser is probably doing something funny. If you aren't sure how to proceed, I have supplied some basic instructions for Mozilla and Netscape or Internet Explorer.

Note that I did not say that downloading this file will make you more secure, only that it will silence the errors. It is possible to use this certificate to derive some meaningful security benefits, but you must understand and use it properly. Specifically, you must verify the certificate fingerprints with me in person or by telephone. Please read on for an explanation, or if you aren't interested, you have no security anyway--there's no sense worrying about it.

SSL (also called TLS) is a complicated set of protocols that are intended to protect sensitive information from being intercepted as it travels across the Internet. When your browser connects to a URL that starts with https://, it starts an SSL "session", the padlock icon appears at the bottom of your window, and all further information exchanged between you and the Web server is encrypted. This makes it difficult, maybe impossible, for an eavesdropper watching the conversation to understand its content.

This is nice, but it does not address a subtler and more dangerous security threat: How do you know that the server at the other end is actually the one you meant to connect to? There are ways that I could trick your computer into thinking that my evil server is "www.wellsfargo.com". If I have set up my evil server to look exactly like the real Wells Fargo site, which is also pretty easy, you would not know anything had gone wrong until after you had tried to log in, revealing your account number and password.

The people that designed SSL tried to solve this problem with so-called "server certificates". Basically, a server certificate is a unique piece of identifying data that another server cannot forge. This means that I, the evil hacker, can't simply copy the certificate from the Wells Fargo server along with everything else.

But, this only brings us to another problem, which is that we still don't have a way to know that the unique certificate presented by the server actually belongs to the rightful owners of wellsfargo.com. (Confused yet?) To solve this problem, the designers of SSL invented "certificate authorities". These are supposedly trustworthy corporations that act kind of like a notary public for SSL certificates. They are supposed to look at your credentials and make sure that you really are who you say you are, then they "sign" your server certificate. Finally, browsers are distributed preprogrammed to trust server certificates signed by one of these large corporate Certificate Authorities, which forms the foundation for the whole rickety pyramid scheme of trust.

My server certificates are not issued by one of the large, official Certificate Authorities that browsers are preprogrammed to trust. Instead, I have created by own (not very authoritative) Authority which is represented by the file at the top of this page. Since the number of people involved is fairly small, we can achieve decent security as long as you verify that the Certificate Authority file you downloaded has not been tampered with.

To be sure that the file you just downloaded is really the one that I created, you have to compare the certificate's "fingerprint" with another, non-Internet source of information. Here are a few ways this could be done:

• If you know me, and would recognize my voice on the telephone, you can call me to compare fingerprints by reading them aloud.
• If you are in the area of Claremont, California, you can retrieve a hard copy of the fingerprints from me in person, either at my office at Pomona or at home.
• If you can do neither of these things, you can send me your mailing address and I will mail to you (as in real, paper mail) a hard copy of the fingerprints, which you can at least verify was postmarked in Claremont. Obviously this method isn't as difficult to fool as the other two, but you would be tipped off that something is wrong if you receive two or more letters with different information.

This rant has been removed to a new site consecrated for just such rants.

The first window will say, "You have been asked to trust a new Certificate Authority".

• Click View to see the certificate details, pictured at left. SHA1 and MD5 fingerprints are displayed at the bottom of the window.
• Verify that the fingerprints match those you have received from a non-Internet source (see above)

Having satisfied yourself that the fingerprints are correct, do the following to install the certificate:

• Click Close to dismiss the Certificate Viewer window
• Check the box that says "Trust this CA to identify web sites".
• Click OK.

The certificate installation process on Internet Explorer 5 is needlessly long and complicated:

• First, choose "Open from its present location" when prompted to save the certificate file.
• In the certificate viewer window (pictured at left), it is possible to find the fingerprint under the "Details" tab. But, it will be buried at the end of a list of uninteresting properties, only the SHA1 fingerprint is visible, and it is called a "thumbprint".
• Continue by pressing the button labeled, "Install Certificate".
• You will now be presented with a useless "Wizard" that is supposed to help you figure out where to save the certificate. Your answers to none of these questions matter.
• Keep pressing Next until you arrive at the dialog box pictured at bottom left, which asks you whether you want to install the certificate. (You've only clicked about 15 times so far, so Windows can't be sure you really want to do something).
• Check that the displayed fingerprints match the copies that you retreived from a non-Internet source (see above), then click Yes to install the certificate.

The following should help with programs that use the OS X certificate storage, such as Mail.app and probably Safari.

• Save the certificate file (from the link at the top of this page) somewhere, such as the Desktop.
• Open Keychain Access (in Applications :: Utilities)
• Select the X509Anchors keychain. This will probably require an administrator username and password.
• On the File menu, click Import, and select the singingtree certificate file. You should now see the new certificate in the CA list, like so:

• Double click the singingtree certificate. It should display the details, including the warning that says, "This certificate is not in the trusted root database."
• Go to the bottom and expand the Trust Settings triangle. Set the "When using this certificate" box to "Always Trust".
• Set the SSL box to "Always Trust." None of the rest of the settings should ever matter, so if you are feeling paranoid, set them all to "Never Trust" or "Ask Permission.".