{"id":28,"date":"2005-05-18T01:11:24","date_gmt":"2005-05-17T23:11:24","guid":{"rendered":"http:\/\/blog.blackdown.de\/2005\/05\/18\/securing-wordpress-admin-access-with-ssl\/"},"modified":"2016-10-29T03:51:02","modified_gmt":"2016-10-29T01:51:02","slug":"securing-wordpress-admin-access-with-ssl","status":"publish","type":"post","link":"https:\/\/blackdown.de\/articles\/securing-wordpress-admin-access-with-ssl\/","title":{"rendered":"Securing WordPress Admin Access With SSL"},"content":{"rendered":"
January 22nd, 2006:<\/strong> There’s an updated version of this guide for WordPress 2 now: Securing WordPress 2 Admin Access With SSL<\/a><\/em><\/p>\n As one can guess from the look of this site, I’m using WordPress<\/a> as my blog engine. At this time WordPress does not support HTTPS access to the admin area when the rest of the blog is served via normal HTTP. This is a bit unfortunate. I do not like logging in to my server over unencrypted connections, especially not when using public WLANs. Getting around this WordPress limitation requires quite a few steps:<\/p>\n All communication involving passwords or authentication cookies should be done over HTTPS connections. Note: This documentation assumes a Debian<\/a> sarge installation with Apache<\/a> 2. Some things, in particular Apache module related ones, will be different on other systems. Then import The module gets enabled automatically after installation.<\/p>\n<\/li>\n Debian provides sane default configurations for both modules. You might want to take a look at the configuration files ( January 22nd, 2006: There’s an updated version of this guide for WordPress 2 now: Securing WordPress 2 Admin Access With SSL As one can guess from the look of this site, I’m using WordPress as my blog engine. At this time WordPress does not support HTTPS access to the admin area when the rest ofThe Goal<\/h3>\n
wp-login.php<\/code> and the
wp-admin<\/code> directory should only be accessible over HTTPS.
\nNormal reading access, as well as comments, tracebacks, and pingbacks still should go over ordinary HTTP.<\/p>\nThe Plan<\/h3>\n
\n
The Implementation<\/h3>\n
\nThe server used throughout the instructions is example.org\/192.0.34.166. The server’s DocumentRoot<\/code> is \/blog and WordPress resides in \/blog\/wp. The value of WordPress’
home<\/code> option is ‘http:\/\/example.org’ and the value of its
site_url<\/code> option is ‘http:\/\/example.org\/wp’.<\/p>\n
\n
\n
$ openssl pkcs12 -export -clcerts \\r\n -in blogclient.cert \\r\n -inkey blogclient.key \\r\n -out blogclient.p12<\/pre>\n
blogclient.p12<\/code> into your browser.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n
\nApply this patch<\/a> to the WordPress code. It makes the following changes:<\/p>\n\n
wp_setcookie()<\/code><\/li>\n
check_admin_referer()<\/code> working with HTTPS URLs<\/li>\n
\n
$ aptitude install libapache2-mod-proxy-html<\/pre>\n
$ a2enmod proxy\r\n$ a2enmod ssl<\/pre>\n
ssl.conf<\/code> and
proxy.conf<\/code>) nevertheless.<\/p>\n<\/li>\n
$ a2enmod headers<\/pre>\n<\/li>\n<\/ul>\n<\/li>\n
$ cat > \/etc\/apache2\/conf.d\/ssl.conf << EOF\r\n<IfModule mod_ssl.c>\r\n\tListen 443\r\n<\/IfModule>\r\nEOF<\/pre>\n<\/li>\n
wp-login.php<\/code> and
wp-admin<\/code> to the local host. Also completely deny access to files which should never be accessed directly. Here is an example:
10-example.org<\/code><\/a><\/li>\n
20-example.org-ssl<\/code><\/a>
\nIf you are compressing WordPress output you have to enable the RequestHeader<\/code> line.\n<\/li>\n
$ a2ensite 20-blog-ssl\r\n$ \/etc\/init.d\/apache2 restart<\/pre>\n<\/li>\n
[→ Read the rest of this entry<\/a>]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[6,3,2,8,20],"tags":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\t\n