Apache being Apache, can do something really interesting with virtual host setups. If you access the server by a domain that isn’t explicitly mapped to a virtual host, it’ll default to the first virtual host it encountered in its configuration files. This is pretty neat, extremely useful, and – annoying in this case, as attempting to access the site via https is possible (since the domain is pointing to the system) but going to a place it should not be – the third-party application, which is the only SSL vhost set up.

Could’ve set up another vhost for SSL for the main site(s); the problem with that is Apache’s handling of SSL (IP based) and the fact that it’d require yet-another-expense – this would require a valid SSL certificate, as it’s hard to argue that going to https://mycoolsite.foo isn’t customer-facing, even if unintentional.

Solution is simple: quick cluster of rewrite rules to push anything not matching the domain of the third-party, SSL-using application, to non-https:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^crazyapplication.mycoolsite.foo$ [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}

Naturally, replace crazyapplication.mycoolsite.foo with whatever.

So, what happens after the fact is this: Aside from the single domain we want covered by SSL, we’re simply redirecting https to http.

There are other ways to do this, of course, but tactical use of mod_rewrite generally avoids the backing oneself into a corner syndrome.

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/?(.*)$ http://TARGETDOMAIN/$1 [L]

Drop this sucker in, swap out ‘TARGETDOMAIN’ with where you want your 404′d files redirected to. Bah.

Likewise, there are three reasons to use SSL. To protect your and your clients’ passwords, to secure e-commerce transactions, and to keep Karl Rove from outing you as a CIA operative.

Of course, going into some sort of retirement, I’d imagine Mr. Rove won’t be committing much more high treason, but I’m sure he’ll be kicking back, playing a little shuffleboard on the weekends, and probably reading your e-mail.

The second fall of Rome aside, SSL is always a good idea. If there’s one thing the Internet needs, it’s more security. Of course, SSL is pissing into the wind – almost all of our efforts are pissing into the wind. We’re never going to stop users from opening “WICKED COOL SCREENSAVER!!!!!!1111.EXE” – that must not deter our course, brothers.

Of course, SSL costs money, doesn’t it? Screw that, hey?

No, it doesn’t necessarily cost a dime. If you have users that can understand very simple sentences of three to four words, words that have no more than three syllables, you can deploy self-signed SSL certificates in places that don’t justify blowing $50-$300 on a genuine signed-by-some-money-grubbing-certificate-authority certificate.

Let us proceed with the rocking:

yum -y install mod_ssl

This will get you mod_ssl, which should in turn get you everything you need. And possibly then some, depending on what you’re setting up. For our purposes, I’m pretending you need an SSL-secured webmail installation. I’m also assuming you’re setting up SSL for a virtual host, simply because I have virtual hosts on my box, and damned if I’m setting up another VE for you people.

openssl genrsa -des3 -out domain.name.key 4096

Enter pass phrase for domain.name.key:

Why 4096? I like big numbers. domain.name should be your domain; for example, for foo.com, use foo.com.key. This standard will continue through the rest of the commands.

Enter a passphrase. Make it stupidly complex, something you won’t remember and can’t type without looking at it. But be sure to store it in a safe place. Your hard drive is not a safe place. Nor is a post it not attached to your monitor.

openssl req -new -key domain.name.key -out domaine.name.csr

A challenge password []:
An optional company name []:

This is a certificate signing request, and it’s how you get a certificate – any certificate, be it self signed or not. The first prompt will be the pass phrase you created while generating domain.name.key.

As for the rest, since we’re self-signing, the values here don’t really matter all that much for the most part. If you’re running a respectable business and this is for some sort of internal mail server, you’ll likely want to use acceptable, ‘real’ values. If this is for personal use, I heartily endorse the idea of insisting you’re the Queen of England.

A word about e-mail address – I recommend you have a ‘hostmaster@your.domain’ set up. It’s damned useful for using for this sort of thing, as well as actual domain registration contact info. (Helps prevent you from being spammed just because you own a domain.) But really, you can use any e-mail address you wish. (Assuming it’s your e-mail address.)

I’ve never yet filled in a challenge password or an optional company name. Next.

cp domain.name.key domain.name.key.bak
openssl rsa -in domain.name.key.bak -out domain.name.key

chmod go-rwx domain.name.key
chown root:root domain.name.key

Again, this is the pass phrase from the first step. What are we doing here? We’re (*gasp*) removing the encryption from the key. Why? Because sooner or later your server is going to have a problem at three in the morning, and your hosting company, being the nice people they are, are going to try to fix it. We want them to be able to restart Apache, yes?

The problem with encrypted keys is, Apache won’t start without which you enter the passphrase. If your system goes down for any reason and comes back up, it’ll be stuck in boot, waiting for you to type in the passphrase. If something happens and Apache needs to be restarted, same deal. Bad thing, all around.

The last two commands, by the way, ensure that only the root user can read the key. Thus, if someone manages to read the key, you have bigger problems anyhow, because your system has been wtfpwned.

openssl x509 -req -days 999 -in domain.name.csr -signkey domain.name.key -out domain.name.crt

Congratulations, you now have a self-signed SSL certificate. Now it’s time for some Apache configuratin’:

cp domain.name.csr /etc/httpd/conf/ssl.csr
cp domain.name.crt /etc/httpd/conf/ssl.crt
cp domain.name.key /etc/httpd/conf/ssl.key

vi /etc/httpd/conf/ssl.conf

In this file, you want to find:

<VirtualHost _default_:443>

…And comment it out. Comment everything out that isn’t commented out, until you reach:

</VirtualHost>

…And comment that out, too. Then save and exit.

vi /etc/httpd/conf/httpd.conf

Time to set up your real virtual host entry. Here’s an example of one:

<VirtualHost IPADDRESS:443>
ServerName HOSTNAME
DocumentRoot /path/to/html
ErrorLog /path/to/error_log
CustomLog /path/to/access_log combined
SSLCertificateFile /etc/httpd/conf/ssl.crt/domain.name.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/domain.name.key
SSLEngine on
</VirtualHost>

IP address is naturally the IP address of your system, or at least the IP address the domain you’re using is pointing at. ServerName is the hostname, and should be what you listed for ‘Common Name’ on the certificate signing request. The rest, I leave to you. Anyhow, once done, restart Apache:

/etc/init.d/httpd restart

Open your web browser, go to your domain, using https instead of http. You should get a little window. The message varies with your browser, but should basically say, ‘Oh noes, I don’t recognize this Certificate Authority!11111111111′

If you want, examine the details, but unless you did something really wrong, it should be your certificate. FireFox, at least, will allow you to accept the certificate permanantly; which if you’re setting up an internal site or something for a company, might be a good idea to click. (Less confused users.)

No such option with IE – at least not IE6. Such is life, but you now have SSL, even if Microsoft doesn’t recognize you as a certificate authority.

It’s okay; after all, no one respects their authority, either.

So what’s next? You now have SSL on a domain. You can set up all sorts of crazy things, or you can do something useful and set up webmail or something. The sky is the limit, or some such.