Securing WordPress for SSL admin
I've written before about how WordPress doesn't really have a way to allow you to put administration tools in a secure location unless you do the same thing with the entire blog. This concerns me since I'm often on a wireless network that is open and not mine. Say, for example, at a book store with free wireless. While surfing on an open wireless network is generally pretty benign, sending any username/password across it without them being secure/encrypted makes it very easy to steal them.
I've hunted around a few times before, but had never really found a good solution. While doing some work on my site, I decided to try again and this time came up with "Admin-SSL". It's a plug-in someone wrote for WordPress that allows you to move all the "admin" stuff to a secure location. Something that isn't possible with the default install of WordPress (where you are either all secure or all open).
There are two examples of the power and benefit of open-source software with this plug-in. First off is the basic fact that WordPress is open which allowed for the plug-in to be created in the first place. While this isn't limited to open source software, it's a big help.
Second, when I installed the plug-in on my site, it didn't work properly. Some of the software that runs my site is different where the plug-in was originally created. However, since I could look at the source code, I was able to find a fix that works and allows me to use the it. To contribute back to the overall community a little, I've sent a note back to the original author explaining what I ran into and how I fixed it. This gives him the opportunity to let other people know about the issue and a way to fix it. Possibly even creating a specific fix for the issue in the next version.
* * * * *
Stop reading.... unless you are a web geek and/or are specifically looking for a fix for Admin-SSL on version 1.3 of the Apache web server. Below are the details of the fix that works for me. YMMV.
First, the short and sweet fix to try:
< When you configure Admin-SSL (at least version 1.1) on a server < running Apache 1.3, under the "Other Settings" category and the < "HTTPS Detection" section < < change: "The name of the HTTPS $\_SERVER variable" < to: "SERVER\_PORT" (without the quotes) < < and change: "The value of the HTTPS $\_SERVER variable when HTTPS < is ON" < to: "443" (again, without the quotes)
Now some details. Admin-SSL uses the predefined $\_SERVER\['HTTPS'\] php variable to check for secure connections while pattern matching to see if it should redirect a page to a protected URL. While this variable is available in Apache 2.x it is not in the Apache 1.3.x versions of the server.
See the list of "specials" under the "RewriteCond Directive" for reference: Apache 2.x - http://httpd.apache.org/docs/2.0/mod/mod\_rewrite.html\#rewritecond
You can use an existing feature in the Admin-SSL configuration (described above) to get around this limitation assuming the port that your host uses for SSL is different from. Usually, SSL is set to run on port "443". If your provider uses a different port, you can simply use that instead. The only exception to this is if you have a host that runs both HTTP and HTTPS over the same port. In that case, there is no way to tell the difference in the script using the above method.
All this, of course, assumes that your host provides you with a way to access your site via HTTPS with either a private or shared cert. A general practice is for them to setup URLS like:
"https://www.your-site.com/~your-username/" that would simply give you a secure version of "http://www.your-side.com/". If you don't see a colon followed by a number after the .com, you should be running on 443. If you see something like "https://www.your-site.com:1234/~your-username/", that means that your host is running HTTPS on port "1234", or whatever the number there is. That's the number you would want to configure.
If, for some strange reason, that number is "80", you're going to have to fins another solution, because that's the standard port for web traffic which means the script wouldn't be able to tell the difference.