trey – discursions

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.

Go to the main site, and log in with your StartSSL Open Identity certificate. Create one if need be.
Validate your email address in the resulting dashboard. The validation will be in force for 30 days.
Validate every domain you wish to renew.

Generate the certificate for the domain you are renewing.

Select the StartCom SSL Certificates Wizard.
Choose Web Server SSL/TLS Certificate, and click Continue.
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.
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"
```

Copy the content of the CSR into the resulting form. It will look something like this:

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

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.

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.

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>

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

Reload apache2, and the new SSL certificate is loaded!

ip command nuggets

View IP address related information (all interfaces):

ip address

ip a

View the ARP table

ip neighbors

Cross-reference the IP addresses in the ARP cache with their local hostnames (if known). Replace “@localhost” with the hostname/IP address of the DNS server you want to query, or remove it altogether to use the system’s default DNS server:

for ip in $(ip nei | awk '{print $1}'); do dig -x $ip @localhost | grep "in-addr.arpa"; done

Or, wrapped in a shell function:

arp () {
  for ip in $(ip nei | cut -d' ' -f1); do 
    dig -x $ip @localhost | grep "in-addr.arpa"; 
  done
}

Arch Linux installation (lvm2)

After my power went out here while I was on an extended vacation, I realized the folly in having a completely encrypted drive that could only be unlocked via a locally entered password. Ideally GRUB and the kernel could be configured to probe the network to develop a fingerprint of its devices, and unlock automatically without any further keys if all devices are present. Otherwise, unlock via entered password. This is a task for another day.

My current task is to install a plain, unencrypted Arch Linux installation to my old workstation (lithium). I have a new SSD, and I want to document the process of installation (mainly so I can follow it again). It is adapted from my Encrypted Disk instructions.

# BIOS partition, since all of the systems I'll be installing this in the immediate future are all BIOS, not EFI/UEFI
parted -s /dev/sda mklabel gpt mkpart bios 2048s 4096s
parted -s /dev/sda set 1 bios_grub on
parted -s /dev/sda mkpart primary ext2 6144 100%  # Fill the rest of the disk
parted -s /dev/sda set 2 lvm on
pvcreate /dev/sda2
vgcreate vg /dev/mapper/lvm
lvcreate -L 16G vg -n swap
lvcreate -L 50G vg -n root
lvcreate -l +100%FREE vg -n home
mkswap -L swap /dev/mapper/vg-swap
mkfs.ext4 /dev/mapper/vg-root
mkfs.ext4 /dev/mapper/vg-home
mount /dev/mapper/vg-root /mnt
mkdir /mnt/home
mount /dev/mapper/vg-home /mnt/home
swapon /dev/mapper/vg-swap
pacman -Syu reflector
reflector --country US --verbose -l 10 --sort rate --save /etc/pacman.d/mirrorlist

Arch Linux encrypted drive (including /boot)

These instructions are adapted from Pavel Kogan’s blog post for an encrypted hard drive. The main difference between that post
and this one is the different options. I will be setting this on a system with 32GB RAM, and I prefer a GPT partition table. Everything else should be the same. The usual Arch installation guide should be followed.

Don’t forget to do the initial steps before partitioning disks! Things like connecting to the network, and updating the system clock.

# BIOS partition, since all of the systems I'll be installing this in the immediate future are all BIOS, not EFI/UEFI
parted -s /dev/sda mklabel gpt mkpart bios 2048s 4096s
parted -s /dev/sda set 1 bios_grub on
parted -s /dev/sda mkpart lvm # Fill the rest of the disk
cryptsetup luksFormat /dev/sda2
cryptsetup luksOpen /dev/sda2 lvm
pvcreate /dev/mapper/lvm
vgcreate vg /dev/mapper/lvm
lvcreate -L 16G vg -n swap
lvcreate -L 50G vg -n root
lvcreate -l +100%FREE vg -n home
mkswap -L swap /dev/mapper/vg-swap
mkfs.ext4 /dev/mapper/vg-root
mkfs.ext4 /dev/mapper/vg-home
mount /dev/mapper/vg-root /mnt
mkdir /mnt/home
mount /dev/mapper/vg-home /mnt/home
mkswap /dev/mapper/vg-swap
swapon /dev/mapper/vg-swap

…then continue with the usual Arch installation. Don’t forget to add the “lvm2” and “encrypt” hooks to /etc/mkinitcpio.conf when you get to that part! And definitely don’t forget to add the following lines to /etc/default/grub:

GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:lvm"

Then, run:

grub-mkconfig -o /boot/grub/grub.cfg
grub-install /dev/sda

I’ll post again once I’ve gone through this process, which I won’t be able to do for about a week. I will be going through it, modified, three times over the coming weeks, so I’ll really be able to stress it out and update any deficiencies.

Thoughts on this method

It works like a charm! The only hiccup is when booting GRUB prompts for the encrypted disk password, then the kernel asks for the same password when booting. The trouble with GRUB asking for it, if I mistype the password GRUB doesn’t prompt me a second time, and I’m dropped into the GRUB rescue shell (which isn’t self documenting). I will try this reddit thread which may be useful. The only other option is to reboot, and try again.

I guess the other problem is my BIOS is so slow! The RAID BIOS takes several seconds to boot. Also, decrypting GRUB and the disk takes a little longer than I’d like. Neither of these are problems with the method. None of these problems are showstoppers, since the only way to correct this is to replace the whole system. In any case, once the kernel begins to boot it takes less than two seconds before I’m at the GDM prompt! The power of dual-Xeon (8 cores), 32GB RAM, and an SSD (probably the biggest speed gain of all)!

I can already envision system replacing my NAS. I can attach up to 5 HDDs to the Marvell RAID controller, then leave them as discrete disks (JBOD) for use with Btrfs. Hopefully that filesystem will have matured enough to make it feasible (and reliable).

Further thoughts on this method

After a few weeks of using this, I ran into a major drawback to this scenario: if I am away from my house for an extended period, and my computer shuts down, I have to wait until I go back home before I can rectify it. As it stands, my power went out when I was away for the holidays, and it was nearly a week before I could go back and boot it up. It is unclear whether my Debian-based router would have booted back up fully, but that’s something entirely different. Thus, on my primary, fixed workstation, I have removed the encryption since I have at least one scenario where it would need to boot unattended.

I’ve kept this encryption method on my personal laptop, since that one always travels with me and is much easier to lose.