First, you will need to generate a cryptographic private key for your certificate authority (CA):

$ openssl genrsa -out rootCA.key 2048

Certificate authorities in HTTPS have a private key and a matching public CA certificate. You should store this private key in encrypted storage, because you will need it again if you ever want to generate more certificates. Next, you will need to create a public CA certificate and provide some information about your new CA. If you are the sole user of your new CA, then this information can be set to whatever you want:

$ openssl req -x509 -new -nodes -key rootCA.key -days 9999 -out rootCA.pem

Let me explain a bit about these two commands. The openssl command line utility takes a subcommand as its first argument. The subcommands genrsa and req are used to create RSA keys and to manipulate certificate signing requests, respectively. Normally when you go out and purchase an expensive SSL certificate, you will generate a key yourself and create a Certificate Signing Request (CSR), which is given to your certificate authority to approve. The CA then sends back an public SSL certificate that is presented to website clients. Generating the key yourself means that the private key never passes through the hands of your CA, so only you have the ability to authenticate using your SSL certificate.

The x509 switch in the argument above signifies that you are trying to create a new Certificate Authority, not a Certificate Signing Request. The nodes switch actually means no DES, which means that the resulting certificate will not be encrypted. In this case, DES encryption of the certificate is not necessary if you are the only party involved.

You have just created a new Certificate Authority key and certificate pair. At this point, you can import the rootCA.pem certificate into your web browser and instruct it to trust it for identifying websites. From then on, your browser will accept any website certificate that is signed by your new CA. Now you’re ready to make some website certificates. Create a private key and Certificate Signing Request for your new website as follows:

$ openssl genrsa -out SITE.key 2048

....

$ openssl req -new -key SITE.key -out SITE.csr

....

> Common Name ... : (put the name of your domain here)

Remember to put the domain name of your website as the common name when it asks you for it. Once you’ve completed the certificate signing request, you need to use your new Certificate Authority to issue a certificate for this new key:

$ openssl x509 -req -days 9999 -in SITE.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out SITE.crt

You’ve created a functional SSL certificate and keypair for your website! You can configure your web server to use your new site key and certificate, and it will begin serving resources over HTTPS. However, this certificate will only work for the domain that you specified before in your CSR. If you want to create a single certificate that will work for multiple domains (called a wildcard certificate or a multi-domain certificate), you will need some more steps. Create a file named SITE.cnf, and put the following inside:

[req_distinguished_name]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
organizationalUnitName	= Organizational Unit Name (eg, section)
commonName = Common Name (eg, YOUR name)
commonName_max	= 64
emailAddress = Email Address
emailAddress_max = 40

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[v3_req] 
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = rogerhub.com
DNS.2 = *.rogerhub.com

Under the last block, you can insert as many domains with wildcards as you want. To do this, use the following command to generate your CSR:

$ openssl req -new -key SITE.key -out SITE.csr -config SITE.cnf

Now, run the following to generate your wildcard HTTPS certificate, instead of the last command above:

$ openssl x509 -req -days 9999 -in SITE.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -extensions v3_req -out SITE.crt -extfile SITE.cnf

The v3_req block above is a HTTPS extension that allows certificates to work for more than one website. One of the flags in the certificate creation command is CAcreateserial. It will create a new file named rootCA.srl whose contents are updated every time you sign a certificate. You can use CAcreateserial the first time you sign a website certificate, but thereafter, you will need to provide that serial file when you sign more certificates. Do this by replacing -CAcreateserial with -CAserial rootCA.srl in the final command. A lot of the concepts here only hint at the greater complexity of HTTPS, openssl, and cryptography in general. You can learn more by reading the relevant RFCs and the openssl man pages.

It just so happens that Linode, the hosting company that hosts the RogerHub network, recently announced a 10x increase in bandwidth caps for all their clients, and Opera announced their decision to move their browser line over to Webkit, sparking conversation about our complacency with Safari/Chrome. These two together motivated me to return to Firefox and recapture their vast add-on ecosystem to try to address this issue.

ssh -D 1025 rogerhub

You’re probably familiar with ssh‘s ability to forward TCP and erect ad-hoc SOCKS proxies. If not, you should definitely check out man ssh and read through the -L and -D flags. This command sets up a SOCKS proxy on localhost:1025 (ports below 1024 are privileged and can only be bound by root) through which you can forward web traffic and stuff.

Now, Google Chrome’s proxy support isn’t great for two reasons: first, they’ve had corporate adoption in mind since the beginning, so Chrome has historically read proxy settings from the environmental variables/group policy/system configuration, whatever it is on your system. In their Windows version, there’s also a UI to set proxy settings, but it isn’t their main focus. Second, their extension API doesn’t allow for the same kind of deep integration with the UI and with the program internals as Firefox’s add-on environment allows.

So, I opened up Firefox and installed FoxyProxy, the popular proxy-switching add-on, and configured it with the SSh proxy. I also pulled in NoScript for the sake of locking down the browser itself.

NoScript comes with a bunch of draconian defaults, and isn’t very useful without a bit of configuration (you could, for example, just turn off scripts in Firefox instead of keeping its defaults). Enabling same-origin scripts (Base 2nd level domains works well for me) will let most sites and their CDN subdomains to function the way they were meant while ignoring the GA, Facebook, and ad network trackers. Of course, this isn’t very good practice for casual browsing, but open wifi is a battlefield.

Altogether, it makes for enough security to give you peace of mind while browsing on public wifi. Firefox, as a browser, has really improved over the years as well, especially its web developer tools which (back in the day) once consisted of an Error Console and the imperative to install/learn Firebug. Also, splitting search and location just makes sense.