Command Center

I recently purchased and installed a new SSL certificate from GoDaddy for Marrily. During the process, I came to learn more about SSL and the different steps to set everything up from scratch. There are an abundant amount of articles and tutorials on how you can get started, but surprisingly there are no articles on “why” you have to follow those steps. Truth is I was pretty confused when I first started. There were a bunch of different steps and different key, pem, crt, csr files that need to be generated. The result was that I got lost and screwed up during the process. I then add insults to injury by accidentally revoking my certificate instead of re-keying it and ended up having to call GoDaddy to revert the deletion. Since any entrepreneur with a SaaS website will eventually need to implement SSL to protect their customers, having a better understanding of SSL will be greatly beneficial. This is my explanation to the entire process in plain English in hope that I can help clear up the confusion.

Why SSL?

To protect the communications between your web server and the client’s browser, you need to implement an encrypted channel so that all data transferred back and forth can only be read by your server and the browser. Anyone who eavesdrops in between will just see gibberish. Only your web server and the client’s browser know the right “secrets” to unlock the encrypted message. This communication protocol is called https, with the s stands for “secured”.

When user requests a page via https, your server will need to encrypt the content using a secret which the user’s browser can decrypt using a well-known identity. If somehow the content is encrypted with an unknown identity, the browser will be very hesitant to accept it, and it will ask user to make the hard decision to proceed or not.

Why Purchase a SSL Certificate?

To purchase a SSL certificate is to obtain a publicly verifiable identity for your domain that is accepted in all browsers. Most modern browsers include a list of well-known root Certificate Authority (CA) public keys, and any encryption done using these CA sources will be accepted by the browser. It is also possible for you to generate a root Certificate Authority set of key as well, technically speaking you become your own Certificate Authority. However, since your identity is unknown and not verifiable, the browser will not trust your keys and thus it will pop up an alert to notify the user. Nonetheless, once you add your certificate key to your browser’s list of accepted certificates, it will come to know about your identity and hence it won’t bother popping up anymore.

Since you can’t ask everyone to manually install your public key to their browser’s list of accepted certificates, you will need to buy the certificate from an established vendor whose public key already came bundled by default in the browser. I read somewhere that this is how browser vendors can make some money, e.g. the SSL guys will need to pay to have their identity (the public key) included in the browser. In exchange, these SSL vendors can turn around and certify (or “sign”) anyone who wants to get a SSL certificate for a fee.

If you think about becoming a SSL vendor, you will need to convince all other browsers that you’re completely trustworthy, and you protect your private key used to generate the SSL certificate with your life, since whoever gets their hands on your private key will be able to sign any SSL request, thus compromising your identity as the reputable Certificate Authority. All SSL vendors offer a warranty on their SSL certificate service from $1,000 to $10,000 to a lot more specifically as a statement that they keep their secret hidden really well to protect the identity of their customers’ SSL certificates.

Obtaining a SSL Certificate

Step 1: Generate your private key

To handle https requests, your web server will need to encrypt the data. Hence the first step you need to do is to generate a private key that will be used for the encryption. You can use different encryption algorithms but a SSL vendor can ask you to use a specific method and key length. The longer the key, the better the encryption strength. If the key is too short, the bad guy can quickly run through all the possibilities and found out your private key, then he can pretend to be you. In my case, GoDaddy want to have 2048 bits (256 bytes) for the strength for the private key. For personal use, a key strenght of 1024 bits (128 bytes) would be sufficient.

openssl genrsa -out private.key 2048
Generating RSA private key, 2048 bit long modulus
..............................+++
.+++
e is 65537 (0x10001)

Step 2: Generate a new SSL Request .csr file

The next step is to generate a “request” for a new SSL using your private key. This request file has an extension of .csr which stands for Certificate Signing Request, and it contains the identity about you (or your company), and most importantly, where the SSL certificate would be valid for: a single domain (cheapest) or any sub-domains (a.k.a. wildcard, and a bit more pricey). All these information will be encrypted using your private key and saved to a file. The SSL Vendor will then take this file and sign it to produce a valid SSL certificate that can be applied to your server.

EV SSL

If you pay more money, you can also get your identity in the SSL certificate confirmed as a legitimate business entity. This type of SSL certificate is called EV SSL (Extended Validated Certificate). Essentially the SSL vendor will verify the identity of your company by asking you to submit your business registration paperwork, bank account, letter from attorney or accountant, etc., for an additional fee ($400 to $1,000). In return, you will have a green-bar status with your company’s name next to the browser’s address bar. The theory is that user can identify your company’s name, and thus feels more secured as he/she knows that the website is the correct one, not a phished site that just pretend to be your website. Most (if not all) banks and prominent businesses have this type of EV certificate to protect their identity.

To generate a new CSR from your private key, use the command:

$ openssl req -new -key private.key -out marrily.com.csr

As I mentioned, the most important bit of the CSR file is where the SSL Cert should be valid for, which is defined in the “Common Name” attribute. For single domain (https://marrily.com, or https://www.marrily.com), you can use either “domain.com” or “www.domain.com”, since the “www” subdomain is so commonly used and thus can be omitted. Check out line 14 below for more details:

$ openssl req -new -key private.key -out marrily.com.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Marrily
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:marrily.com
Email Address []:alexle@marrily.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

I did not specify any challenge password in this case to keep everything simple.

Step 3: Submit your CSR to get a SSL Cert

Now that you have the CSR file containing your identity and which domain the SSL would be valid for, you can submit this CSR file to the SSL vendor (of course you will have to pay them first). They will take your CSR file and generate a new .crt (certificate) file using their own private key. Essentially they “sign” your CSR file with their carefully guarded secret file. You will then get back the your .crt file corresponding to the CSR, and another .crt file that belongs to the SSL vendor.

Chances that the SSL Vendor’s crt file actually contains a list of different certificates (public keys). The reason is that more or less your SSL vendor is actually a re-seller of another Certificate Authority, which can also be a reseller of another higher-level CA. So the first certificate would belong to your immediate SSL vendor, the one after that belongs to the higher-level CA that signed your vendor’s cert, and the cert listed after that belongs to an even higher CA that signed the CA’s cert that signed your vendor’s cert which signed your own certificate. Essentially it’s a tree of certificates that lead all the way up to the highest level of CA, which is a root certificate that is included in the browsers by default. For GoDaddy, the root CA is www.valicert.com, and for VeriSign, it is VeriSign’s own Class 3 Public Primay Certification Authority - G5.

(notice the green bar, that’s the EV SSL which costs you some more money to obtain)

Step 4: Configure Your Web Server

Now you should have in your possession these files:

1) your private key

2) your .csr file (not used anymore)

3) your new SSL certificate provided by your vendor as a .crt file, which is valid for your domain.

4) your SSL vendor’s crt file, containing a list of different certificates.

You are now ready to go and configure the web server to use your private key and your new SSL certificate (which is technically a public key) for the https-enabled website. The specific configuration for each web server is different, but the process will be the same. Also, the .crt files sometimes have a “.pem” extension as well, but for simplicity’s sake, they can be used interchangeably.

Nginx and GoDaddy SSL

In my case, I used nginx to serve my Rails application. I originally installed this nginx instance from source using passenger’s installer but ssl was not enabled by default (you can check this by running “nginx -V” and look for - -with-http_ssl_module). I re-ran the passenger’s installer again and add the - -with-http_ssl_module switch to the optional parameters, and everything was good to go.

One gotcha for Nginx is that you will have to combine the 2 certs that GoDaddy give you into one .crt file, with your SSL certificate comes first, then GoDaddy’s crt file (gd_bundle.crt). The browser would understand this as your SSL was signed by the CA whose public key is next cert entry, then that one was signed by the one after it, etc. all the way to the root CA.



$ cat www.marrily.com.crt gd_bundle.crt > marrily_combined.crt



I then added a new server{} block to listen for ssl requests on port 443. After restarting Nginx, Marrily is now ssl-protected with a green padlock.

server {
    listen          443;
    server_name     marrily.com;
    # passenger stuff

    ssl on;
    ssl_certificate         /your/ssl/folder/marrily_combined.crt;
    ssl_certificate_key     /your/ssl/folder/private.key;
}

Self-Signing your Certificate and Testing SSL Locally

Now that Marrily is https-enabled and some of the actions requires SSL, I wanted to develop the site locally using SSL as well to make sure all the logic worked correctly. I’d need to self-sign a new SSL certificate and have it installed locally.

Preparation

In my environment (Mac OS X Snow Leopard), I also have nginx installed using Homebrew. Homebrew installed nginx with ssl support by default so no recompilation was needed. I also added a new entry to my host file so that I can use a fake domain to access my local site, and I’d use this fake domain in my CSR as well.

# /etc/hosts
127.0.0.1 marrilydev.com

Self-Signing a New Certificate

I generated a new private key using openssl:

$ openssl genrsa -out privatekey.pem 2048

Then I generated a CA cert using this private key:

$ openssl req -new -x509 -key privatekey.pem -out cacert.pem -days 3650
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:marrilydev.com
Email Address []:

I didn’t care about any of the details except for the Common Name field, which I specified the fake domain.

Since the cacert.pem file was generated (a.k.a. signed) using the same privatekey.pem file, we could use it as the SSL certificate directly. All we’d need to do is set the ssl_certificate_key setting in the configuration to the privatekey.pem file:

upstream rails { server 127.0.0.1:3000; }

server {
   listen       443;
   server_name  marrilydev.com;

   ssl                  on;
   ssl_certificate      /Users/sr3d/projects/misc/ssl/cacert.pem;
   ssl_certificate_key  /Users/sr3d/projects/misc/ssl/privatekey.pem;
   ssl_session_timeout  5m;

   server_name   marrilydev.com;
   access_log    /Users/sr3d/projects/marrily/svn/marrily_marrily/m3/app/log/access.log;
   error_log     /Users/sr3d/projects/marrily/svn/marrily_marrily/m3/app/log/error.log;
   root          /Users/sr3d/projects/marrily/svn/marrily_marrily/m3/app/public/;

   location / {
     proxy_set_header  X-Real-IP  $remote_addr;
     proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header Host $http_host;
     proxy_connect_timeout 74; # max is 75s
     proxy_redirect off;

     # Proxy to Backend
     if (!-f $request_filename) {
        proxy_pass http://rails;
        break;
     }
   }
}

(Note: locally I have the nginx proxy all traffic to the development server running on port 3000)

Also, since Mac OS X has special restrictions for port 80 and port 443, nginx must run with sudo to listen to port 443, otherwise it would silently fail and you won’t be able to hit the site via https.

Getting Rid of SSL Warnings by Installing the Self-Signed Cert

With nginx configured to listen to secured requests, I opened up the site in Chrome, and saw a huge red error message complaining about the validity of the certificate, since Chrome did not recognize the identity of the cacert.pem. Obviously I could just ignore the warning and proceed to the https site for the current session, but there’s a better solution: add the cacert.pem to the list of approved certificates.

To install the self-signed certificate, just double click on the cacert.pem file in Finder. The cert would be added automatically to Keychain Access.

With the cert added to Keychain, all browsers installed in the system would gladly accept a https connection to https://marrilydev.com.

Summary

• SSL certificate is not all that confusing once you understand the gist of it and why each file is needed
• The process in simple steps:
  
  • generate a new private key for encryption
  • Using this private key, generate a CSR containing the domain information for the SSL
  • submit the CSR file to the SSL vendor to obtain a new CRT certificate file
  • configure your web server to listen to 443 https traffic using the private key in step 1 and the CRT obtained from the vendor
  
  
• GoDaddy SSL has different pricing on their SSL stuff, so search around and don’t pay a full price.
• SSL is cheap, implement it to protect your customers and gain their trust
• If you’re gziping your site, should add this line to your nginx’s conf file:
  
  gzip_buffers 16 8k; to make sure nginx doesn’t loose large gzipped JS or CSS

Reference

• How to setup GoDaddy SSL certificate on Nginx
• Nginx Gzip SSL
• http://alexle.net/archives/309