Apache and SSL – The Easy Way

It’s no secret–SSL is confusing. Creating and signing certificates is a convoluted process, especially from the command line. Fortunately, Debian-based systems have an easy way for Apache users to create, sign, and install their own SSL certs. This tutorial assumes that Apache is already installed with the default configuration.

### Configure SSL ###

Step one is to configure Apache to enable `mod_ssl`:

# a2enmod ssl
Enabling module ssl.
See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates.
Run ‘/etc/init.d/apache2 restart’ to activate new configuration!

The documentation referred to by that script’s output explains that, on Debian systems, an SSL certificate is installed automatically when the `ssl-cert` package is installed. It also outlines the process of creating a new certificate (useful when usen name-based virtual hosts). From the manual:

> If you install the ssl-cert package, a self-signed certificate will be
> automatically created using the hostname currently configured on your
> computer. You can recreate that certificate (e.g. after you have
> changed /etc/hosts or DNS to give the correct hostname) as user root
> with:
> make-ssl-cert generate-default-snakeoil –force-overwrite
> To create more certificates with different host names, you can use
> make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /path/to/cert-file.crt
> This will ask you for the hostname and place both SSL key and
> certificate in the file /path/to/cert-file.crt . Use this file with the
> SSLCertificateFile directive in the Apache config (you don’t need the
> SSLCertificateKeyFile in this case as it also contains the key). The
> file /path/to/cert-file.crt should only be readable by root. A good
> directory to use for the additional certificates/keys is
> /etc/ssl/private .

So, let’s create a new virtual host–one which can only be accessed via SSL.

Use the syntax from the manual to create a new certificate:

# make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/private/securehost.crt

When prompted, enter a hostname for the virtual host. For this example, the hostname is `securehost`.

### Create the Virtual Host ###

Once SSL is configured, it’s time to create the virtual host which will be accessed via SSL. Create the file */etc/apache2/sites-available/securehost* containing the following:

ServerName securehost

SSLEngine on
SSLCertificateFile /etc/ssl/private/securehost.crt

The above example assumes knowledge on how to configure a virtual host. Much of the necessary configuration has been omitted and replaced with an ellipsis.

It may be desirable to redirect port 80 traffic addressed to this hostname so that visitors do not have to explicitly designate the `https://` protocol. To do this, rename the virtual host file you just created to *securehost-ssl*, then create a new file called *securehost* containing the following:

Redirect / https://phpmyadmin/

### Configure Apache ###

All that’s left is to configure apache to recognize the new virtual hosts. The first step is to enable them:

# a2ensite securehost securehost-ssl
Enabling site securehost.
Enabling site securehost-ssl.
Run ‘/etc/init.d/apache2 reload’ to activate new configuration!

Before reloading Apache, it may be necessary to enable name-based virtual hosting for ports 80 and 443. In Debian, this is done in the file */etc/apache2/ports.conf*. Look for the lines that say `Listen 80` and `Listen 443`. Add the following options:

NameVirtualHost *:80
Listen 80

NameVirtualHost *:443
Listen 443

Finally, reload Apache to reflect the new configuration:

# service apache2 reload

### Try It ###

Now try navigating to https://securehost. This will most likely result in a certificate warning, which can be ignored/bypassed. Assuming that the document root contains an index page, it should be displayed here.

Once successful, try removing the **s** in the protocol to test the redirection from port 80. If redirection is working properly, the location bar in the browser should update to include the **s** again and the index page should again be displayed.

### Other Tips ###

It is possible for the same hostname to serve completely different sites based on the port specified. For example, a corporate site may display generic marketing info for visitors to port 80, but employees know that they need to use `https://` to access the login area. This keeps visitors from being presented with irrelevant employee prompts, and ensures that all employees are logging in securely.


SSH From the Inside

### Problem ###

I need SSH access to a particulr machine (*schoolsvr*) which is behind a NAT. I only need to enable access from a single client (*homesvr*), which has a public IP address of its own. Both machines are running **sshd**. I can access *homesvr* from a shell on *schoolsvr*, but not vise-versa.

If I had admin access on *schoolsvr’s* gateway, I could alter the NAT to forward some unused port (say, 12345) to *schoolsvr:22*, which would allow me to SSH to *schoolsvr* using the gateway’s public IP and port 12345. Unfortunately, I don’t have admin access to the gateway.

How do I enable SSH access to *schoolsvr*?

### Solution ###

The solution is to open an SSH tunnel from *schoolsvr*, which I can access from a shell on *homesvr*. To achieve this, I use the OpenSSH client program’s `-R` option to bind an SSH tunnel to a non-standard port on *homesvr*. Consider the following command:

nick@schoolsvr$ ssh -R 12345:localhost:22 nick@homesvr
nick@homesvr’s password:

This command connects to *homesvr* via the standard SSH port (22) and binds that connection to the specified bind port (12345). This port remains bound until the SSH session is terminated. Now all SSH traffic directed to port 12345 on *homesvr* will be forwarded to port 22. When I get back to *homesvr*, I can open a new SSH session with *schoolsvr* using the following command:

nick@homesvr$ ssh -p 12345 localhost
nick@localhost’s password:

I’m in! I can terminate this session when I am finished, and the original tunnel remains open until I kill it on *schoolsvr*.

This command can be set up in */etc/inittab* (or an Upstart config file, depending on your system configuration) with the `respawn` action, which would ensure that the tunnel is open upon boot and will be automatically reopened upon termination. Note that such a setup requires the appropriate SSH keys to be configured on both machines, as an init process can’t enter a password.

Because each half of the connection is done using SSH, this setup is completely secure. Of course, anyone with physical access to *schoolsvr* would have full control over the open login to *homesvr*. To prevent this, I can modify the original command as follows:

nick@schoolsvr$ ssh -nNT -R 12345:localhost:22 nick@homesvr &

The `-n` option redirects standard input from */dev/null*. The `-N` option is specifically designed for port-forwarding applications such as this, and tells SSH not to bother preparing a command stream for this connection. The `-T` option tells the remote host not to bother allocating a pseudo-tty for this connection. These three options eliminate the possibility of using this open tunnel to execute any other processes on *schoolsvr*. Additionally, I appended an ampersand (`&`) to send the process to the background. Now I can close the shell in which I ran the command without killing the process.

### Conclusion ###

While not as elegant as a true NAT-based port forwarding solution, reverse SSH tunnels are a fast, secure way to connect two remote machines for general use. When used with discretion, they can be a real time-saver.

What do you think of this solution? Did I leave anything out? Let me know in the comments.


Linux Server: to Reboot or Not to Reboot?

Linux servers have a reputation as workhorses. Since very early in the
development of Linux, its users have boasted in the stability of the
OS. In fact, it is not uncommon to hear of Linux-based servers running
for years without the need for a reboot. This raises the question: how
often should you reboot your Linux server?

Months and months of server uptime can be a good thing (and for some,
even cause for boasting), but is it wise to go such a long time without
rebooting? I would strongly argue that it is not. In fact, a wise
server recovery/contingency plan will include reboots as part of a
regular maintenance schedule. Below I outline some reasons why you
should reboot your server on a regular basis.

### Kernel Upgrades ###

The Linux kernel is under constant development. New drivers are always
being written, old ones are rewritten, bugs are patched, and security
holes are plugged. These upgrades generally result in a system that is
faster, safer, and more reliable. Package managers upgrade the kernel
regularly in most distributions. But even if your distribution doesn’t
automatically upgrade your kernel, for the aforementioned reasons you
should make it a point to do so periodically.

In order for the upgraded kernel to run, the system needs to be
rebooted. Some distros notify the user when a reboot is required, but
it is ultimately the responsibility of the sysadmin to know what
software is being upgraded and what actions those upgrades require.

### Real-World Reliability Testing ###

Any sysadmin who has been at it for a while has experienced this

Something happens that causes the server to shut down–perhaps a
hardware addition/replacement, power loss, or the need to move the
machine. Once the interruption is over, the admin boots the server only
to find that things aren’t working as they should. Some critical
service failed to start properly. What happened? As software packages
are updated and new versions are released, many variables come into
play that affect normal operation of that software. A configuration
setting might become deprecated. A hack that was used to fix a bug in
an old version, may render the new version useless. The list goes on.

As the time between reboots increases, so does the likelihood that some
service will not initialize properly. These errors take time to
diagnose and correct, which translates to unacceptable server downtime.
This problem is compounded when two or three issues occur on a single
reboot. Rebooting on a regular schedule allows the sysadmin to catch
these types of errors quickly. It also provides time to correct the
errors without workflow grinding to a halt, as users are informed ahead
of time that the server will be down for maintenance.

While it is true that services can be restarted individually, nothing
can accurately simulate a full reboot. And the longer you wait between
reboots, the greater the chance of something going wrong. Remember:
*You will never experience a routine reboot until you implement a
reboot routine.*


Making Bootup Music with beep and rc.local

In my house I run a headless server which I administrate via SSH. I reboot the server regularly, but because there is no monitor there is no way of knowing when the machine is finished booting (since, of course, my SSH connection is terminated during reboot). In a situation like this you can just ping the server’s IP until you get a response, then log in via SSH, check the logs, and make sure everything is
running properly.

But rather than having to ping the server we can use a program called **beep** and the startup script */etc/rc.local* to let us know when the machine has finished booting.

As you may know, */etc/rc.local* is a startup script which runs at the end of the boot process, after everything else, immediately before the login prompt appears. It is usually empty by default. There are a handful of reasons why someone might need to modify *rc.local*. As the post’s title suggests, we will use it in conjunction with beep to make our machine play some bootup music.

**beep** is a program that beeps the PC speaker. It may or may not be installed by default in your distribution, but it is almost certainly available in the repositories. beep is highly configurable and allows for any number of beeps, of any duration, at any frequency. After reading the beep man page, I got my music on and wrote a couple of bash scripts to play some simple tunes. I saved the scripts in */usr/local/bin*, and added one of them to */etc/rc.local*. Now when my server finishes rebooting it plays the Imperial March! If you have beep installed, give it a try:


beep \
-f 392 -l 450 -r 3 -D 150 \
-n -f 311.13 -l 400 -D 50 \
-n -f 466.16 -l 100 -D 50 \
-n -f 392 -l 500 -D 100 \
-n -f 311.13 -l 400 -D 50 \
-n -f 466.16 -l 100 -D 50 \
-n -f 392 -l 600 -D 600 \
-n -f 587.33 -l 450 -r 3 -D 150 \
-n -f 622.25 -l 400 -D 50 \
-n -f 466.16 -l 100 -D 50 \
-n -f 369.99 -l 500 -D 100 \
-n -f 311.13 -l 400 -D 50 \
-n -f 466.16 -l 100 -D 50 \
-n -f 392 -l 500 -D 100

The frequencies for the notes came from a page which you can find linked in the *Additional Resources* below. I must warn you, if you are not musical you are going to have a very hard time authoring your own beep music. But if you are up for the challenge, it is the geekiest music you will ever write. Like, geekier than [Pocket Calculator](

### Additional Resources ###

[An introduction to services, runlevels, and rc.d scripts]( –
[Arch Boot Process]( –
[Frequencies of Musical Notes](