It’s time to get your new web-based database up and going… awesome! How do you go about making sure the info passed from your server to the user (or staff member) isn’t intercepted by the wrong person? Enter the SSL Certificate. You’ve all seen the padlock icon in your browsers – just check your Gmail account, can’t miss it.
What’s an SSL Certificate?
Very simply put, an SSL certificate is a file on your web server that allows someone visiting your website to establish a secure connection (think https). The certificate contains information about your organization, the website, the company that issued it, and several other tidbits. Here’s a Wikipedia entry if you want a super technical explanation.
There are a several types of SSL Certificates. Most likely, however, there are only two that would apply to this scenario: Standard and Wildcard.
- Standard Certificates only work for a single web address. (i.e. www.mychurch.com)
- Wildcard Certificates work for all subdomains of the registered address. (i.e. www.mychurch.com, mail.mychurch.com, etc.)
If you can afford the added cost, I recommend purchasing a Wildcard Certificate. This will give you the most flexibility for your web driven database. For example, one Wildcard Certificate can service multiple sites:
If you purchase a Standard Certificate you will have to purchase additional certificates for every subdomain launched in the future. Additionally, depending on what version of IIS you might be using, it becomes very complicated to use multiple Standard Certificates on one web server.
Where’s the best place to get an SSL Certificate?
I’ve purchased a few SSL Certificates from DigiCert, but there are several legitimate vendors (VeriSign, Thawte and GeoTrust just to name a few). The most important thing I’d recommend is to shop around. Quite often these companies will throw in a free certificate for your Exchange Server or a free additional year added to the certificate you’re purchasing if you just ask.
If you need to save some serious bucks, there is always Garrison Host’s Alpha SSL. It’s not the most intuitive process and their insurance coverage is minimal. However, it is the cheapest Wildcard SSL you can find and at the end of the day it’s secure.
I’m not taking any online transactions, do I need SSL?
This is a very common question. The answer: a resounding yes!
Even though you’re not taking online transactions, I wager your database has some sort of login process involving a password – if it doesn’t we need to have a serious conversation about the software you’ve chosen. Also, I’m sure that all your users (including yourself) have unique passwords for every website they use, right? … No? Then it’d be a pretty big problem if someone’s password wasn’t protected when they logged in to your website, huh?
That’s right. If you so much as have a simple login form, it needs to be on a secure connection. Otherwise, the password is passed back to the server in plain text and is “low hanging fruit” for anyone possibly listening in.
Additionally, most churches I’ve helped are overly concerned with security roles and making sure that only certain staff can see specific counseling or benevolence notes. Talk about a huge security hole! We’re talking about a treasure trove of unencrypted info for a hacker to intercept and I don’t even mean those sensitive notes. I’m referring to the member’s birthdate, phone number, email, address, and any other basic identifiers a hacker could use to gain access to any other accounts. Every time a person details page is viewed, if it’s not encrypted with SSL, it’s free-game to a hacker.
Is it really worth the annual cost?
Yes! With concerns of identity theft around every corner, we have to be responsible. Our members trust us with their personal information. If they knew one of the most foundational steps towards protecting them was overlooked they could very quickly lose trust in our organizations. Especially with the low-cost option available, there is no excuse.
What’s the bottom line?
All web-based church databases need SSL certificates. Period.