Thu, 19 Mar 2009
Unlocking Cryptography
Generating SSL Keys on Debian Linux
As reported in my last entry, I recently created updated SSL keys for my server. This is a somewhat arcane process, involving wizardly incantations on the command line. As a service to the community, I will now describe this process and provide a simple script to stramline the process.
First, the reason it was necessary to generate these keys is that the default Debian install creates keys that are only good for one year. Further, these keys are “snakeoil”; that is literally what the configuration calls them, which serves as a reminder to sys-admins that they are the default configuration (generally more exploitable), they are not part of a chain-of-trust (nobody else is vouching that you are who you say you are), and they potentially do not uniquely identify your server (setting up a series of servers with the same configuration can cause confusion among various connecting hosts).
These instructions apply to generating a self-signed key: just as with the default Debian key, nobody else is vouching that you are who you say you are. If you want to get an “official” key, you have several options, of varying expense:
Unless you are going to be selling something to the general public, or will be accepting payments from people you don’t personally know, however, these are all overkill. A self-signed cert will work just fine for you if you are using this server inside an organization where you have control over browser deployments, or if you are working with a technical audience of people you already know.
On to the steps!
Remember, these are specific to Debian GNU/Linux default installs. If your system is on another version of Linux, you’ve customized your install in some unusual way, or you’re using another OS, you will have to modify these instructions to match your environment.
Login as root:
sudo su -
Change directories to your SSL configuration directory:
cd /etc/ssl;
Create the seed for your private key:
openssl genrsa -out example.com.key 1024;
Use the seed to generate a public/private key pair request:
openssl req -new -key example.com.key -out example.com.csr;
Generate and sign the keys:
openssl x509 -req -days 365 -in example.com.csr -signkey example.com.key -out example.com.crt;
copy the old/default key to a timestamped file:
mv /etc/ssl/example.com.csr "/etc/ssl/example.com.csr.`/bin/date +%Y%m%d`";
Copy the old/default apache certificate to a timestamped file:
mv /etc/apache-ssl/apache.pem "/etc/apache-ssl/apache.pem.`/bin/date +%Y%m%d`";
Copy the new private key to the apache-ssl certificate:
cp -p example.com.key /etc/apache-ssl/apache.pem;
Sign the new apache-ssl certificate:
cat example.com.crt >> /etc/apache-ssl/apache.pem;
Change permissions on the certificate to avoid security issues:
chmod 600 /etc/apache-ssl/apache.pem;
Delete the originals:
rm /etc/apache2/apache.pem;
link the apache-ssl certificate to apache2’s, so you don’t deal with multiple certs when you don’t need to:
ln /etc/apache-ssl/apache.pem /etc/apache2/apache.pem;
copy the apache cert to the generic ssl cert library:
cp -p /etc/apache-ssl/apache.pem /etc/ssl/certs/ssl-cert-example.com.pem;
copy the private key to a restricted area:
mv ./example.com.key /etc/ssl/private/;
Change permissions on the private keys to ensure they remain private:
chmod 600 /etc/ssl/private/*;
change ownership on the private keys, as well:
chown root.ssl-cert /etc/ssl/private/example.com.key;
Move the public key into the certificate directory:
mv example.com.crt /etc/ssl/certs/;
Change permissions on the public keys, also:
chmod 600 /etc/ssl/hall*;
chmod 600 /etc/ssl/certs/example.com.crt;
chmod go+r /etc/ssl/certs/example.com.pem;
Restart Apache and your mailserver (I use Postfix rather than Exim) so that they reload their keys:
etc/init.d/./apache2 restart;
/etc/init.d/./postfix reload;
All done!
I’ve also written a script to automate this process. Feel free to use it, but remember I’m not responsible if it breaks anything.
Comments, criticisms, and corrections are welcome.
posted at: 01:00 | permanent link to this entryMon, 16 Mar 2009
Marvelously Modified Mailserver
Geeky Fun!
After spending a whole week of classroom time in a “System p LPAR and Virtualization I: Planning and Configuration” training session, this weekend I was feeling motivated to make a few changes. As I’d been deferring the (completely unrelated) migration of my email and SSH server to a new platform, it was time to take action!
This is a relatively large change for my small environment. Currently, I’m running a web server (Apache), a mail server (Postfix with SpamAssassin), a remote access server (SSH), Windows (Samba) and Unix (NFS) networking servers, some monitoring utilities (Monit), and various smaller functional programs.
Fortunately, the migration process was to be relatively painless. As I had planned for this, I already had mirrored the configuration from my “Old and Busted” system (based on an Intel Pentium III running at 800 MHz, and although rock solid, dreadfully slow), to the “New and Kewl” system (based on an Intel Xeon dual core, dual processor running at 2.3 GHz). All that needed to be done, then, was:
- At the router, stop accepting inbound email for the duration of the migration.
- Disable the Postfix daemon on OldAndBusted.
- Copy the user mailboxes from OldAndBusted to NewAndKewl.
- At the router, set inbound email connections to be directed to NewAndKewl.
And that should do it!
Except for the small item of ensuring that my users’ individual email clients are all configured to talk to NewAndKewl instead of OldAndBusted. Not a problem! I use DNS for my internal network, so I updated the DNS configuration to point mail.hallmarc.net at NewAndKewl, and everything was good.
Except the email clients were using the IP address rather than the fully-qualified domain name for the mail server. Uh. Dumb. Ah! but I can modify the configuration from the command line for all the kids accounts by logging in remotely and changing all of Thunderbird’s instances of OldAndBusted’s IP to NewAndKewl’s IP. Done and done. (Yes, I did have to use the GUI on my wife’s Windows XP PC to do this. One more reason not to support Windows.)
About using that GUI… Apparently my wife for months had been clicking through a dialog box every time she collected email. The dialog indicated that the mail server’s SSL/TLS certificates had expired. I only learned this because, yup, I used the GUI to change her server setting. So now I needed to update my server certs. Which will be the subject of my next blog entry.
posted at: 19:33 | permanent link to this entry
Marc Elliot Hall St. Peters, Missouri
Page created: 21 January 2002
Page modified: 31 December 2009
