Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Click here to return to the 'wow... never thought I would be flamed for trying to help' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
wow... never thought I would be flamed for trying to help
Authored by: simonlok on Jan 27, '03 11:17:43PM

Well... here is an attempt at watering down the tip.... hopefully this will help and I won't get even more flames for trying again.

First you kind of have to understand the concept of certificates. Each web server has a public key and private key. The private key is generally only accessible to the server administrators (and of course to the httpd process). The public key is supposed to be accessible to anyone. When you "sign" a public key, it becomes a certificate. Remember that a digital signature is nothing more than encrypting a hash with a private key so that anybody can "decrypt" it (called verification in this case) with the corresponding public key. The thing you need to keep in mind is who's private key is used in the signing... for web servers this is generally the private key of the certificate authority.

Most people use "well known" certificate authorities (e.g. Verisign or Thawte). However, this concept of being a "well known" certificate authority is arbitrary. Often this comes down to money. If you have a million bucks, you can pay Microsoft to have your personal public key included by default with Internet Explorer. Thus you become "trusted." This has absolutely nothing to do with you, everything to do with status quo. People like Verisign have made serious mistakes before by signing public keys of random people claiming to be big names (e.g. Microsoft).

Some technically savvy organizations have realized this is all a big scam, so they setup their own "certificate authority." For example, check out It is very easy to setup your own ca. You literally just run openssl and say "make me a keypair." All keypairs are technologically created equal (assuming algorithmic and key strength parity). The difference is primarily in policy. You "designate" this to be you "CA" key pair. Then you run the same openssl command to create a keypair for each secure server. You can then use openssl to "sign" each webserver keypair with your "CA" keypair. Want to know exactly what the commands are? Read this:

Okay, so now enters Safari. How the hell do you make this all work. Well, you need access to the CA public key. Where do you get that you ask? Well, it needs to be published by the administrator. This is usually on a website, with a phone number for you to call to verify the fingerprint over the phone or something like that. See the ColumbiaCA website above for an example. This public key typically comes in PEM or DER format. PEM format is the default openssl format, but unfortunately our friends are Microsoft do not allow PEM to be imported into IE for Mac easily. DER on the other hand imports easily, but it's a binary format and that sucks because, well, it's a binary format.

I hope this helps. I hope I don't get any more flames for trying to help. Anyway, good luck.


[ Reply to This | # ]
wow... never thought I would be flamed for trying to help
Authored by: bts on Mar 21, '03 12:26:46PM

Thanks for the pointer; this works fine for Safari, but I'm looking for information on how to add root certificates to, Camino, and other programs using the SecureTransport framework. Any ideas?

[ Reply to This | # ]