Now, in the year 2016, the Googlebot will start to arrest those who do not comply. Your organic ranking will take a hit and the Chrome / Chromium browser will gradually shame sites which are not 100% encrypted with https. Also, newer protocols like HTTP/2 require the use of SSL.
Similarly, Google is sunsetting older SHA-1 certificates that expire in 2016, and especially those expiring after January 1, 2017. SHA-1 certs will need to be re-keyed (free) with the issuer.
For developers, anytime you access a login form the connection should be secure. Considering how many sites (CMS, control panels, database tools) the average developer touches, and how much free/shared Wi-Fi we use, we really need to be careful. You're also putting clients, and possibly their customers, at personal risk. This is particularly true for people using the same password for everything.
Tim Fowler showed an OpenUpstate.org crowd just how easy it is to be a phishing bad guy in a coffee shop with a battery run, pocket-sized access point. Even if the login forms are encrypted (self-signed or real) you still have the concern of mixed content session hijacking if the entire domain is not encrypted.
Enter our hero, Let's Encrypted. Now, you have no/few excuses, because a basic domain-verified SSL certificate (which covers www.example.com and example.com) is free. Heck, even the paid SSL certs are sufficient for most needs and cheap at $9/year (wildcards are $92/year).
Finally, SSL and TLS are related and intertwined in a confusing way. SSL v2.0 and v3.0 has been deprecated. Best practices for protocols and ciphers change as new vulnerabilities are found. Mozilla maintains a list of "intermediate" and "modern" ciphers (check the oldest compatible browser list to compare to your needs) for various HTTP servers (Apache, Nginx, etc), ALWAYS backup conf files and test first..
This will be the subject of a Lightning Talk at Upstate PHP this week on Feb 18th at 6PM. I'm posting a lot of the details here because I'm sure I'll forget things in a 5-10 minute talk.
Let's Encrypt can be a bit of work to configure on older servers, or ones with older versions of Python. However, once you get it setup the renewal process is simple and automatic. There are automated install tools for different operating systems and plugins for popular web servers, so you may be able to use one of those less manual methods with ease.
I ended up doing a manual "webroot" install method for a variety of reasons, including the operating system and version. I also like to know how things work, so not hitting the "easy button" makes you understand.
At its simplest, the letsencrypt-auto script will take your domain name, email, and the public root directory path of your domain as inputs. It then creates an obscure public directory called /.well-known/acme-challenge/ and drops in a validation file. The Let's Encrypt server then pings your server looking for that obscure file (much like Google's Analytics or Webmaster Tools HTML validation). If the file exists then they know you control the domain in question and certificate files are saved to a directory in /etc/letsencrypt/live/. From there you installed the SSL certificates as normal. Some of the plug-in tools will actually modify your Nginx or Apache web server's configuration file and reload/refresh the web server for you.
Here are instructions for ways I've manually (without using the aforementioned plugins) configured CentOS with special notes and code examples for installing in Apache, a Drupal work around, and adding a scheduled cron job
Always backup files, test first on a development copy first (if possible) so you don't crash the server. Apache can/will fail with no error messages if you have things like missing SSL files and it's really annoying to debug no error, so definitely backup your configuration file(s) first
Lovingly crafted by orangecoat with some rights reserved, and a promise not to spam you.
Back to top