SSL Checklist Before you go HTTPS

SSL Tips

If you have a website with sensitive data you have to have an SSL installed and working on your website; otherwise browsers are going to let users know that they are sending their sensitive data across an unsecure connection. Aside from the added cost there are quite a few things that have to happen in order for the installation an execution of the ssl to work. Here are a few tips that can save you a bunch of time and headache.

Make sure it is installed correctly

There are many tools on the web that can diagnose issues relating to your cert. Just going to your website with a https isn’t enough. If your cert has a bundle crt you may need to do more than just point to it. For nginx you may have to concat the certificates in order to reference them correctly. These tools will help you discover any issues you might have with the cert’s installation.
Here are a few

  • Digicert.com/help
  • SSL Shoper checker
  • Make sure all your page references are HTTPS

    Even if your cert is installed correctly the page can still show errors if you are referencing a file that isn’t https. This means any offsite images, css and js need to reference https version of resource links. If this hasn’t been done most browsers will throw up a notification (usually in the url bar) saying the connection isn’t fully secure. Even worse, in the case of JS, the browser won’t even execute the script so that means uses get a broken experience.

    Google Analytics must be HTTPS

    I installed a cert months ago. Everything looked fine and since I wasn’t actively looking at the site’s analytics I didn’t see that I was referencing the http:// link to analytics in the site’s code. I had forced the site to redirect to https so that all traffic would be under https. What I didn’t realize was that the google analytics script called on the page wasn’t executed because it was an unsecure resource. As a result I lost a few months of unrecoverable analytics data.

    Check Your Site Links on Google

    A good thing to do once you feel everything is installed correctly is to goto Google.com and search your site’s indexed pages. You can do that by searching site:yourdomain.com. This will show most, if not all, of your sites pages being indexed by Google. This will allow you to quickly click through to your site and see if any of the links give weird ssl related issues – like links that say they are https when they aren’t or pages that are indexed without https when they should. Checking your links on Google is a good way to see what your users see.

    Becareful with Forced Redirects

    Forcing traffic to HTTPS using redirects can make sure that users see a secure site when they are visit your website. There are many scripts out there that will force users to https – but beware that pattern matching can lead to some unexpected issues. Users might visit your website by typing a whole host of different things. For example they might type:

  • http://www.domain.com
  • www.domain.com
  • domain.com
  • domain.com/
  • https://www.domain.com
  • http://domain.com
  • https://www.domain.com/asset
  • www.domain.com/asset
  • You get the point. You need to make sure that each request is handled the way it should be.

    https:// vs. https://wwww

    A certificate by default only handles one website. Of course you may have bought a wildcard cert which makes this tip moot. If you didn’t buy a wildcard you will need to be sure that your server has the cert installed for the correct website url which means either with www or naked. The choice is your personal preference; just know that if you have links to your site that are www.domain.com and it isn’t the one set up with the cert then it will throw up a big unsecure warning. The other option is to issue the certificate for both www and naked versions of your site – which means it costs more money, but still cheaper than a wildcard.

    You need to secure each subdomain

    Like the above issue – a standard cert is only good for the top level domain unless you purchased the wildcard version of the certificate. Wildcard certs cost more but allows your site’s subdomains to be covered by the certificate. The only other option is to buy a multi domain cert and explicitly state each subdomain you want to be secured.

    Decide Secure, Unsecure, or Both

    On the server you will need to decide which ports your site will be reachable on. For secure transmission you’ll need to be on port 443 and for unsecure you’ll need port 80. You will have set that up when you installed and referenced your cert. What you might want to consider is leaving directives for both 443 and port 80 so that your site can be reached at both http and https.

    In conclusion

    SSL installation is complicated and it has many ramifications for your site and site content.