Strong TLS Encryption at Alureon.net!

October 31, 2017 Apache, Linux, MySQL No comments

You may (or may not) have noticed that alureon.net is now served over strong TLS encryption!  This is a big win for me, as it’s always been something that has puzzled me.

You can check the certificate yourself in Chrome using Developer Tools

TLS in Chrome's developer tools

Aww yeah!














What Not To Do

Tempting as it might be, you apparently cannot self-sign a certificate and expect any browser not to freak out about it.

openssl req -x509 -new -nodes -key alureon.key -sha256 -days 1024 -out alureon.pem

(This opens up a whole new basket of problems with Subject Alternative Names as well.  Just don’t do it.)

Expecting users to click through the “INSECURE” prompts or install your root certificate seems a bit unreasonable in most cases.

What To Do

A buddy of mine pointed me over to https://letsencrypt.org/

Using certbot, I was able to get myself a legitimate, trusted cert (for free!) with little hassle.  I opted for:

certbot certonly --apache -w /srv/http -d www.alureon.net -d alureon.net

I answered a few questions, and it generated my SSL cert and key.  Super easy.  The only other steps are pretty much uncommenting the SSL module in httpd.conf.

LoadModule ssl_module modules/mod_ssl.so
Include conf/extra/httpd-ssl.conf

Also, you have to set up extra/httpd-ssl.conf to point to your new SSL cert and key.

SSLCertificateFile "/etc/letsencrypt/live/www.alureon.net/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/www.alureon.net/privkey.pem"

I opted for some other pretty extreme settings as well, forcing only the latest version of TLS.

SSLProtocol -all +TLSv1.2

Fixing Insecure Resource Requests

After you go full TLS, browsers still claim you’re insecure if you make any requests to insecure resources (resources not served over http).  This includes fonts, javascript, and even images.  I wanted the green Secure text in Chrome badly enough to go the extra mile, so I continued to fight the good fight.

I’m sure there’s a better way to do this, but I did

UPDATE wp_posts SET `post_content` = REPLACE (`post_content`, 'http', 'https');

This worked wonderfully, but it also changed the literal text “http” in all of my posts to “https”.  This had some funny side effects, but I think I changed everything that actually needed to be “http” back.  There was one post where I had pasted text of myself working in a directory named “/srv/http”.  It changed the directory name to “/srv/https”, which I though was kind of funny.

Forcing TLS at the Domain Level

This worked great for manually navigating using SSL (typing https:// in the browser), but I’m guessing most people aren’t going to do that.  How do we force them to use SSL at the domain level?

I found this hack on some random website, and it seems to work great (aside from appending an extra forward slash to my TLD).

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVERNAME}/$1 [R,L]

I just appended that to the bottom of my httpd.conf, and it worked!  If anyone knows a more efficient way, let me know.

Fixing Pretty Permalinks with WordPress and Apache Web Server

March 26, 2017 Apache, Linux, WordPress No comments , , , ,

Apparently, in order to use pretty permalinks in WordPress, (with Apache Webserver…) you can’t simply “enable the option” in WordPress and expect it to work. You have to make the following changes to your httpsd.conf. In my case, this was located at /etc/httpsd/conf/httpsd.conf.

  1. Uncomment LoadModule rewrite_module modules/mod_rewrite.so
  2. Enable FollowSymLinks for your WordPress directory.
  3. Enable AllowOverride to either All or FileInfo. The relevant configurtion section for these steps is as follows:
        <Directory "/srv/https">
        # Possible values for the Options directive are "None", "All",
        # or any combination of:
        #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
        # Note that "MultiViews" must be named *explicitly* --- "Options All"
        # doesn't give it to you.
        # The Options directive is both complicated and important.  Please see
        # https://httpsd.apache.org/docs/2.4/mod/core.html#options
        # for more information.
        Options Indexes FollowSymLinks

        # AllowOverride controls what directives may be placed in .htaccess files.
        # It can be "All", "None", or any combination of the keywords:
        #   AllowOverride FileInfo AuthConfig Limit
        AllowOverride All

        # Controls who can get stuff from this server.
        Require all granted

That should do the trick. The only other caveat is that WordPress needs a .htaccess as well. Fortunately, as long as WordPress has write permissions, it can make its own! I just restarted my web server and viola!