I recently bought 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 fortuitously revoking my certificate instead of re-keying it and finished 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 momentously 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 make pleased by a secret which the user’s browser can decrypt by a well-known identity. If somehow the make pleased is encrypted with an unknown identity, the browser will be very hesitant to accept it, and it will question user to make the hard choice to proceed or not.
Why Hold a SSL Certificate?
To hold 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 Power (CA) public keys, and any encryption done by these CA sources will be accepted by the browser. It is also possible for you to generate a root Certificate Power set of key as well, technically speaking you become your own Certificate Power. But, since your identity is unknown and not verifiable, the browser will not trust your keys and thus it will pop up an alert to report 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 question 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 defaulting 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) built-in 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 reflect 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 Power. All SSL vendors offer a warranty on their SSL certificate service from ,000 to ,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 question you to use a point method and key length. The longer the key, the better the encryption strength. If the key is too small, the terrible 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 2048Generating 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 by your private key. This request file has an additional room 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 by 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 being. 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 (0 to ,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 right 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 vital 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 any “domain.com” or “www.domain.com”, since the “www” subdomain is so commonly used and thus can be omitted. Check out line 14 not more than for more details:
$ openssl req -new -key private.key -out marrily.com.csrYou are about to be questioned to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are reasonably a few fields but you can leave some blankFor some fields there will be a defaulting value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [AU]:USState or Province Name (full name) [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits Pty Ltd]:MarrilyOrganizational Unit Name (eg, section) []:Common Name (eg, YOUR name) []:marrily.comEmail Address []:alexle@marrily.com
Delight enter the following 'superfluous' attributesto be sent with your certificate requestA challenge password []:An discretionary 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 by 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 really contains a list of different certificates (public keys). The reason is that more or less your SSL vendor is really a re-seller of another Certificate Power, 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 built-in in the browsers by defaulting. For GoDaddy, the root CA is www.valicert.com, and for VeriSign, it is VeriSign’s own Class 3 Public Primay Certification Power – 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 point configuration for each web server is different, but the process will be the same. Also, the .crt files sometimes have a “.pem” additional room 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 attention. I originally installed this nginx instance from source by passenger’s installer but ssl was not enabled by defaulting (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 discretionary parameters, and everything was excellent 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 know 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 Hard SSL Locally
Now that Marrily is https-enabled and some of the actions requires SSL, I wanted to develop the site locally by 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 by Homebrew. Homebrew installed nginx with ssl support by defaulting 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/hosts127.0.0.1 marrilydev.com
Self-Signing a New Certificate
I generated a new private key by openssl:
$ openssl genrsa -out privatekey.pem 2048
Then I generated a CA cert by this private key:
$ openssl req -new -x509 -key privatekey.pem -out cacert.pem -days 3650You are about to be questioned to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are reasonably a few fields but you can leave some blankFor some fields there will be a defaulting 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.comEmail 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) by the same privatekey.pem file, we may possibly 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 may possibly 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 involuntarily 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
Reference
(out of reviews)
Answers Rating