WPAD: 1. Introduction

[Place Filler]

Test

Secure µTorrent WebUI

Ever wanted to have secure access to your µTorrent WebUI - here is a guide to setting up Apache to terminate an SSL connection from the wider Internet at your server, Apache then forwards your request unencrypted to your WebUI interface over localhost, then encrypting this data and sending it back.

This means that your username/password and monitoring of your downloads can't be seen by someone sniffing or logging your data.

This guide assumes that you already know how to setup multiple virtual hosts on SSL and you have your own self signed wildcard certificate and you can access the µTorrent WebUI over an unencrypted http connection, if not check out these links

• Setup µTorrent WebUI
• Self-Signed Certificates: How to get Cross Browser Compatibility with Wildcard Domains
• Apache2: Multiple Virtual Hosts over HTTPS

The next step is to get ensure you have setup µTorrent correctly. Note here that we are only allowing access from localhost (127.0.0.1) so the only way to access it will be either from the server locally, or though HTTPS and Apache. Set the alternative listening port to any unused port, 8080 or 8000 would be a common choice

Now edit your  Apache configuration file and add in the following - Changing your server name, path to certificate/key file and the port number in the proxy pass directive. Note - DON'T change the order of the two ProxyPass directives or it won't work.

   1: <VirtualHost *:443>
   2:     ServerName utorrent.example.com
   3: 
   4:     SSLCertificateFile conf/ssl/wildcard.crt
   5:     SSLCertificateKeyFile conf/ssl/wildcard.key
   6:     SSLEngine on
   7: 
   8:     ProxyPass /gui/ http://127.0.0.1:8000/gui/ 
   9:     ProxyPass / http://127.0.0.1:8000/gui/ 
  10: </VirtualHost>

Winsplit Revolution in Portable Apps

Portable Apps

is a great utility that sits on your usb thumb drive, and provides access to a number of applications which you can use on a host computer by simply plugging in your drive, it then pops up a menu in your taskbar

  

---

Winsplit Revolution

is also a great utility which allows you to move windows around your screen, perfect for large screens and multi-screen setups. For instance Ctrl-Alt-Numpad 7 will send the currently selected window in the top left corner of your screen, similarly Ctrl-Alt-Numpad 6 will send it to the entire right half of the screen. It makes sense if you look at you numpad as a map of your screen

 

---

Combine the two!

As of 04 June 2008 Winsplit Revolution now comes in a portable install mode - meaning that all files are stored on your usb drive, however they mention no integration with Portable Apps. By selecting the portable mode in the Winsplit installer and carefully choosing the path of install to be "X:\Portable Apps\Winsplit" where is the drive letter of your usb drive with Portable Apps already installed then voila - we now have Winsplit in the Portable Apps menu on your taskbar

Self-Signed Certificates: How to get Cross Browser Compatibility with Wildcard Domains

Introduction

A self-signed SSL certificate is a convenient  way to encrypt data between your own web server and web requests you make to it over the wider Internet. If you own multiple domains or run multiple sub domains, say as virtual hosts in Apache then creating a certificate that won't cause errors on Firefox, Opera and Internet Explorer 5,6 and 7 is non trivial, there are a few tricks which are only tucked away on some remote message boards - so I have summarized them here.

Creating a self-signed certificate for a single domain name is simple and covered in multiple places with easy to follow guides such as at

• http://sial.org/howto/openssl/self-signed/,
• http://www.akadia.com/services/ssh_test_certificate.html
• http://blog.taragana.com/index.php/archive/openssl-how-to-create-self-signed-certificate/

Wildcard certificate guides are a little rarer, however the one that this tutorial is based upon is below

• http://www.heebs.ch/computer/notes/wildcardcert

The above guide is essentially no more difficult than simply using * for the common name of your server when you come to generate the certificate, there are a number of problems with this simplistic approach when it comes to supporting multiple domains and subdomains on the same I.P addresses. As we must present the certificate BEFORE we can accept traffic there is no way for us to know which domain has been requested - thus all domains must be supplied with the same certificate.

---

The Problem

1. I.E 5 and Firefox (tested on 2.*) don't fully follow the relevant RFC - they will match the wildcard * to any domain or subdomain, for instance the list below would all match a wildcard cert issued with the common name *
   • http://example.com
   • http://site1.example.com
   • http://abcdef.net
2. I.E 6 and IE 7 however follow the guidelines to the rules - these specify that a wildcard can only match one level of subdomains, so with the same common name as the previous example we get
   1. http://example.com - Match
   2. http://abcdef.net - Match
   3. http://site1.example.com - The dreaded certificate error problem

---

The Solution

There are some custom fields in a certificate where you can specify other sites where the certificate is valid - known as "Certificate Subject Alt Name", thankfully we specify as many domain names that we want in here - but even better this field also supports wildcarding.

Initially only created one entry in this extra field - the entry I needed for a Vista Sidebar tool to connect which required a valid certificate, this however then broke compatibility with Firefox for all my other domains. It turns out that if this field is present Firefox then ignores the usual Common Name attribute which I had left as *.

There is however a resolution to allow all browsers to co-exist in a peaceful world. Simply put we can combine the best of both worlds into the Certificate Subject Name. Starting off with creating a Certificate Authority we essentially follow heeb's guide, but I have added a few steps in at the start and end

   1: #We need to set the subjectAltName, It appears that this can't be set at the command prompt.
   2: nano /usr/ssl/openssl.cnf
   3:
   4: #Scroll down to the [ usr_cert ] section and alter, uncomment or add in a comma separated list 
   5: #of all the domains, sub domains and wildcard matches you want in the form
   6: subjectAltName=DNS:*,DNS:*.example1.com,DNS:*.example2.com,DNS:12.34.56.78
   5:
   8: #Create temporary directories
   9: mkdir -p demoCA/{certs,crl,newcerts,private
  10: echo 01 > demoCA/serial
  11: touch demoCA/index.txt
  12:
  13: #Create a new root authority.
  14: #You will want to miss out this step if you ever create more certificates, 
  15: #as you will want to reuse the old authority
  16: openssl req -new -x509 -keyout demoCA/private/cakey.pem -out demoCA/cacert.pem -days 3652
  17:
  18: #Create a signing request 
  19: #I don't think it matter any more what we use as common name, but use * here to be safe
  20: openssl req -new -keyout ./wildcard.req -out ./wildcard.req -days 3652
  21: 
  22: #Sign the request
  23: openssl ca -policy policy_anything -out wildcard.crt -infiles wildcard.req
  24: 
  25: #Extract the key for Apache, it is used for encrypting/decryptind the data
  26: openssl rsa <> wildcard.key
  27:
  28: #Copy the file demoCA/cacert.pem into the root of all your web sites
  29: #Name it with the extension .crt, for example.
  30: cp demoCA/cacert.pem /path/to/website/wildcard.crt

---

Final Thoughts

Now simply browse to your website over http and open the file wildcard.crt that we just created http://example.com/wildcard.crt. When prompted to save you want to do this into the "Trusted Root" or similar folder. See below for screenshots of this process in IE and Firefox.

Note that although the steps above assume you are running Linux with Apache, there is nothing stopping you from doing this in Windows XP by using  Cygwin and importing the certificate into IIS.  In fact I made this guide using Cygwin on Windows XP and imported the certificates into Collabnet Subversion Server which is a full Apache server for Windows XP with built in svn support wrapped up in a simple installer.

The Final step is to setup multiple virtual directories in either IIS or Apache and tell them to use the key we just created, a guide for Apache can be found in my next blog post here.

---

Installing a new Trusted Root in Internet Explorer

---

Installing a new Trusted Root in Firefox

Apache2: Multiple Virtual Hosts over HTTPS

Ever wanted to run multiple virtual hosts on your Apache installations under SSL, but you only have one I.P address to bind to? There are three main steps

1. Create your own signing authority and a self signed certificate (If you haven't got one of these yet see here)
2. Change your Apache configuration file
3. Restart Apache

Change Apache Configuration

A summary from Rich Bowen
Copy the two files wilcard.crt and wildcard.key into a subdirectory of your Apache install, for instance I usually use the dir conf/ssl/. Now edit your config file to look similar to this, the two cert/keys MUST be the same. You also need to ensure that Listen 443 is defined somewhere in the file

   1: NameVirtualHost *:443
   2: <VirtualHost *:443>
   3:     ServerName foo1.bar.com
   4:     DocumentRoot /www/foo1/
   5:     SSLEngine on
   6:     SSLCertificateFile conf/ssl/wildcard.crt
   7:     SSLCertificateKeyFile conf/ssl/wildcard.key
   8: </VirtualHost>
   9:
  10: <VirtualHost *:443>
  11:     ServerName foo2.bar.com
  12:     DocumentRoot /www/foo2/
  13:     SSLEngine on
  14:     SSLCertificateFile conf/ssl/wildcard.crt
  15:     SSLCertificateKeyFile conf/ssl/wildcard.key
  16: </VirtualHost>
  

As a side note the first virtual host is the default one if you get an unmatched domain name, so foo3.bar.com would get served as if it was foo1.bar.com.