PKI-loses TLS

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 05 Jan 2008 13:00:19 +0100

Florian hat im April 2007 eine Notiz über PKI-loses TLS unter Verwendung von selbstsignierten Zertifikaten veröffentlicht. Er ist ja immer für provokative Aussagen gut, und in der Notiz erklärt er seine Beweggründe gut und hat bei mir einen Denkprozess ausgelöst.

Ich werd das in den nächsten Monaten mal für den einen oder anderen Dienst, z.B. OpenVPN, ausprobieren und gucken, ob dieser Ansatz in der Praxis funktionieren könnte. Für die Anwendung im Webumfeld sehe ich ja eher schwarz, weil dank der verDAUung des Internets ein https-Server mit selbstsigniertem Zertifikat gemeinhin als unsicherer angesehen wird wie ein Server mit unverschlüsseltem http. Weil bei Ersterem der Browser weint, und bei Zweiterem nicht.

EasyRSA on Debian for an OpenVPN CA

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 06 Mar 2007 13:50:53 +0100

After asking for useable CA Software, I have finally settled on using EasyRSA. This is what I did to come across the packaging shortcomings of EasyRSA in Debian.

Storing your CA

Be sure that your CA is stored in a secure place. Don’t store it online, and make it accessible only to yourself. In my opinion, storing the the CA in a cryptoloop or dm-crypt container file on a small 32 MB USB stick is a good idea. Cryptloop, dm-crypt and LUKS are rather easy today and available in the stock Linux kernel. I commonly use grml-crypt to manage the crypto loopback stuff:

sudo grml-crypt start /media/usb4/cryptoloop $MOUNTPOINT

Gotcha: don’t confuse sudo’s “password” prompt with grml-crypt’s “Enter LUKS passphrase” prompt, the cryptoloop password won’t bring you anywhere on the sudo prompt.

Preparing the CA directory

For the CA, create a dedicated directory in the mounted cryptoloop file system. You’re originally supposed to copy the entire EasyRSA directory tree in there, but I’d recommend to only link the files from your system’s EasyRSA directory to automatically take advantage of distribution updates.

You’ll need at least these links:

lrwxrwxrwx 1 mh mh   56 Dec 25 23:23 openssl.cnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf
lrwxrwxrwx 1 mh mh   52 Dec 25 23:22 pkitool -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool
lrwxrwxrwx 1 mh mh   60 Dec 25 23:23 whichopensslcnf -> /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf

ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool .
ln -s /usr/share/doc/openvpn/examples/easy-rsa/2.0/whichopensslcnf .

Configuring your CA

The only thing you cannot link is the vars file which contains your CA’s local settings:

export EASY_RSA=“$(pwd)”
export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”
export KEY_CONFIG=$($EASY_RSA/whichopensslcnf $EASY_RSA)
export KEY_DIR=“$EASY_RSA/keys”

# Issue rm -rf warning
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR

export KEY_SIZE=1024
export CA_EXPIRE=3650
export KEY_EXPIRE=3650
export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus.de”
export KEY_EMAIL=“mh+easyrsa-mh-openvpn@zugschlus.de”

export PKCS11_MODULE_PATH=“dummy”
export PKCS11_PIN=“dummy”

Comments have been removed from this file. Better copy the file from /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars and edit it to your needs. I added the two PKCS11 variables since you won’t otherwise be able to issue certificate requests.

Creating the CA

Next, decide on a shell instance where you will do most operations, and source vars in there.

Next, run /usr/share/doc/openvpn/examples/easy-rsa/2.0/clean-all. If you do this in a directory of an already-in-use EasyRSA CA, you’ll need to restore your backup.

To actually initialize the CA, run pkitool --initca --pass. If you do not give the --pass parameter, you’ll create a CA that can issue certificates without asking for a passphrase, which might not be a brilliant idea. Choose a reasonably secure pass phrase.

Creating Certificates - the simple and suboptimal way

You can now simply proceed to create an arbitrary number of pairs of “private” keys and associated certificate by simply calling pkitool <clientname> and/or pkitool --server <servername>. Depending on your security policy, you can mandate the private keys to be protected by a passphrase (adding --pass to the command lines), but you’ll have the expense of being asked for the passphrase every time you start a new openvpn daemon.

Creating Certificates the Right Way

I have put the “private” in quotes since the keys created this way are not really private: The key was created on the box hosting the CA, was stored on the local (crypted) file system and needs to be moved to the target system via a secure channel. Doing so the right way is harder than expected, so it is usually the better way to keep the private key really private by creating it directly on the target system. On the target system, you need OpenVPN installed, and openssl. After the certificate was created, you can remove openssl again.

Creating a private key is part of a key-pair generation process that also leaves a certificate request. The contents of the certificate request is public, and you can safely move it to the CA box and convert it to a certificate by signing the request. You only need to make sure that nobody exchanges your target system’s certificate request for her own before you sign it as you might end up certifying a wrong identity.

For the rest of this document we’re going to assume that you have ssh access to the target system and have verified the ssh host key, so that you can be reasonably sure to be connected to the right system.

To create a certificate request, you can use this script, which I have called create-easyrsa-cert-req:

#!/bin/bash

set -u

TMPDIR=“/tmp”

export OPENSSL=“openssl”
export PKCS11TOOL=“pkcs11-tool”
export GREP=“grep”

export KEY_CONFIG=“/usr/share/doc/openvpn/examples/easy-rsa/2.0/openssl.cnf”

export KEY_DIR=“$TMPDIR/keys.$$”
mkdir -p $KEY_DIR

export KEY_SIZE=1024
export KEY_EXPIRE=3650

export KEY_COUNTRY=“DE”
export KEY_PROVINCE=“”
export KEY_CITY=“”
export KEY_ORG=“Zugschlus”
export KEY_OU=“$(hostname --fqdn)”
export KEY_EMAIL=“mh+$(hostname)-ovpn-cert@zugschlus.de”

export DEBUG=1
umask 077
if [ “${1:-foo}” != “server” ]; then
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr $(hostname)
else
  /usr/share/doc/openvpn/examples/easy-rsa/2.0/pkitool --csr --server $(hostname)
fi

mv $TMPDIR/keys.$$/* .
rm -rf $TMPDIR/keys.$$

When called without parameters, it creates a certificate request for an OpenVPN client certificate, and when you call it with “server” as parameter, it will create a server certificate request.

In any case, it will leave two files in the current directory. They are named after the current host name, and have the extensions .csr and .key. The .key file is your private key. keep it private! The .csr file is the certificate request which you can now move to the keys subdirectory of your CA directory via scp or other means such as an USB stick.

To do the actual signing, invoke pkitool --sign <hostname> and enter the CA passphrase. You can ignore the error message that there was no .key file to chmod. Gotcha, when signing a server certificate, use pkitool --server --sign <hostname>.

Move Certificate to the target host

You can now move the certificate to the target system. Since you’re probably going to need the root certificate and the certificate revocation list as well, the .crt file, and ca.crt to the target system. These files are public, so there is no need for a secure channel. If you created the .key file on the CA system (which is not recommended), you need a secure channel to move the .key file to the target system as well.

Revoking Certificates

Since an OpenVPN server’s only means of authentication is to check whether the certificate presented by a client is signed by the “right” CA, the only way to revoke VPN access is to revoke the certificate. This is also done on the CA system by calling /usr/share/doc/openvpn/examples/easy-rsa/2.0/revoke-full <client-name>. This creates a crl.pem file which contains a list of all revoked certificates. You need to have a mechanism to distribute that list to all systems that might need it, and it is recommended to have this automated. Remember, if you do not distribute the .crl file, the systems are not going to know about revoked certificates.

X509 Certification Authority

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 14 Apr 2006 15:44:00 +0200

In diesem Artikel samme ich Links zu Literatur und HOWTOs über den Aufbau lokaler X.509 Certification Authorities.

David Pashley: Becoming a X.509 Certificate Authority. Inklusive einiger interessanter Artikellinks für “further reading” am Ende des Artikels.

Looking for useable CA software

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 03 Mar 2006 23:22:09 +0100

To support my experiments with OpenVPN, I have been trying to evaluate different CA software packages in Debian. With devastating results.

I tried

pyca
tinyca
easy-rsa (from the openvpn package)

pyca

Pros

command line

Cons

Unmaintained upstream
Quite underdocumented - the maintainer doesn’t think so and closed #355177.
Didn’t work when I tried it

tinyca

pros

seems easily useable

cons

has a GUI and is thus not suitable for very old boxes as CA host
version in unstable gets in endless loop after CA certification
version in testing crashes without error message if default values for CA are changed
version in testing succeeds in creating CA and then displays a GUI that doesn’t accept any mouse clicks

easy-rsa

pros

easily useable
Only CA tried that actually worked in creating certificates for first OpenVPN installation

cons

not properly packages - only in examples directory of OpenVPN package
creates CA without password!

openca

not packaged for Debian (see #141748)

openxpki

split from openca in October 2005
Has not yet released any code

conclusion

All software sucks. Does Debian have CA software that is actually useable?

To self-signed or not to self-sign?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 08 Dec 2005 14:52:05 +0100

Auf der Nesus-Mailingliste fand ich heute eine Mail, deren Autor sich darüber wundert, dass
Nessus bei einem Self-Signed Certificate keine Warnung wirft.

Schließlich ist das eine schlechte Security-Maßnahme weil auf diese Weise Man-in-the-Middle-Attacken möglich werden. Das sei insbesondere im kommerziellen Umfeld ein Problem.

Nun, meine Meinung dazu ist, dass es sicherer sein kann, ein selbstsigniertes Zertifikat selbst zu verifizieren als sich blind auf die durchaus durchwachsenen Prozesse einer kommerziellen CA zu verlassen.

Ach ja, die oben zitierte Mail kam von einem Verisign-Mitarbeiter.

Zugschlusbeobachtungen (Entries tagged as pki)

PKI-loses TLS

EasyRSA on Debian for an OpenVPN CA

Storing your CA

Preparing the CA directory

Configuring your CA

Creating the CA

Creating Certificates - the simple and suboptimal way

Creating Certificates the Right Way

Move Certificate to the target host

Revoking Certificates

X509 Certification Authority

Looking for useable CA software

pyca

Pros

Cons

tinyca

pros

cons

easy-rsa

pros

cons

openca

openxpki

conclusion

To self-signed or not to self-sign?