Every month, I get a newsletter from my webhost, DreamHost. And I read it! That’s how I found out that supernaut could be SSL, have https:// in its URL and have that fancy lock in the address bar. Up there, ^.

Why would I want to do something like that? Well, because I can. Because it’s useful for a lot of reasons, especially now. Since the Snowdon NSA whistleblowing, which gets worse and more damning with each document release, it became obvious to me I should take the implementation of privacy and security as seriously as I do reading about it. Recently this has meant beginning the move off Google, which I use for so much; installing PiWik instead of using Google’s Analytics, installing GPGTools for email encryption (and badgering my friends to do the same); and obviously, if easy website encryption was possible, I’d give it a spin.

The first things I tried it out on have been my private server (running Pydio, formerly AjaXplorer) – my self-running DropBox, and for PiWik, then on a couple of small, low-traffic sites, to test how SSL would play with my standard-ish WordPress setup, which led to some rewriting of htaccess rules, and quick/easy code cleanup. So then I thought to try it on supernaut, which gets enough traffic and is complex enough to really show the horror.

WordPress make it reasonably simple – provided you have STFP/shell access – to make the switch. First the admin and login side of things can be SSL’d simply by adding:

define('FORCE_SSL_ADMIN', true);

to wp-config. Then in the Admin General Settings changing WordPress Address and Site Address to https. Then in the root .htaccess, editing the WordPress with two additional lines:

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]


This did the majority of the change; the remainder turned out to be annoying. Images in the content seemed very reluctant to make the jump. This is partly because they are effectively hardcoded via the process of inserting the using the Media Library. I tried several methods with varying degrees of success, and finally adding this to functions.php seemed to do the job, updated a bit to use WordPress’ inbuilt is_ssl() function, which is a wrapper for both isset($_SERVER[“HTTPS”]) and a check for server port 443, and uses str_ireplace() instead of the depreciated ereg_replace:

function supernaut_ssl_content($content) {
if ( is_ssl() )
$content = str_ireplace('http://' . $_SERVER['SERVER_NAME'], 'https://' . $_SERVER['SERVER_NAME'], $content);
return $content;
}
add_filter('the_content', 'supernaut_ssl_content');

Which just left data in custom fields, which I use primarily for video. These look like they are best edited by hand in supernaut, though it’s possible I could use the WordPress HTTPS (SSL) plugin … I’d rather bash around in the code so I understand what’s going on. (edit) well obviously I can just wrap any code in the template with the above function, and just replace $content with $variable that pulls the post meta, no? (edit 2) And also for situations where I’m using Advanced Custom Fields (sadly not here), adding this to functions.php takes care of the rest:

add_filter( 'wp_get_attachment_url', 'set_url_scheme' );

This just leaves changing the WordPress Address and Site URLs in General Settings to https://, and that’s it (I think).

The last thing then is my own certificate. While Chrome is reasonably calm about the fact my SSL is an unsigned certificate (i.e. I haven’t spent up to $1500 on one from a trusted vendor), and Safari drops down a fairly innocuous warning – which admittedly is enough to make most people anxious, FireFox turns on all the alarms and does a mad freakout that’s impossible to simply bypass. Horrible, no? I figured that $15 a year for a secure certificate was probably worth it, for the experiment alone.

supernaut on SSL then! Most Excellent!

And for those reading for whom this was all WTFBBQ?, here’s what DreamHost said:

SNI – SSL Without a Unique IP!

“Server Name Indication,” or SNI, is a biiiig deal in the world of web hosting.

Every site on the web is tied to a specific IP (v4) address, but a single address can be shared across several different domains. In fact that’s one feature that’s helped to keep the Internet from bursting apart at the seems up ’till now.

IPv4 addresses are the Brettcoins of the shared hosting world in that they are both EXTREMELY valuable and that there are only a finite number of them gifted to humanity by the Gods.

While IPs can be shared among websites, they cannot be shared among SSL-enabled (secure) websites. If you want to handle secure web transactions on your own without the use of a specialized third party payment platform you’ll need to lease (and pay for,) a unique IP address for your own personal use.

Or at least…that’s how things USED to work.

SNI extends the protocols used to process secure web transactions to allow for the usage of a single IP address across several different SECURE websites. And, as of not too long ago, we support it!

You can still obtain a unique IP address and tie your secure hosting to it if you’d prefer – but it’ll cost ya ($3.95/month.)

To add or modify the secure hosting settings on any of your domains, visit the “Domains/Secure Hosting” section of your control panel, and click to “Add” or “Edit” services on your domains.

https://panel.dreamhost.com/index.cgi?tree=domain.secure

For a little background on setting up secure hosting in general, including some caveats of SNI, check out our wiki!

http://wiki.dreamhost.com/Secure_Hosting