Normally when we log into the Dashboard our credentials are transmitted in plaintext – that's unencrypted – meaning that they are susceptible to packet sniffing. Equally our user session can be intercepted, our cookies hacked, and the site hijacked.
Not ideal then.
The best way to shore up this litany of insecurity is by implementing SSL, so that rather than log in and administer the site using http we use https.
This is certainly not the be-all and end-all of administrative security. There can still be (greatly reduced) risks of cookie stealing and phishing when using the SSL shared certificates offered by shared hosting providers, and meanwhile, only partial page encryption can result from poorly written, non-SSL-compatible WordPress plugins. We shall be addressing this latter concern later on. Nonetheless, this foundation measure can be layered with further safeguards, using a mix of defensive plugins and Apache modules, as we shall see.
- SSL for shared hosts
Shared web hosts tend to offer SSL with a choice of shared and dedicated certificates.
Shared, server-wide certificates
Often included on any level of plan, shared certificates are not domain-specific but are offered server or provider-wide and so are shared between many users.
For reasons particularly concerning our site visitors' trust and perception – not least due to the ugly URL formats that accompany them – shared certificates are far from ideal for securing, for example, client areas or shopping pages. Then again, they do provide a major leap forward in securing our login and administration pages, are quickly enabled and they likely cost nothing.
Check your provider's documentation for the precise format, but typically, expect to be assigned an address along these lines:
- https://secure.webhost.com/~USERNAME/ for hosts with a provider-wide certificate
- https://SERVER.webhost.com/~USERNAME/ for hosts with server-specific certificates
USERNAME is your web hosting account username, and if required, SERVER is the specific server where your web files reside.
Letting WordPress know
Navigate to the General Settings in the Dashboard and swap the WordPress address (URL) for your SSL address. With Hostgator, for instance, here's an example:
Save the page and you will be logged out automatically as the database is reset.
Now open the WordPress configuration file in your web files root folder, wp-config.php, adding this line to encrypt just the login, so that your credentials are no longer transmitted in plaintext:
Or better still, to secure the login and the entire Dashboard, add this instead:
Logging in to the WordPress Dashboard
That's it. Log in using the above address appended with the path to your Dashboard. Again using my Hostgator account example, we have this:
Or if you have an account with multiple websites, you'll need to specify the particular site:
Dedicated, domain-specific certificates
Dedicated or private certificates are domain-specific and, set up properly and notwithstanding SSL-unfriendly WordPress plugins, further improve security while encouraging a higher but varying degree of confidence.
Certificates can be self-signed, using your own free certificate, but these issue a “not trusted” warning to site users resolving https pages, which makes sense as anyone can issue them.
Certificates signed by a Certificate Authority, which reckons it knows the difference between good and bad and that charges handsomely to say so, are deemed essential for sites providing secure services, such as for shops, and exude complete confidence by site users who trust authorities.
Your certificate must be linked to a dedicated IP address, so if you don't have one, buy one from your web host. Also, bear in mind that you can use only one certificate per IP address, meaning that if you have multiple domains, only one domain can be secured by SSL at that IP address: this is why a dedicated IP is required, otherwise only one user on a shared host would be able to use SSL.
Obtaining signed certificates
Your web host will likely provide these, but third party certificates can equally be assigned. Shop carefully though because Certificate Authority prices vary wildly:
SSLShopper's a good place to compare certificates and prices. CAcert provides free certificates but not all browsers trust them by default, issuing a warning.
Setting up a signed certificate
The setup is the same as for automatically assigned shared certificates except that, having to be individually added to your server by a root account, your hosting provider has to do this manually and will therefore charge a few bucks. Open a support ticket for details.
Once installed, unlike with shared certificates, your secure pages can be accessed with the simple addition of the s, for example https://somesite.com/shop-here.
- SSL for VPS and dedicated servers
In this scenario, you have the necessary dedicated IP address, and probably have root access to set things up yourself. Some of the above SSL for shared hosts notes still apply so take a look.
Creating a self-signed certificate
Those wanting simply to secure login and Dashboard administration need pay nothing by instead creating a self-signed certificate and a private key. Logged into your remote server, assume root superuser privileges at the terminal:
You need OpenSSL's cryptography toolkit to create the two files. Find out whether you have it:
If you can't see the version details then install OpenSSL to implement the SSL functions:
Head to the private SSL directory, where we'll add the key and certificate:
Generating the files
Now to generate the key. Swap somesite for your domain name:
And protect the key, so only the root superuser can read it:
Now for the self-signed certificate. Change the expiration value of 365 days, if you like, but certificates should be replaced every now and again:
You'll be asked a few basic questions. They're nice and straightforward, but the one that may confuse you requests a Common Name. For that, give your domain name in the format www.somesite.com.
Required Apache modules
Configuring the virtual host file
Backup and open your site's configuration file, the virtual host file:
What you see in the vhost file is the basic configuration of your site in the form of Apache directives. The file contains a single virtual host (one site's configuration) for regular HTTP. We need to tweak that and add another virtual host, this time for HTTPS. Our objectives are practical enough:
- Enable HTTPS (SSL)
- Link the certificate and key files
- Route (rewrite) non-admin/non-login traffic to HTTP
- Route admin/login traffic to HTTPS
Those last two points will prevent duplicate HTTP and HTTPS pages that would, among other things, dilute our SEO efforts.
Otherwise, to keep things nicely ordered in one place, the following virtual host example cuts and pastes the WordPress permalink rewrite rules from our web root's htaccess file, so allow for that. Swapping the 18.104.22.1680 IP address for yours, somesite for your domain name, altering the paths to your web files, including further existing virtual host directives (for example, the location of site logs), and importing any existing htaccess permalink rewrites, your edited file will resemble the following which, because I'm a nice kinda guy, is #commented to help:
Finally, be safe and exit the root user account:
Alerting WordPress and activating SSL
Navigate to the General Settings in the Dashboard and swap the WordPress address (URL) for the SSL address. In this case, that means merely changing the http to https before saving the page. You will be logged out automatically.
With this scenario the addition of define(‘FORCE_SSL_LOGIN', true); or define(‘FORCE_SSL_ADMIN', true); to your wp-config.php file is not necessary and may create problems. But. For those without a domain-specific SSL certificate you will need to add either define(‘FORCE_SSL_LOGIN', true); to encrypt your login credentials, else define(‘FORCE_SSL_ADMIN', true); to encrypt login and secure WordPress' Dashboard. Now, back at the terminal, restart Apache:
Using a signed certificate
The procedure is the same except that instead of generating a self-signed certificate – the .crt file – you would create a Certificate Signing Request (CSR) – .csr – file.
Using the above Creating a self-signed certificate guide substitute the command openssl req -new -key somesite.key -x509 -out somesite.crt -days 365 for this:
Following the prompts, your form will look something like this:
Where the form asks for a Common Name, give your IP address or a Fully Qualified Domain Name. Submit the file to a Certificate Authority and upload the returned certificate to the folder in which the CSR was generated, linking to it in the virtual host.
Testing SSL and insecure pages
Check the site to ensure that the browser properly navigates your mix of http and https pages.
While SSL icons (in the address and/or other bars) and messages vary between browsers, as we have covered in our protocols overview, the icons signify when a page is properly secured, and hovered over, will give a confirmation message:
If you see a warning icon then not everything is being encrypted on the page, breaking the overall encryption. For WordPress this is known to happen when some activated plugin hasn't been written with SSL in mind, causing a conflict. You can troubleshoot the problem by de-activating and re-activating plugins, one at a time. Having found the culprit, either beg the developer to help or swap it for a compliant plugin equivalent.
WordPress SSL reference
The WordPress documents are far from comprehensive in this area but, nonetheless, there is at least some theory to be had from the codex:
Meanwhile, the Apache documents are better but, well, they still aren't entirely clear: