In my related post on security for 2017 (and beyond), I talked about how your organization needs to build in better security on the part of your users. But you also need to secure your website by moving your site onto HTTPS instead of HTTP. At the very least, this will protect the integrity of your login page, but also can protect your site visitors. Visitors will be able to see that you have secured your site by two indicators: the green padlock, and the HTTPS text in the browser address bar.

So, what’s with HTTPS? What does it mean? When browsers display the green padlock and HTTPS next to your domain name in the address bar, they are confirming three important things to the browser user:

1- That your transmissions are secure (meaning no third party can add or subtract anything from the page). Here’s an example of a Wi-fi provider adding advertisements to websites not secured by HTTPS.

2- That your transmission is being encrypted (no one is able to eavesdrop on the interaction between you and the person browsing). That’s why the green padlock always, always needs to be present when you collect passwords, credit cards, or any personal information on your website. (Starting in January 2017, Chrome will alert users when they are on sites that don’t use encruption when collecting passwords or credit card numbers.)

3- A third party has confirmed your site’s identity and ownership. (This is probably the least solid attribute: if someone is attempting to impersonate your domain, they could still do so while being verified, for example, by pretending to be G00gle instead of Google.)

In order to move to encrypted, secure transmission of your website, you’ll need to get your site onto HTTPS for all visitors and interactions.

How do you move your site to HTTPS?

Basically, you need to acquire and configure an SSL certificate, then make sure you’re only serving secure files. If your nonprofit doesn’t have a tech department or contractor who can do this, here’s how I suggest you do it:

1- Get your organization an SSL certificate

Although there are free SSL certificates available via Let’s Encrypt, these certificates require more tech know-how to set up (if you are comfortable using the Command Line, you’ll be able to work with Let’s Encrypt). These certificates will also require more ongoing maintenance (their certificates are only valid for 60 days, so require more frequent updating). If you’ve got strong tech support in-house (or more time than money), Let’s Encrypt can be a reasonable option, but for the most nonprofits I work with, I suggest paying for a certificate.

The path of least resistance is to go to the help section of your hosting provider (not your registrar, if you’re not sure what I mean, read this post.) Use your website host’s preferred method to acquire a certificate. This will cost $75 to $200 per year in addition to what you pay now for hosting. This is a new expense, but it’s long overdue and part of the modern web.

Once you order and pay for a certificate, you have to verify your ownership. You fill in a form, and the certificate authority (CA) who issues your certificate confirms that you are the owner of the domain and you have control over it.

Some entities will opt to go through a more substantial verification processes to get higher grade verification (called Extended Validation or EV, which costs more), but many of us in the nonprofit world will be able to function with the basic verification (Domain Validation, or DV) which costs less and goes quickly. (This is why some Certificate Authorities are critical of Domain Validation, but it will still work for enabling you to use HTTPS.)

Once you have acquired the certificate and verified yourself, you will need to install the certificate on your server. This is where using your host’s preferred method makes a big difference. There are technical tasks to confirm the configuration, and saving money but spending hours trying to puzzle out the hosting details is not necessarily something that you’re going to put in the “win” column.

The most basic requirement is that you need for the site to start replacing http://yoursitename.org with https://yoursitename.org, which for WordPress sites is handled via your .htaccess file. Hosts that will do this for you will save you quite a few headaches.

2- Updating your site to only serve secure content

Once you have the certificate set up and functioning on your host, there’s still some detailed work to do to see that secure green padlock appear. Your site will only earn the green padlock when your certificate is configured correctly and everything on the page is being served securely. You have to confirm that everything on the page: all text, files and images, are making use of SSL.

You can use the aptly named Why No Padlock? to make sure that your site certificate is configured correctly. It can tell you if there’s any problem with your certificate or your encryption. But if you are using a CDN (content delivery network), it won’t detect issues with insecure images loading. (For example, if you are using Cloudflare, you have to set it to use SSL. And of course, remember that you have to clear the site cache if you want images to be served from these new secure URLs.)

Still no padlock? For a granular list of exactly what insecure items are still depriving your site of full HTTPS, try this handy SSL check tool from Jitbit, which crawl your site (up to 200 URLs at a time) and locate the items that are not loading from a secure URL. The culprits here are generally going to be images that are hard coded into your theme or in specific pages or posts, and that tool will sniff them out.

If there are just a few, you can manually update their URLs to use HTTPS instead of HTTP. But if there are many affected URLs, the fastest way to deal with this in a content management system is going to be to find and replace all the references to your old (insecure) media library with updated URLs.

If you are comfortable working directly in your CMS database, you can do a find and replace using PHPMyAdmin. For WordPress users, there are plugins that will enable you to do this from your WordPress admin area (I like Better Search and Replace, whose paid version allows you to preview the changes before you make them).

In any case, be sure to backup your database before doing any search and replace functions in it, since, well…. you can mess things up pretty badly if you make a mistake.

3- Final step: update your Google Analytics settings

Go to your property settings in the Google Analytics admin area and to ensure that it is now recording visits that use HTTPS.

When all these steps are complete, your site will largely operate the same, but you will be keeping your business and your visitors deails more secure.

Want to know more?

For more about these changes, here’s some useful links:

• Short glossary of useful terms if you’re the one setting up HTTPS
• Useful Tune the Web tutorial on security

Images courtesy of Google