Renewing my Free SSL certificate with StartCom

Since my Secure Sockets Layer (SSL) certificate needs are quite modest, I use the free SSL certificates from StartCom. Here are my instructions for renewing it, which is almost identical to the process for creating an SSL certificate with StartCom.

  1. Go to the main site, and log in with your StartSSL Open Identity certificate. Create one if need be.
  2. Validate your email address in the resulting dashboard. The validation will be in force for 30 days.
  3. Validate every domain you wish to renew.
  4. Generate the certificate for the domain you are renewing.
    1. Select the StartCom SSL Certificates Wizard.
    2. Choose Web Server SSL/TLS Certificate, and click Continue.
    3. Your validated domain should show in the list. Enter the domain you’re generating the keys for into the “Please enter your full hostname here” input field.
    4. Under “Please submit your Certificate Signing Request (CSR):” select “Generated by Myself”. You can use the form, but generally I remember reading that it’s more secure for you to generate your Certificate Request (CSR) and private key from it yourself, using an offline OpenSSL script invocation. The present a suitable openssl command invocation, to which I added the -subj option to avoid having it prompt me for that information:
      openssl req -new -newkey rsa:2048 -nodes -out eldon.me.csr -keyout eldon.me.key -subj "/C=US/ST=Georgia/L=Mableton/O=Eldon Carl Blancher III/CN=eldon.me"
      
    5. Copy the content of the CSR into the resulting form. It will look something like this:
      • -----BEGIN CERTIFICATE REQUEST-----
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTEDDD
        BLAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
        OBFUSCATTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTED==
        -----END CERTIFICATE REQUEST-----

        The actual code has been obfuscated to protect it, I highly doubt that’s a valid CSR now.

    6. Click “Submit.” If the CSR is accepted, the resulting page should provide a link to the new certificate files (the “here” link), as a ZIP archive.
    7. Download and unpack the archive. There are several ZIP archives with in it, one for some possible web servers. The Apache.zip file contained two files:
      • 1_root_bundle_crt, renamed to startcom.crt
      • 2_eldon.me.crt, renamed to eldon.me.crt

        Now that the certificates are generated, I need to add them to my apache2 web server.

      1. My current sites-available/eldon.me apache2 configuration looks like this:
        <VirtualHost *:80>
        DocumentRoot /var/www/eldon.me
        ServerName www.eldon.me
        ServerAlias eldon.me
        ServerAdmin trey@blancher.net
        ErrorLog /var/log/apache2/eldon.me-error.log
        TransferLog /var/log/apache2/eldon.me-access.log
        RedirectPermanent / https://eldon.me/
        </VirtualHost>
        
        <VirtualHost *:443>
        ServerName www.eldon.me
        ServerAlias eldon.me
        ServerAdmin trey@blancher.net
        SSLEngine on
        SSLProtocol all -SSLv2 -SSLv3
        SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
        SSLCertificateFile /etc/ssl/certs/eldon.me.pem
        SSLCertificateKeyFile /etc/ssl/private/eldon.me.key
        SSLCertificateChainFile /etc/ssl/certs/startcom_sub.class1.server.ca.pem
        SSLCACertificateFile /etc/ssl/certs/startcom_ca.pem
        DocumentRoot /var/www/eldon.me
        Customlog /var/log/apache2/eldon.me-access.log combined
        ErrorLog /var/log/apache2/eldon.me-error.log
        HostnameLookups On
        </VirtualHost>
        
        <Directory /var/www/eldon.me>
                Options FollowSymLinks            
        #       AllowOverride Limit Options FileInfo
          AllowOverride All
                DirectoryIndex index.php
        </Directory>                                  
        
      2. I changed these three lines:
        SSLCertificateFile /etc/ssl/certs/eldon.me.crt
        SSLCertificateKeyFile /usr/local/apache/conf/eldon.me.key
        SSLCertificateChainFile /usr/local/apache/conf/startcom.crt
        
      3. Reload apache2, and the new SSL certificate is loaded!

Migrate install to new VPS…

I have a ChunkHost Virtual Private Server (or VPS), and I ran into a predicament. I will admit my Debian knowledge is ever increasing, and now that sid has “thawed” its package selection is much more mercurial. Currently, this poses a problem for my web sites hosted on the VPS: amberandtrey.us, and this site (eldon.me). At the moment, Sid is going through a particular transition: apache-2.2 to apache-2.4. Thus many of the packages I need are in flux, and on any given day it could be horribly broken. I decided to switch back to Wheezy, but there’s no real way to downgrade. I’d have to reinstall.

ChunkHost gives a really (insidiously) easy way to fire up a new VPS (called a “chunk”). Within minutes I had my betachunk. My first chunk was called “alphabouncer” by me because I originally intended it to be an IRC bouncer (so if someone were to attack my IP address they’d be attacking my chunk, not my home IP address), but I digress. It wasn’t a simple matter of just copying files; I had to back up the MySQL databases, back up the WordPress files, copy my WeeChat configuration, restore it all, set the DNS server to point both domains at the new IP address, and coax it into working.

NOTE: All of the commands were performed within my backup directory, /root/backup/2013-06-15, unless otherwise noted.

  1. The first thing I did was to backup the databases. Since both websites use their own databases within the confines of the single MySQL instance, I needed to ensure the mysqldump command captured all databases. To conserve space, I ran the results through bzip2. The command I used was this:
    mysqldump -u root -p --all-databases --events | bzip2 -c - > websites_$(date +%F).sql.bz2

    All events may not have been necessary (and possibly problematic if the database is in active use at the time of the dump), but mysqldump will issue a warning if that flag is not passed. These are small enough databases that grabbing the events should not pose a problem.

  2. The next task was to back up the WordPress files. These lived in two places: /usr/share/wordpress for amberandtrey.us, and /var/www/eldon.me. I wanted to move amberandtrey.us to /var/www/amberandtrey.us to be more orthogonal with my directory structure, but more on that below. I also grabbed /etc and /root in case I needed them (I definitely did, mainly for SSL certificates, apache2 and WordPress server files). In order to back these up, I just used the standard tar commands:
    tar -cvjf amberandtrey.us_$(date +%F).tar.bz2 /usr/share/wordpress tar -cvjf eldon.me_$(date +%F).tar.bz2 /var/www/eldon.me/ tar -cvjf etc_$(date +%F).tar.bz2 /etc tar -cvjf alphabouncer-root_$(date +%F).tar.bz2 --exclude=backup --exclude=downloads --exclude=.cpan /root

    I used the excludes because the destination is in /root/backup, and I didn’t need to have all the cruft lying around on the new server.

  3. To copy my Weechat configuration, I created a matching username on the new VPS (betachunk). Rather than tar up my ~/.weechat directory, I used Midnight Commander (or “mc” for short) on alphabouncer to select the directory and copy it over. Since the two VPSes are in the same data center, I thought the transfer would occur quickly. It did, but some of the logs were still outrageously large, so it took a few minutes to complete.
  4. Restoring it all was a little tricky, compounded by the fact that I wanted to make minor structural changes to some of the WordPress directory layout. I copied the contents of alphabouncer:/root/backup/2013-06-15/* to betachunk:/root/backup/2013-06-15/. I can’t remember exactly, but I think I used mc to copy the entire backup directory over. I first changed directory (“cd”) into the backup directory, and untarred the etc backup file to the current directory (a nonstandard location) because I was going to copy the files one at a time using the command:
    tar -xvf etc_2013-06-15.tar.bz2

    I first copied over all of my SSL files for both sites, and the StartCom (my cert provider) files as well. This included everything for /etc/ssl/certs and /etc/ssl/private.

  5. Next I unpacked amberandtrey.us, created the directory where I wanted the files to ultimately live, and move the resulting files into that directory:
    tar -xvf amberandtrey.us_2013-06-15.tar.bz2 mkdir -p /var/www/amberandtrey.us mv usr/share/wordpress/* /var/www/amberandtrey.us

    I then repeated the process with eldon.me:

    
    tar -xvf eldon.me_2013-06-15.tar.bz2
    mv var/www/eldon.me /var/www/
    
    
  6. The next step was the tricky part. I had to restore all databases, but the database server MySQL hadn’t been installed yet (installing the wordpress package did NOT resolve this dependency!):
    aptitude install mysql-server

    Installing the mysql-server package prompted me to set the root password, but I still needed to copy the /etc/mysql/debian.cnf file from the previous installation. This allowed the MySQL daemon to start cleanly.

  7. The final step in transferring the WordPress sites to betachunk was to set up the /etc/wordpress/config-*.php files. Copying them from the restored /etc backup location, and we were almost in business.
  8. Since I was using SNI (Server Name Indication, see my KeePassX database merge topic for a brief discussion of this), I’d need to tie the new IP address to both domains. ChunkHost has a neat little DNS tool that can be used to do this. Since at my domain registrar (GoDaddy, I use them because they were convenient when I bought my first domain, and inertia keeps me with them) already has the ChunkHost nameservers for both domains, I just needed to update ChunkHost’s DNS server with the new IP address, and I was running!

Well, I thought I was running. amberandtrey.us worked no problem, but eldon.me had issues. Apparently I have the error log for eldon.me in a weird file (it’s not /var/log/eldon.me-error.log, like it probably should be). This has now been corrected. Anyway, I had to run “ls -al /var/log/apache2/” in a watch command to see what file was changing when I tried accessing eldon.me (and was getting a 500 Internal Server Error):

watch -n 1 ls -al /var/log/apache2

I saw the nonstandard log file (eldon.me-ssh-error.log) changed size and modification date/time, so I investigated that file. I found these errors:

[Sat Jun 15 03:33:14 2013] [error] [client 216.207.245.1] PHP Warning: require_once(/etc/wordpress/config-eldon.me.php): failed to open stream: Permission denied in /var/www/eldon.me/wp-config.php on line 19, referer: https://eldon.me/wp-admin/post-new.php [Sat Jun 15 03:33:14 2013] [error] [client 216.207.245.1] PHP Fatal error: require_once(): Failed opening required '/etc/wordpress/config-eldon.me.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/eldon.me/wp-config.php on line 19, referer: https://eldon.me/wp-admin/post-new.php

That led me to believe that /etc/wordpress/config-eldon.me.php did not have the correct permissions. I changed the ownership to www-data, and set the permissions to match the config-amberandtrey.us.php. Now eldon.me works!

Whew, what a long post! It took me longer to write than I would have expected because I ran into the problems on eldon.me (the server providing the WordPress post form I’m using). We’ll see if it lets me post it!

KeePassX Database merge…

I’ve done a lot in the past three weeks. I finally went back to Mardi Gras in New Orleans, something I haven’t been able to do since I started working in Huntsville. I also managed to move this site to my old VPS. The edis.at OpenVZ VPS was a little under powered for my tastes, though its pricing is very attractive. Turns out the original Apache2 documentation I first found (I can’t find the link for the life of me) was wrong: you CAN have multiple SSL sites behind one IP address, thanks to a browser extension: Server Name Indication (SNI). This Google search should help you find the appropriate articles to set it up. All I did was backup both WordPress database on my two sites, backup both sets of WordPress files, copy the relevant apache2 configurations over to my ChunkHost, restore the database to the new server, and restore the WordPress files (to a different web-root). It worked like a charm!

While I was in Mobile last week, my ISP (Knology) decided to do some network maintenance. My IP address changed, and my pfSense router hadn’t been configured to automatically obtain a new lease. Thus I was unable to reach my KeePassX database. I will get to the KeePassX database merge below. To rectify the WAN DHCP lease problem, I discovered these instructions. Since Knology changes my IP address so infrequently, I’m not likely to even notice the problem until I look at my IP address.

When I was down in Mobile last week, I went to the USA Career Fair to seek employment in Mobile. Got a lot of good leads, so I started filling out online applications. However, saving my passwords to KeePassX proved to present me a problem: I didn’t have access to my password database via sshfs. This meant I had to use my local copy. This meant that anything I added or deleted from the local copy wouldn’t be reflected in my master database. When I got back to Huntsville, and sorted out my WAN connection problem, I needed a way to merge the databases (I did not want to do it by hand).

I noticed that KeePassX has import and export functions, but no explicit merge. I didn’t want to import the laptop local database into the master, since I was afraid of a lot of duplicates. I did find this KeePassX forum topic, that presents some solutions. The patch that was linked isn’t directly accessible to the public, and it’s unclear whether it was added to keepassx on Debian sid. However, further down that page, someone had posted a public-domain Python script which will merge the two databases. Here’s a link to the script. I backed up my databases in case something went wrong, and actually renamed my master database to avoid overwriting it in place.

Basically you provide three XML database names, the first source, the second source, and the destination file. However, it only seems to add the entries that are in both files, plus the ones that are only in the first. Since I had entries that were unique to both files, it appears that all I had to do was run kdb-merge twice, and just swap the first and second source. This is essentially what I ran:


kdb-merge master.xml laptop.xml merged.xml
kdb-merge laptop.xml master.xml merged.xml

The true test was loading up the merged.xml file into KeePassX. I loaded a new, blank database (which it turns out I didn’t have to do; importing an XML file apparently creates a new database). I then made sure the different entries from both files were there. I still have the backup files, should something be missing or be totally wrong.

One final step was to shred the XML files, since they contain the passwords in plaintext format. A simple rm/remove/delete would not do, since most disks don’t overwrite a deleted file (and its contents remain on disk). Perhaps if I had SSDs in this system it’d be different. That’s for the next workstation.

StartCom SSL intermediate certificate chain fix…

In the past year I’ve installed two SSL certificates from StartCom, for my two websites: amberandtrey.us, and eldon.me. Both of these sites (now) are running Debian Sid, and have almost identical configurations. For most browsers/devices I’ve tried, the StartCom SSL certificates work fine (notice the appropriate lock icon in the address bar [in Google Chrome/Chromium it’s a green lock icon]). However, on some devices–most notably my Samsung Galaxy S II running CyanogenMod 9.10, and my mother’s aging iMac–I get a message similar to the following following:

(Sorry for picking on you Midnight Commander, but yours is a website I know generates this error for me consistently. Maybe I can link to this post and have you fix that!)

Searching for the string “entity is not trusted” on the StartCom forums guided me to this posting, which suggests using a free tool called SSL Checker to verify that my SSL installation is complete and without problems. The site gives me the following:

So it is verified that my SSL certificate is not trusted by all browsers. They give a hint back to StartCom’s extensive FAQ. It led me to the Apache Web Server configuration page. I needed to copy both the ca.pem and sub.class1.server.ca.pem, and configure apache2 appropriately (in the sites-available/eldon.me configuration file). My configuration ended up being like this:



DocumentRoot /var/www/eldon.me
ServerName eldon.me
ServerAlias www.eldon.me
ServerAdmin trey@blancher.net
ErrorLog /var/log/apache2/wp-error.log
TransferLog /var/log/apache2/wp-access.log
RedirectPermanent / https://eldon.me



SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
SSLCertificateFile /etc/ssl/certs/eldon.me.pem
SSLCertificateKeyFile /etc/ssl/private/eldon.me.crt
SSLCertificateChainFile /etc/ssl/certs/startcom_sub.class1.server.ca.pem
SSLCACertificateFile /etc/ssl/certs/startcom_ca.pem
DocumentRoot /var/www/eldon.me
Customlog /var/log/apache2/eldon.me-ssh-access.log combined
ErrorLog /var/log/apache2/eldon.me-ssh-error.log
HostnameLookups On



  Options FollowSymLinks
  AllowOverride Limit Options FileInfo
  DirectoryIndex index.php


I was missing the ChainFile and CACertificateFile, and I added the extra bits about CipherSuite and Protocol. Now the SSL Checker validates everything on eldon.me. The same configuration isn’t working for amberandtrey.us, the checker says “No SSL could be found,” yet my browser indicates SSL is active and enabled. I’ll have to do a closer comparison… [Edit 2013-01-27 0554 -0600]Looks like the SSL certificate is tied directly to www.amberandtrey.us (which redirects to amberandtrey.us). The opposite problem exists for eldon.me. If I have the SSL Checker scan www.eldon.me, it says “No SSL could be found.” Must be a difference in the way I set up the SSL certificates.

Now I can be sure that folks won’t have to click through an SSL warning when they visit my sites!