Pamela's SSL Certificate Primer

If you aren't familiar with how SSL certificates work, setting up a website to use such a certificate can be a nightmare! This page is intended to get you through the ordeal without tearing your hair out. If you find that there was information missing from this primer that would have been useful, please consider editing the wiki to put that information in, so that future users can benefit from your pain.

Basics of SSL Certificates

SSL Certificates are really just a collection of characters that contain a lot of crypto gook, all created with the goal of ensuring that people can communicate with you as securely and reliably as possible. When you apply for a certificate, two different blobs of information are created - what are known as a public key and a private key. Once your web server has access to your public and private key, those keys can be used to offer a new protocol, called "https" (ie http over ssl)**.

Via the https protocol, your public key is given away to anyone who might want to talk to you. If your public key is used to encrypt data and send it over the wire, the only way that data can be decrypted is if your private key is applied. This makes your private key incredibly valuable -- anyone who has it can decrypt and read web communications intended only for you.

Private and public keys are 'signed' by a Certificate Authority, or CA. When a CA signs your certificate, data is embedded into your certificate that points to the CA's certificate -- thus, a browser (or other program) can decide whether they trust your certificate by checking out who signed it. Sometimes, the certificate used to sign your certificate is in turn signed by yet another authority -- in this way, certificate validation can involve traversing "chains" of certificates. Eventually, the browser or other program will get to the top of the chain; If the certificate at the top of the chain is recognized as trusted, your certificate will be considered valid. If, however, the certificate at the top of the chain is not recognized as being trusted, the browser will warn your users that all is not well, and may even prevent them from entering your website. When you pay for an "official" SSL Certificate, you get a certificate that should always be part of a trusted chain. In contrast, when you create your own Certificate Authority to sign your certificate, or if you use a self-signed certificate, your users will have to manually add the certificate at the top of the chain to their browser trust list.

** note that many many protocols can be encrypted using SSL certificate - we are just focusing on https here cause we can.

Types of Certificates

There are several types of certificates out there:

  • SSL Certificates:
    • A plain old SSL Certificate will protect one single domain name, such as https://domain.com. Note that https://domain.com is not the same as https://www.domain.com as far as SSL is concerned, even if your web server thinks that the two urls are the same. Any communication that takes place using https and a regular SSL certificate should happen using the exact domain name that you apply for.
  • Wildcard SSL Certificates:
  • EV SSL Certificates
    • Extended Validation SSL Certificates are intended to be more secure than the other types of SSL certificates - they use stronger encryption, and they are much more difficult to get. Extended Validation certificates contain extra information about the certificate owner that can be used to protect against phishing attacks. Extended Validation Certificates are only available to corporations at this time (Spring, 2008).

Certificate File Formats

See SSLCertificateFileTypes

The Certificate Process

Note, we don't cover wildcard or EV certficate processes here, sorry.

The general process of generating a signed SSL Certificate is as follows:

  1. Private Key and Certificate Signing Request (CSR) generated
  2. CSR is used to generate a signed SSL Certificate (ie public key)
  3. Web Server is set up to use the public and private key to operate over https

There are a million variations on how you can accomplish these 3 steps. Sometimes you take care of all the steps. Other times, a web hoster, or a DNS hoster or a Certificate Provider will take care of all the steps. Sometimes it is a combination of the above. No matter what variation you choose, you will need to specify a "common name" for the certificate. Although often poorly documented, the common name should be the single domain name that you want to protect, for example, blog.pamelaproject.com.

Variation One: Web Hoster Does It All

Many web hosting providers will generate a signing request, send that request off to a certificate provider to get it signed, and then install the resulting keys into the web server - all you have to do is to fill in a single web form. Check out your web hosting control panel to see if this simple method will work for you. PLEASE NOTE, in order to use PamelaWare, you have to get a copy of your public and private key from the web hoster, and if one was set, you also need to know your private key passphrase -- you'll need to supply that data during the configuration of PamelaWare.

Variation Two: You have to Generate a CSR

If you are asked to supply a Certificate Signing Request in order to get a certificate, you will have to do a bit of extra work. Most web servers contain the tools necessary to generate a CSR - if you have a web server available, you can choose from this page and get server-specific details.

Alternatively, you can download a tool like openSSL and use it to generate the CSR. OpenSSL is available on pretty well any platform, and comes already installed on many operating systems. Windows users should look at Win32 OpenSSL. These instructions should get you to the point where you have two files - a private key file (myserver.key) and a CSR file (server.csr).

At this point, you will usually paste the contents of the .csr file into a web request form at your provider. If you are sending the CSR to your web hoster, they will install the resulting certificates on your web server for you and send you a copy of the certificate. If you are sending the CSR directly to a Certification Authority, you will get the certificate back, and then have to install the certificate yourself.

Variation Three: You have to install the certificate into the web server

It's tough to describe the process for installation of the public and private key on every web server out there -- search engines will be your friend for this part of the journey. You will know you are done when you can use https protocol to get to the common name you specified originally, using a browser.