September 6, 2012
Obtaining an SSL certificate can be tricky. Understanding the process helps to avoid pitfalls, so let's take a look at exactly what is going on when you purchase an SSL certificate.
The purpose of an SSL certificate (from here on, referred to simply as a "cert") is interesting and useful for administrators who need to offer secure services, but if you don't care about the details and just want to make it work, I have one piece of advice. Take a minute or 2 to carefully read the on-screen directions in Rumpus displayed on the Certificate Generation sheets. If you take your time and follow the instructions, the process should go smoothly.
Now then, let's take a deeper look...
SSL isn't just a mechanism for encrypting data transfers; it also provides "trust". Trust means that when a client connects, it is able to verify that the server is who it claims to be and that it is run by a reputable organization. This is why you are asked for the server domain name when you request your cert. The certificate you receive will apply and be valid only for the server name specified, guaranteeing that the server is the server it claims to be.
You will also provide your company contact information, allowing the issuer (also known as a signing authority) to do a basic background check of your company. Once they have done this check, the issuer will essentially vouch for you. Web browsers automatically trust well established signing authorities, and by issuing a certificate to you, the authority is saying "you can trust this server because we are vouching for them." When you obtain an SSL cert, it's not really the cert you are buying, it's the trust you gain by having a reputable company vouch for you.
All signing authorities will require that you send them a Certificate Signing Request, or CSR. A CSR includes the information needed by the authority (your server name and company information) plus a randomly generated "public key".
When a data channel is set up between a client and the server, the data is encrypted using "keys". Clients use a "public key" to encrypt or decrypt the data, and the server uses a matching "private key" to do the same. When data is encrypted using the public key, it can be decrypted only with the matching private key, and vice-versa. The public and private keys are not the same, but are matched so that they must be used together to provide the strong encryption offered by SSL.
The important point here is that SSL encryption requires a matched public/private key pair. Both keys are created when you generate your CSR. The private key is automatically installed on your server by Rumpus and the public key is included in the CSR you send to the authority. When the authority issues your cert, they use the CSR to create it so that the certificate also includes your public key. A certificate can be used only with the private key that was generated along with the CSR used to obtain the cert.
When you apply for a certificate, most authorities will ask what server software you are running. Unfortunately, many won't list Rumpus as an option. Rumpus uses OpenSSL as it's platform for providing SSL service, so if "OpenSSL" is an option, that will work fine. OpenSSL is built into the system, so any variation of "OS X" is also a safe option. Since there really isn't any difference between certificates issued for different servers, a generic "Other" choice can be selected, too. If you still aren't sure, contact the signing authority and ask them to add Rumpus to their list of supported servers.
Certificates can be applied using the "Load Cert" button in Rumpus or by copy/pasting. Using the "Load" button is generally preferable, as Rumpus corrects common issues like incorrect line endings and automatically prompts for an intermediate cert. See the "Secure Transfers" article in the Rumpus package for details about applying your cert.
There is one particularly common problem to watch out for: The signing authority does not provide your private key. (If they did, it wouldn't be private!) Rumpus automatically generates and installs the private key when you generate the CSR. Don't install anything you receive from the authority in the private key field. In fact, don't alter the private key at all.
If a private key is overwritten, damaged, or otherwise altered between the time that you generate the CSR and the time that you install the certificate, the certificate becomes invalid. The only option at this point is to generate a new CSR and have your certificate re-issued by the signing authority.
Fortunately, what you are paying for when you buy a cert isn't the cert itself but the trust involved in the authority vouching for you. So, all reputable authorities will re-issue certificates at no charge and usually very quickly (since they've already decided you are trustworthy). Generate a fresh CSR and send it to the authority, being careful not to alter the private key in any way, and apply the new cert you get back normally.
As always, send an e-mail to "support@maxum.com" if you have any trouble at all.