Skip to content

Month: March 2016

Lets Encrypt & Nginx: Www-root method and Subject Alt Names

Digital Ocean has a pretty good guide for setting up Lets Encrypt with Nginx on Ubuntu 14.04. However, their guide requires you to turn down your Nginx server while initially getting you Lets Encrypt TLS certificates, this of course is problematic for server/site operators who either need or want to continue to have service continuity while getting lets Encrypt Certificates. They also don’t explain how to use subject alternative names to handle multiple sub domains on the same server.

Lets Encrypt’s software requires that they be able to connect to your server to verify that the domain you’re attempting to register a certificate for you control. In the Digital Ocean guide, this process is handled by using the built-in web server in the lens encrypt package. However, Lets Encrypt does not need to operate in this manner to create new certificates, it can use the wwwroot/filesystem approach and your existing server configuration.

The process is very similar to Digital Oceans guide, but the order of operations are slightly different.

WordPress Hardening, Moving WP-Config

Lets be clear about somethings. Security is hard. Even the so called experts get it wrong, surprisingly often at that. I’m not an expert, and I’m not proposing that I’m right. Take what I say with a grain of salt.

In part of WordPress’s hardening guide they discuss moving the WordPress config file (wp-config.php) out of the document root as a mechanism that can be used to make it more difficult to attack. Specifically they say:

You can move the wp-config.php file to the directory above your WordPress install. This means for a site installed in the root of your webspace, you can store wp-config.php outside the web-root folder.

Note: Some people assert that moving wp-config.php has minimal security benefits and, if not done carefully, may actually introduce serious vulnerabilities. Others disagree.

Note that wp-config.php can be stored ONE directory level above the WordPress (where wp-includes resides) installation. Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission).

The linked discussion on the topic on Stack Exchange is also worth reading while you’re at it.

With that said, I’m going to throw my 2-cents in to the discussion.