Tuesday, April 3, 2007

Webapp security using Secure Socket Layer (SSL)...

One of the things I want to do with my webapp is secure certain portions of it using https -- the secure mode of http communication. That requires an SSL Certificate... essentially a digital key and associated (encrypted) certificate that allows the web server and browser to encrypt and decrypt transmissions between the two [Don't ask me much more about the detailed security aspects... I am not a security expert].

However, since my Rails ISP doesn't provide built-in support for SSL, I had to go get my own SSL Certificate. I also had to get my own domain name (see previous posts) because this kind of Certificate is "attached to" (associated with) a specific domain -- I can only use this certificate with stuff on this particular domain.

I immediately ran into acronym hell -- things like "CSR", "RSA Key" -- and a process that was less than intuitive.

First, you have to get a "Certificate Signing Request" (CSR; also called a "Certification Request"), which you then send to a "Certificate Authority" (CA; think Verisign. Thawte, and others). These folks are the keepers of the keys... the public key infrastructure keys, that is, which is nothing more than the folks who are trusted to issue cryptography keys which make secure communications possible (read "eCommerce, eBay, etc...). In essence, they electronically vouch for who you say you are.

Once you have your CSR (which by the way requires that you know some of the webserver details (Apache vs IIS, which flavor of SSL is implemented in the server), then you pick your CA and submit an application. This application includes your CSR, reams of contact information, the domain name you wish to secure, and your email address (several flavors; more later on that).

I searched out the various options and finally settled on Thawte's SSL 123 certificate: it's tailored to securing a single domain name and was quite inexpensive: $39.95 for one year. GoDaddy's Turbo SSL was cheaper ($19.95), but I thought Thawte [pun intended] had a better name. Also, Thawte gives you an online "Trusted site seal" which makes it clear that you have secured your site... something that I thought worthwhile.

Once I got to this point, I figured it was all downhill from here... and it did go downhill, just not in the manner that I expected. I did finally get my certificate and had it installed on my server, but not before I ran into a few snags. Although Thawte gives you the option of having them generate your CSR, I chose to have my ISP generate it for me. At this point, I can't remember exactly why, but I'd most likely have Thawte do it for me now. Here's the chronology:

1. Request RailsPlayground (RP) generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"Invalid state"
RP had put the City name into the State field and we had both missed it.

2. Request RP generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"State code cannot be abbreviated"
RP had put in CA and it had to be spelled out in full.

3. Request RP generate the CSR for me. They did so, I submitted my application to Thawte and it was bounced:
"Invalid email address"
It took me a few more tries until I figured out that it had to be the email address which was referenced in the domain registration system(!). Once that was corrected, my request went thru, I was issued the certificate, and it is now installed on my site.

Were I to do this all over again, I would take the simpler route and do as much as I could directly thru the Certificate Authority's website... that would have saved me some of my headaches. But you still have to dig into it and learn something about the terminology before you can make this happen. Better yet, find an ISP that already has this baked in and save yourself some grief.

I'm happy to say that now I can use https on my website.

The question is how to implement it on my website... regardless of whether a visitor types in "https://" or not, I want to secure certain actions and certain controllers, and automatically route them to use https... but that's a question for more research and another post.

No comments:

Post a Comment