This is the start of a series that will chronicle everything I’ve learned along the way keeping the wife’s photography website (https://www.jendzphotography.com) running smoothly. I’ll cover topics including performance improvements, dealing with spam & robots, content distribution networks (CDN) and using website tools to track progress. I intend to keep the technical mumbojumbo to a minimum and make the reading level less technical than my typical blog posts for easier consumption.
In 2014 Google announced they will start boosting page rankings for https enabled sites. While SEO is of course important, it’s also just good practice to use SSL.
The current Wikipedia entry for HTTPS includes:
HTTP Secure (HTTPS) is an adaptation of the Hypertext Transfer Protocol (HTTP) for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted by Transport Layer Security (TLS), or formerly, its predecessor, Secure Sockets Layer (SSL). The protocol is therefore also often referred to as HTTP over TLS, or HTTP over SSL.
Put simply, when you enable HTTPS you put a private key and public key in the web server configuration that encrypts traffic between the web server and your web browser. OK… put even more simply… It makes your web traffic hard(er) for bad people to read.
Certificates are issued by a trusted Certificate Authority (CA). The whole system is based on trust. Your web browser contains a list of the CAs in the world. When you load a HTTPS enabled site, the certificate is compared against the list, and if all checks out, it turns green and you are safe. If one of these CAs get severely hacked, browsers will remove them from the lists and anything they issued will no longer be trusted. Usually you have to pay out money to a CA to have a certificate issued for you from a company like GlobalSign, Verisign, or GeoTrust. In 2016 however, a free service was launched called Let’s Encrypt that now offers them for free. Yay!!
Their free service is great, but it does have a limitation of only a 60 day duration in the certificates they issue (typically the commercial ones are measured in years). They explain their reasoning for that here. Basically, it is a built in failsafe if they get compromised (stolen) and the short duration encourages automation. And I have to admit, the automation tool I first used is great!
The easiest way to get started is by using a tool to request the certificate and put it in place for you. I found the CertBot tool from the Electronic Freedom Foundation (EFF). I’m using Apache on CentOS 6 so I’ll just focus on that. The install steps for that are here.
mv certbot-auto /usr/bin/
chmod a+x /usr/bin/certbot-auto
Run the commands, and it starts off installing dependencies
Right off, it dives into a few prompts. First the terms of service, then an EFF email notification.
It goes through your web server config and lists the configured domains. In our live site it listed all we had sites for, surprisingly.
Then it asks if you want the tool to automatically configure apache to force redirects to SSL/443 or not. Be sure you take a backup of your config before proceeding – by default at /etc/httpd/conf/httpd.conf.
Yay! First part is done!
So remember the certificate is only valid for 60 days. They include a method to automatically renew it, which is actually pretty awesome. Enterprise system administrators forget all the time to renew certificates.
They have a dry run option (which means it shows what it would do, but doesn’t actually do it)
certbot-auto renew --dry-run
(ignore my annoying python warnings/errors using the default config)
Add this to cron so you don’t forget. They recommend doing it twice a day, but I don’t see any harm in doing it multiple more times.
Yay! We’re all good!
Ah crap…. what now?
By default, it only picked up the base domain (jaas-demo.com) that was configured in Apache, and not the full domain that is more human friendly (www.jaas-demo.com).
They have a command to add a domain to the certificate:
certbot-auto --expand -d www.jaas-demo.com
There we go, thats better.
To troubleshoot any problems, you can use this syntax to dump the contents of the certificate in human readable form:
openssl x509 -in /etc/letsencrypt/live/www.jaas-demo.com/cert.pem -text -noout
That’s all we got! For a basic site this will work out of the box. You may have to tweak things a little if you use a content delivery network, or pull in files from other sites and so on. We’ll cover some of this in a later post.
Wuups… I didn’t notice in the OpenSSL output that only the subdomain www.jaas-demo.com was in the certificate! I actually ran the wrong command above with the expand flag. What that syntax did was create a NEW certificate, not add the subdomain to the existing one. The syntax should include the cert-name field like so:
certbot-auto --cert-name www.jaas-demo.com --expand -d www.jaas-demo.com -d jaas-demo.com
Ahh that is better.
**** Shameless plug ****
Have a website problem of any sort you need help with? Contact me here to see if I can help. Rates based on complexity and time required.
**** /Shameless plug ****