You want to set up a secure Syslog-ng server, and you know you need stunnel and OpenSSL to do this. Creating and managing OpenSSL certificates makes you break out in a rash—it's confusing, and it always takes you too long. Isn't there some kind soul who will show you the way? You're running Debian, or one of its descendants, or pretty much any Linux except Fedora or Red Hat.
Just follow along, and you'll be fine. What we're going to do is create an OpenSSL Certification Authority, and server and client encryption keys to use with stunnel. stunnel provides the transport for our Syslog-ng traffic, and OpenSSL does the encryption and authentication.
You should have OpenSSL already installed; if not, you know what to do.
We'll take this slowly because managing SSL certificates is confusing, and stunnel complicates matters by requiring a special keyfile format.
Although stunnel is going to use these certificates, I'm naming them "syslog-ng*" because they're for authenticating Syslog-ng traffic. We will create the Certificate Authority (CA) and public-/private-key pairs in the /etc/syslog-ng/ directory on the server. After they are created, I'll store them in /etc/syslog-ng/keys on the server and the clients. Wherever you want to keep your stuff, first make sure that the directories exist.
Now, find your CA.sh script, which is part of OpenSSL, and edit these two lines:
DAYS="-days 3650" # 10 years CATOP=./syslog-ng-CA
The default lifetime of your new Certificate Authority (CA) is
one year, so adjust this to suit. CATOP is the top-level directory of your new
CA.
Now, edit openssl.cnf so that the top-level directory for the CA and number of default days agree with CA.sh:
[ CA_default ] dir = ./syslog-ng-CA # Where everything is kept [...] default_days = 3650 # how long to certify for
And, edit your personal information:
countryName_default = US stateOrProvinceName_default = OR 0.organizationName_default = Alrac's Fine Hooves
Make sure these lines are commented out:
[ req_attributes ] #challengePassword = A challenge password #challengePassword_min = 4 #challengePassword_max = 20 #unstructuredName = An optional company name
Now, let's change to the SSL certificate-creation directory:
# cd /etc/syslog-ngCreate the new CA:
# /usr/lib/ssl/misc/CA.sh -newca
CA certificate filename (or enter to create)Hit Enter:
Making CA certificate ... Generating a 1024 bit RSA private key ..++++++ .............................++++++ writing new private key to './syslog-ng-CA/private/./cakey.pem'
Create a good strong passphrase, and don't lose it—you need it every time you create a new key pair:
Enter PEM pass phrase: Verifying - 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) [US]: State or Province Name (full name) [OR]: Locality Name (eg, city) []:Portland Organization Name (eg, company) [Alracs Fine Hooves]: Organizational Unit Name (eg, section) []:HoofRanch Common Name (eg, YOUR name) []:syslog-ng Email Address []:alrac@hoofranch.net
You need the passphrase you just created:
Enter pass phrase for ./syslog-ng-CA/private/./cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 0 (0x0) Validity Not Before: Jul 16 19:05:29 2007 GMT Not After : Jul 15 19:05:29 2010 GMT Subject: countryName = US stateOrProvinceName = OR organizationName = Alrac's Fine Hooves organizationalUnitName = HoofRanch
Use the fully qualified domain name of your server for the common name, or clients will emit complaints:
commonName = xena.alrac.net emailAddress = alrac@hoofranch.net X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 27:F4:BE:F9:92:8A:2B:84:8F:C7:C8:88:B9:4E:8A:A7:D9:3F:FE:93 X509v3 Authority Key Identifier: keyid:27:F4:BE:F9:92:8A:2B:84:8F:C7:C8:88:B9:4E:8A:A7:D9:3F:FE:93 Certificate is to be certified until Jul 15 19:05:29 2010 GMT (1095 days) Write out database with 1 new entries Data Base Updated
You should see /etc/syslog-ng/syslog-ng-CA populated with a number of files and sub-directories.
Now, we will create the server and client key pairs. In this example, the server is Xena and the client is Uberpc. First, we create the signing requests:
# openssl req -new -nodes -out syslogserver-xena_req.pem -keyout \
syslogserver-xena.pem
# openssl req -new -nodes -out uberpc_req.pem -keyout uberpc.pemThe next step is to sign the requests and create the new key pairs. First, the server:
# openssl ca -out syslogserver-xena_cert.pem -infiles \
syslogserver-xena_req.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./syslog-ng-CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Jul 16 19:27:01 2007 GMT
Not After : Jul 13 19:27:01 2017 GMT
Subject:
countryName = US
stateOrProvinceName = OR
organizationName = Alrac's Fine Hooves
organizationalUnitName = HoofRanch
commonName = xena.alrac.net
emailAddress = alrac@hoofranch.net
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
96:DE:84:A1:55:46:78:55:54:B1:4F:B7:E3:CE:EB:26:5A:90:7F:EA
X509v3 Authority Key Identifier:
keyid:27:F4:BE:F9:92:8A:2B:84:8F:C7:C8:88:B9:4E:8A:A7:D9:3F:FE:93
Certificate is to be certified until Jul 13 19:27:01 2017 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base UpdatedAnd then Uberpc:
# openssl ca -out uberpc_cert.pem -infiles uberpc_req.pemOK, we're almost there. You should now have these files:
syslogserver-xena_cert.pem syslogserver-xena_req.pem syslogserver-xena.pem uberpc_cert.pem uberpc_req.pem uberpc.pem
You can delete the req.pem files because
they're not needed anymore. uberpc.pem and
syslogserver-xena.pem are the private keys. Never
ever share these. They are plaintext files, so you can open them and
confirm that they say -----BEGIN RSA
PRIVATEKEY-----.
Open uberpc_cert.pem and copy the public certificate, which is the bit between:
-----BEGIN CERTIFICATE---- -----END CERTIFICATE----
into a new file. You need to do this for every client—copy all of their public certificates into a single file on the Syslog-ng server, which in this recipe I call /etc/syslog-ng/ clientkeys.
Now, copy Uberpc's public certificate into uberpc.pem, like this:
-----BEGIN RSA PRIVATE KEY---- [encoded key] -----END RSA PRIVATE KEY---- [empty line] -----BEGIN CERTIFICATE---- [encoded certificate] -----END CERTIFICATE---- [empty line]
Delete all of the plaintext certificate information. Then, do the same thing to the server's key pair, because stunnel is fussy about the format, and it must be done this way. So now, syslogserver-xena.pem and uberpc.pem contain their own public and private keys, and nothing else.
Now, you can copy Uberpc's keyfile into its permanent home:
# scp uberpc.pem root@uberpc:/etc/syslog-ng/keys/If you have disabled root logins over SSH, I shall leave it to your own ingenuity to figure out how to transfer this file.
And do the same for the server:
root@xena:/etc/syslog-ng# scp syslogserver-xena.pem keys/
Finally, protect the private keys by changing them to mode 0400, or read-only by the owner:
# chmod 0400 uberpc.pem
# chmod 0400 syslogserver-xena.pemFor every new client, follow these steps:
# openssl req -new -nodes -out newclient_req.pem -keyout newclient.pem
# openssl ca -out newclient_cert.pem -infiles newclient_req.pemConcatenate the private and public key into a single file
Copy the keyfile to the new client
Adjust the permissions
Copy the public certificate to the server
Well, that was a bit like work. But now you know how to do it.
Of course, you have the option of not encrypting your Syslog-ng traffic; it will work fine without it. You know that it is trivially easy to sniff traffic on a network with commonly available tools, and any network with wireless access points is extravulnerable, so leaving it in the clear is risky.
I like to use the CA.sh script to create the Certificate Authority because it takes care of the gnarly job of creating all the necessary files. You can use it to create several different types of certificates, but it's almost as easy to use the openssl command, which has more flexibility. The CA.pl script does the same thing, except it's a Perl script instead of a Bash script.
This is what the options mean in the signing request:
req-new-nodesCreate a new signing request for a private key, with no passphrase.
-outThe out filename, or name of your new signing request. This can be anything you want, as long as you use the .pem extension.
-keyoutThe name of your new private key.
This is what the options mean when you sign the private keys:
ca -outUse your CA to sign a new private key, and give it the name of your choice.
-infilesUse this signing request, which must be an existing file.
There is often confusion over keys and certificates. A certificate binds a public key with a distinguished name. Certificates are signed with the issuer's private key, and each one is given a serial number. You can see all this in the example in this recipe, and in your own certificates. All kinds of encryptions and hashes are used to verify that a particular public key did indeed come from a particular CA.
If you trust the issuer, then presumably, you can trust all keys created from the same CA. Private CAs are perfect for jobs like this—we know who we are, so we don't need a third-party CA to vouch for us.