Paranoid Penguin - Rehabilitating Clear-Text Network Applications with Stunnel
A Stunnel server—that is, a host that receives encrypted packets destined for a local clear-text service—requires a server certificate. A Stunnel client does not, however, unless you intend to configure your Stunnel server to use client-certificate authentication. Sadly, client-certificate authentication is beyond the scope of this article, so none of our examples require the client to have its own certificate—only the server does.
If you installed Stunnel after compiling from source and issuing a make install command, you've already got a server certificate (/usr/local/etc/stunnel/stunnel.pem). If you installed Stunnel from a binary package, the package's post-installation script may or may not have created a server certificate for you.
Fedora Core 1's Stunnel RPM creates an empty certificate for some reason. Needless to say, you need a proper certificate, and the way to do that on Fedora is to change your working directory to /usr/share/ssl/certs, type make stunnel.pem and copy stunnel.pem to the directory /etc/stunnel. This certificate, as with certificates created by the Stunnel source-release Make script, has no passphrase.
The Danger of Passphrase-Free Certificates
Using a server certificate that's been generated automatically or semi-automatically by a script is quick and convenient, but there's one problem: such a certificate nearly always is created with no passphrase. On the one hand, you can and should set the permissions and ownership on your certificate to make it root-readable only, so at least unprivileged users on your system aren't able to read and thus use it. On the other hand, if your system is root-compromised, your passphrase-free certificate then can be used and abused by the attacker.
This may be an acceptable risk for you, and indeed, using passphrase-free server certificates is a common practice. After all, it's inconvenient to require a human being to enter a certificate's passphrase every time Stunnel starts up. However, as a matter of principle, crypto experts widely consider it reckless to use passphrase-free certificates. If a process is sensitive enough to warrant cryptography in the first place, the argument goes, it's sensitive enough to require a human being to start that process.
If your Stunnel server system needs a server certificate, or if your automatically generated certificate doesn't meet your needs—for example, it lacks a passphrase—you need to generate your own, using the OpenSSL command. Space does not permit me to give a full, proper explanation of this powerful tool. Luckily, the Stunnel FAQ (see Resources) answers some of the most common questions about how OpenSSL and Stunnel interact, and it includes pointers to further sources of information about OpenSSL.
Suffice it to say that for some users, there may be a compelling reason to create their own Certificate Authority (CA), install their CA certificate (but not key) on every system running Stunnel and use their CA certificate to sign all server certificates. This is necessary, for example, if you want your Stunnel server systems to accept client connections only from Stunnel client hosts with particular certificates.
For many if not most Stunnel users, however, it's good enough to use self-signed certificates and to not worry about being or not being a CA. Here's how to generate a self-signed server certificate using OpenSSL.
Listing 1. Creating a Server Certificate with OpenSSL
nearclient:/etc/stunnel# openssl req -x509 \ -newkey rsa:1024 -days 365 \ -keyout stunnel.pem -out stunnel.pem Using configuration from /usr/lib/ssl/openssl.cnf Generating a 1024 bit RSA private key ...++++++ .............................................++++++ writing new private key to 'key2.pem' Enter PEM pass phrase: ************ Verifying password - Enter PEM pass phrase: ****** ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) :Minnesota Locality Name (eg, city) :St. Paul Organization Name (eg, company) :Wiremonkeys Organizational Unit Name (eg, section) : Common Name (eg, YOUR name) :nearclient.wiremonkeys.org Email Address :X.firstname.lastname@example.org nearclient:/etc/stunnel# chmod 600 stunnel.pem
In Listing 1, the real meat is in the first line. Parsing from left to right, this command tells OpenSSL to create a certificate request in the X.509 digital certificate format, using the RSA cipher with a 1,024-bit key, good for 365 days and with both its key and (public) certificate written to the same file, stunnel.pem. If you instead want to create a password-free certificate, you can include the -nodes option at the end. Read the sidebar “The Danger of Passphrase-Free Certificates” first, though.
Most of the rest of Listing 1 shows a dialog in which OpenSSL prompts me for X.509-type information to include in the certificate, including Country and Region. That stuff should be self-explanatory, but Common Name is very important. If you're creating a server certificate, the certificate's Common Name must be set to the fully qualified domain name (that is, the full hostname) of the host that is going to use the certificate.
Most SSL/TLS-enabled applications expect this Common Name to resolve by way of DNS to the IP address of your server. Stunnel does not unless you configure it to, but setting Common Name to your FQDN is a good habit to get into nonetheless.
In the last line of Listing 1, I've set the permissions of my new server certificate to 0600 (-rw-------). Because I ran my OpenSSL command as root, this file already is owned by root. It's important for any server certificate, whether it's password-protected or not, to be root-readable only. I ran my OpenSSL command from within /etc/stunnel, so my certificate was created in place, and I didn't have to move my new certificate there by hand.
- Handling the workloads of the Future
- Readers' Choice Awards 2014
- diff -u: What's New in Kernel Development
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- Synchronize Your Life with ownCloud
- December 2014 Issue of Linux Journal: Readers' Choice
- Non-Linux FOSS: Don't Type All Those Words!
- Days Between Dates?
- Computing without a Computer