I’ve been thinking about, and even making attempts at, getting Gallery set up within my home network to allow automatic uploading from my Android devices. There are a few things I wanted to do as part of this post, and since I’m getting around to doing it at 11:00 at night, it’s going to be more of a notes-style document than a well-structured post.
First, my goal. I want to be able to automatically upload images taken on my Android devices to a “private cloud”… also known as a computer (VirtualBox VM, actually) on my network running the Gallery software. I want this to be at least as simple as it currently is (I currently use Dropbox with instant upload enabled on both my wife’s and my phones). I want our uploads and the account information associated with them to be secure, both on my private network and particularly across the Internet if I decide to go that route. I have been thinking about setting up a trusted certificate authority for some time. It’s an opportunity to learn and practice with software I don’t use on a daily basis. I have an innate distrust for the cloud. And because I think I can and I want to confirm.
Why am I doing this? Dropbox works fairly well, and it’s nice to have the pictures replicated to both the cloud and our PCs… but we have exhausted our space (if you don’t already have Dropbox and would like to sign up via the link above, that will get me another 500MB 🙂 ). While there are a couple of workarounds for this such as moving all the current photos out of my upload folder, there are some things I gain from Gallery that I’ve been wanting. I may make an effort at integrating the Dropbox functionality alongside Gallery at some point down the road, but there are several steps to get there first. My wife also typically turns off automatic upload and replicates images manually. I think she told me why, but I’ve forgotten; I’d like to get this set back to an automatic function so it’s not something she needs to remember to do.
Here’s a list of the parts involved in my venture, and a short explanation of why:
- My Asus RT-N16 router with Tomato firmware
- Provides internal DNS service and external-to-internal firewall access and port mapping
- Android
- Both our phones are rooted US Cellular (awesome carrier… comment if you’re considering changing carriers and interested in hearing more about them) Samsung Galaxy series Android devices. I don’t have a great deal of love for iOS.
- OpenSSL
- I’ve wanted to configure a CA (certificate authority) to provide clean SSL service for a few of my internal web services for a while. This seemed like a good opportunity to do so, especially when I considered potential public access to my Gallery server.
- TrueCrypt
- I’m planning to store my CA files in a volume that is both encrypted with TrueCrypt as well as offline except when I need to sign a certificate.
- ReGalAndroid
- Android client app to support automatic uploading
- TurnKey Linux
- Lightweight guest for Gallery VM. I had almost forgotten that I had downloaded the pre-built Gallery appliance from them until I started this post.
- Gallery
- In addition to what looks to be a good gallery interface to my photos, I can configure automatic, private backup. I gain the ability to tag and comment on photos, and lose the risk of having photos exist “in the cloud” by default.
This ends up being a moderately complex setup for a “typical” home environment. Some might even say it’s excessive. However, when assembled together, each of these pieces helps to reach the aforementioned goal.
I actually started down this path a little while ago and had a few of the foundational constructs in place. VirtualBox was installed on my XP host system. I had downloaded and configured a VM using the TurnKey appliance turnkey-gallery-12.1-squeeze-i386-vmdk and performed the basic setup for the TurnKey appliance. I had installed the ReGalAndroid app on my SGSII and attempted setup with SSL, and discovered that a self-signed certificate on Android just wasn’t good enough. Attempting to connect to the Gallery over my wifi connection via SSL yielded a “No peer certificate” error. Not particularly surprising considering the SSL cert on the Gallery server was self signed.
So, at this point I essentially have two problems to address that more or less boil down to a single problem: I need to create my own personal trusted CA (which has been near the end of my todo list for quite a while), use that CA to sign a certificate for the Gallery server (and preferably other internal web service servers), and trust certificates signed by my new private CA on our Android devices and internal computers. I’ve made some effort at this previously as well. I’m currently running PCLinuxOS on the laptop I typically use, and ended up annoyed about/failing to complete creation of a CA on that platform (especially in combination with my desire to store the CA in a TrueCrypt volume).
This evening I set out to create the OpenSSL CA on a well-established Ubuntu box on my network, largely based on the instructions at https://help.ubuntu.com/community/OpenSSL. This didn’t get completed, largely due to documentation efforts and to searching for a window I thought I had open regarding trusting new CA’s on Android. At this point, I need to spend some quality time with iptables on another project so I’ll try to pick back up from here later. (This highlights another minor gripe/difficulty/annoyance I’ve had… serial posts in WordPress… there has to be a good way to do it, and some day I’ll probably need to take the time to do so.) Once I finish creating the CA, my next steps will probably involve either creating a TrustManager on Android as documented here or importing a new (private) CA root certificate as documented here.
After creating the necessary certificates largely as indicated in the Ubuntu OpenSSL link, I copied the certificate and private key for the Apache server for my gallery page over to the Gallery appliance. I then ran a2enmod ssl as root to enable mod_ssl on the Gallery server per instructions at https://help.ubuntu.com/10.04/serverguide/httpd.html, HTTPS Configuration section, and received a report back that mod_ssl was already enabled. I then moved the certificate and private key to /etc/ssl/certs and /etc/ssl/private, respectively, ran a2ensite default-ssl, and modified the SSLCertificateFile and SSLCertificateKeyFile directives to point to the correct certificate and key. Though I am still expecting to need to create a concatenated certificate chain with the CA certificate and the server certificate, I went ahead and tested a restart of the server to see what I got.
I received a certificate error/”problem with the certificate on this server” page in IE, much as I had expected – the client I was connecting from doesn’t even trust my new CA as a root yet. I continued past the error, and noted that I will probably have to do a little work on the default-ssl site file in /etc/apache2/sites-available, as it doesn’t load directly to the gallery page; much of that should be able to be copied from the ‘default’ site file in the same directory, and I will play with that later. I first wanted to see if I could get rid of the SSL error on the default Apache page, so I installed my new root CA public certificate as a trusted root CA on that box and retried loading the page. SSL loaded cleanly, oorah!
So, to enable Gallery on HTTPS, I checked /etc/apache2/sites-available/default. No reference there. Turns out I needed to edit /etc/apache2/sites-enabled/gallery (they didn’t do a symlink as is done for the default sites). I updated the VirtualHost section for *:443 to include the cert and key directives from the default-ssl config file, ran a2dissite default-ssl to disable the default-ssl site, and restarted Apache again. I was then able to load the gallery site with HTTPS and no errors from that system.
I copied the public certificate for my root CA to my Dropbox, clicked on the .crt file in the Android dropbox app, and was able to install the certificate after setting an unlock mechanism. Following that, I tested access from the ReGal Android app, but received a mismatch on the CN. Apparently the ReGal app will not accept a match on an altName, and I will need to match the FQDN (which I will have to use for the connection so it will work both when I’m at home and when I’m on the public Internet). Time to re-issue the certificate with the CN set to the FQDN and the hostname as a subject alt name.
After correcting and replacing the certificate and key, and revoking the old one for whatever that was worth, I encountered a new error with details “net.dahanne.gallery3.client.business.exceptions.G3ItemNotFoundException”. This was fixed by enabling the REST module as indicated here. Once that was done, I was able to establish a secure connection to the gallery!
