Schlagwort-Archive: OpenSSL

Zertifikatsanfrage (CSR) mit OpenSSL erstellen

Dieses Tutorial beschreibt, wie eine Zertifikatsanfrage (engl. Certificate Signing Request, kurz CSR) erstellt werden kann. Dabei wird die Erstellung von Anfragen für Zertifikate mit einem und mehreren enthaltenen Hostnamen behandelt. Die nach diesem Tutorial erstellten Zertifikatsanfragen können dann genutzt werden, um sie an eine Zertifizierungsstelle (engl. Certificate Authority, kurz CA) zu übermitteln.

Voraussetzung, um diesem Tutorial zu folgen, ist eine funktionsfähige Installation von OpenSSL. Die Installation von OpenSSL ist nicht Gegenstand dieses Tutorials.

Die folgende Tabelle gibt Auskunft über die Konfigurationen, mit denen dieses Tutorial getestet wurde.

BetriebssystemOpenSSL Version
Ubuntu 16.04 LTSOpenSSL 1.0.2g
CentOS/RHEL 7OpenSSL 1.0.2k-fips
Fedora 26OpenSSL 1.1.0f-fips

Keyfile und CSR in einem Schritt erstellen

Die Dateien für den privaten Schlüssel und den CSR können auf der Kommandozeile mit dem folgenden Befehl erstellt werden. Dabei werden die benötigten Informationen interaktiv abgefragt.

/tmp$ openssl req -newkey rsa:2048 -sha256 -keyout test.key -out test.csr
Generating a 2048 bit RSA private key
..............................................................................................+++
........................................................................................................................+++
writing new private key to 'test.key'
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) [AU]:DE
State or Province Name (full name) [Some-State]:NRW
Locality Name (eg, city) []:.        
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:test.example.com
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:.
An optional company name []:.

Die einzelnen Argumente des Befehls sind wie folgt zu erklären:

openssl req ruft das Kommando zur Generierung eines PKCS#10 CSR auf [1]. Das Argument -newkey rsa:2048 gibt an, dass ein neuer RSA-Key mit einer Schlüssellänge von 2048 Bit generiert werden soll. Dieser Schlüssel wird anschließend verwendet, um den CSR zu erzeugen. Mit dem Argument -sha256 wird angegeben, dass das beantragte Zertifikat mit dem SHA256-Algorhytmus signiert werden soll. Man beachte, dass dies von der Zertifizierungsstelle überschrieben werden kann. Mit -keyout test.key wird der Dateiname angegeben, unter dem die Private-Key-Datei (test.key) im aktuellen Verzeichnis gespeichert werden soll. Dementsprechend gibt -out test.csr an, wo die CSR-Datei (test.csr) gespeichert werden soll. Im oben dargestellten Beispiel geschieht dies ebenfalls im aktuellen Verzeichnis.

Das Kommando erzeugt den privaten Schlüssel und fragt interaktiv nach einer Passphrase, mit welcher die Private-Key-Datei verschlüsselt wird. Anschließend werden die Informationen abgefragt, welche in den CSR aufgenommen werden sollen. Mit einem „.“ gibt man an, dass der Standardwert aus den eckigen Klammern in den CSR übernommen werden soll. Auf die Angabe einer E-Mail-Adresse und eines Challenge-Passworts kann guten Gewissens verzichtet werden, da diese Angaben von den meisten Zertifizierungsstellen ignoriert werden.

CSR für mehrere Hostnamen erstellen

Um einen CSR für mehrere Hostnamen zu erstellen, bedient man sich am einfachsten einer Konfigurationsdatei. Die im Folgenden verwendete Konfigurationsdatei kann unter [2] heruntergeladen und unter einem beliebigen Namen (z.B. csr_config.cnf) gespeichert werden. Ausführliche Informationen zum Aufbau der Konfigurationsdatei finden sich in Kapitel 3.3 des unter [2] verlinkten TLS-Kochbuchs. Beachten Sie, dass hinter dem Parameter subjectAltName neben den weiteren Host-/Domain-Namen auch der commonName mit aufgeführt werden muss.

[ req ]
default_bits = 2048
default_keyfile = test_privatekey.pem
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:test.example.com, DNS:*.test.example.com

[ req_distinguished_name ]
countryName = DE
stateOrProvinceName = Nordrhein-Westfalen
localityName = MeinOrt
0.organizationName = MeineFirma
organizationalUnitName = MeineAbteilung
commonName = test.example.com

Die obige Konfigurationsdatei kann nun genutzt werden, um einen CSR für den Hostnamen test.example.com und alle möglichen Hostnamen unterhalb der Domain .test.example.com zu erstellen:

/tmp$ openssl req -batch -sha256 -new -config csr_config.cnf -out test2.csr

Mit der Option -batch wird der interaktive Modus deaktiviert. Die Option -new gibt an, dass ein neuer CSR generiert werden soll. Dabei wird ein Private-Key nach den Vorgaben in der Konfigurationsdatei, welche mit -config csr_config.cnf angegeben wird, erzeugt.

Abschließende Bemerkungen

Die beiden gezeigten Methoden zur Erzeugung einer Zertifikatsanfrage stellen nur einen kleinen Ausschnitt aus dem großen Werkzeugkasten namens OpenSSL dar. Doch sind sie dazu geeignet, in einfacher Weise einen CSR zu erstellen, den man zur Signatur an eine CA seines Vertrauens senden kann.

  1. PKCS #10: Certification Request Syntax Specification
  2. TLS/SSL-Kochbuch – Rezepte für die Verwendung von OpenSSL

ejabberd mit Let’s Encrypt Zertifikat

In diesem Artikel wird dokumentiert, wie ein Let’s Encrypt1 2 Zertifikat für ejabberd eingerichtet werden kann. Dabei stütze ich mich auf mein TLS-Kochbuch3.

Die Dokumentation bezieht sich dabei auf meine konkrete Installation und ist nicht ohne Transferleistung auf andere Installationen übertragbar. Es ist also keine Schritt-für-Schritt-Anleitung! Der Artikel bietet über die Dokumentation hinaus jedoch auch Hintergrundinformationen und Wissenswertes für abweichende Konfigurationen.

Ausgangssituation

In meiner Umgebung ist ejabberd auf einem Ubuntu Server 14.04 LTS4 installiert und nutzt ein TLS-Zertifikat von CAcert5 6.

Außer ejabberd läuft auf dem Server auch noch ein Webserver, welcher verschiedene Webseiten ausliefert.

Daneben ist bereits der Let’s Encrypt Client acme-tiny7 installiert, dessen Verwendung in Abschnitt 3.6.2 TLS-Kochbuch erläutert wird.

Der Ablauf im Überblick

Wie vorstehend bereits erwähnt, verwendet ejabberd bereits ein TLS-Zertifikat, welches nun durch ein Let’s Encrypt Zertifikat ersetzt werden soll. Der Ablauf gliedert sich dabei im Wesentlichen in zwei Teile. Zuerst wird ein Let’s Encrypt Zertifikat für den Hostnamen des ejabberd-Servers ausgestellt. Anschließend wird ejabberd konfiguriert, um zukünftig dieses Zertifikat zu nutzen.

Zur Durchführung der Domainvalidierung wird ein VirtualHost für den Hostnamen des ejabberd-Servers konfiguriert. Da sich die genaue Konfiguration je nach verwendeter Webserver-Software unterscheidet, wird hier nicht näher darauf eingegangen, sondern auf die Dokumentation des jeweiligen Webservers verwiesen.

Generierung des TLS-Zertifikats

Nun wird mit Hilfe von OpenSSL8 9 ein privater Schlüssel und eine Zertifikatsanfrage (engl. Certificate Signing Request (CSR)) erstellt. Beide Schritte werden ausführlich in Abschnitt 3.1 TLS-Kochbuch beschrieben.

Ich persönlich generiere den privaten Schlüssel und den CSR stets offline auf einem sicheren Computer. Anschließend lade ich sie zum Server hoch. Die Zugriffsrechte auf den Schlüssel sind so eingeschränkt, dass nur root und der Benutzer, unter dem der Webserver ausgeführt wird, diesen Schlüssel lesen dürfen.

Da bereits eine Installation von acme-tiny auf dem Server existiert und bereits ein Account-Key erstellt wurde, wird dieser in dem Verzeichnis verlinkt, in dem auch der private Schlüssel und der CSR liegen.

Nun kann das TLS-Zertifikat angefordert werden. Wie dies im Detail funktioniert, wird in Abschnitt 3.6.2 im TLS-Kochbuch beschrieben.

Sind bis hier alle Schritte erfolgreich gewesen, liegen nun Schlüssel und Zertifikat in einem Verzeichnis vor.

$ python acme-tiny/acme_tiny.py --account-key /var/www/sites/ssl/account.key --csr /var/www/sites/ssl/request.csr --acme-dir /var/www/sites/public/.well-known/acme-challenge/ > /var/www/sites/ssl/cert.crt
Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying fqdn...
fqdn verified!
Signing certificate...
Certificate signed!

$ ls -l /var/www/sites/ssl/
-rw-r—– 4 root root account.key
-rw-r—– 1 root www-data cert.crt
-rw-r—– 1 root root priv.key
-rw-r—– 1 root root request.csr

Zertifikat für ejabberd präparieren

Der Dienst ejabberd erwartet, dass der private Schlüssel, das Zertifikat und die Zertifikatskette in einer Datei übergeben werden.10 Dazu wird noch die Zertifikatskette von Let’s Encrpyt11 heruntergeladen und ebenfalls in /var/www/sites/ssl/ gespeichert.

Das folgende Skript zeigt, wie das Zertifikat erzeugt, die Zertifikatsdatei für ejabberd zusammengesetzt und der Dienst neugestartet wird:

#!/bin/bash
# Datum: 2016-11-13
# Autor: Joerg Kastning <webmaster(aet)my-it-brain(Punkt)de>
#
# Beschreibung:
# Dieses Skript dient der Erneuerung des TLS-Zertifikats fuer
# jabber.my-it-brain.de über Let's Encrypt mit dem Client acme-tiny-by-frezbo.

DIR='/var/www/sites/ssl'

# Erneuerung des Zertifikats
python acme-tiny-by-frezbo/acme_tiny.py --account-key ${DIR}/account.key --csr ${DIR}/request.csr --acme-dir /var/www/sites/fqdn/.well-known/acme-challenge/ > ${DIR}/cert.crt

# Erzeugung der Zertifikatsdatei fuer ejabberd
cat ${DIR}/priv.key ${DIR}/cert.crt ${DIR}/lets-encrypt-x3-cross-signed.pem >${DIR}/ejabberd_cert.pem

sudo chown root:ejabberd ${DIR}/ejabberd_cert.pem
sudo chmod 0640 ${DIR}/ejabberd_cert.pem
sudo mv ${DIR}/ejabberd_cert.pem /etc/ejabberd/ejabberd_cert.pem

# Neustart von ejabberd
sudo service ejabberd restart

Abschluss der Migration

Durch den im vorangegangenen Abschnitt dargestellten Code wird das neue Let’s Encrypt Zertifikat an der gleichen Stelle und unter dem gleichen Dateinamen wie das alte Zertifikat abgelegt. Auf diese Weise muss die Konfiguration von ejabberd nicht weiter angepasst werden. Der Dienst lädt nach einem Neustart das neue Zertifikat. Die Migration ist damit abgeschlossen.

Let’s Encrypt Zertifikate besitzen eine Gültigkeit von 90 Tagen.12 Um die Erneuerung des Zertifikats zu automatisieren, wird das Skript „SmartRenew.sh“ verwendet (siehe Abschnitt 5.4 im TLS-Kochbuch).

Quellen und weiterführende Links:

Kurz vorgestellt: Mozilla SSL Configuration Generator

In diesem Artikel möchte ich euch kurz den Mozilla SSL Configuration Generator vorstellen, auf den mich ein Kollege aufmerksam machte.

mozilla_ssl_configuration_generator

Mozilla SSL Configuration Generator

Es handelt sich dabei um eine Seite, die dabei hilft, valide Konfigurationen für verschiedene Webserver wie Apache, NGINX, Lighttpd, HAProxy oder AWS ELB zu erstellen. Man gibt dazu den verwendeten Webserver, dessen Version und die OpenSSL Version an. Die Seite erstellt daraufhin die Konfiguration, welche per Copy&Paste übernommen werden kann. Lediglich die enthaltenen Pfadinformationen sind an die eigenen Bedürfnisse anzupassen.

mozilla_ssl_configuration_generator_nginx

Konfiguration für nginx 1.4.6 | modern profile | OpenSSL 1.0.1e

Neben der Konfiguration erhält man auch noch die Information dazu geliefert, welche Browser mit der erstellten Version kompatibel sind.

In einer ersten Stichprobe scheint die Seite ganz brauchbare Ergebnisse zu liefern. Ich freue mich über eure Meinungen und Erfahrungen zu diesem Dienst.

Bei positiver Resonanz nehme ich einen Hinweis auf diesen Dienst in eine kommende Version meines TLS-Kochbuchs auf.

Mein TLS/SSL-Kochbuch

Heutzutage werden immer mehr Kommunikationsverbindungen im Internet mit TLS/SSL-Verbindungen geschützt. Die Verschlüsselung hilft, die Vertraulichkeit der zwischen Sender und Empfänger übertragenen Daten zu schützen und sollte daher standardmäßig aktiviert sein. Doch bereitet der Einsatz von TLS/SSL-Verschlüsselung noch immer vielen Administratoren und Betreibern verschiedenster Anwendungen Kopfschmerzen. Zu undurchsichtig scheint der Dschungel aus Zertifizierungsstellen, Zertifikaten, Zertifikatsanfragen, öffentlichen und privaten Schlüsseln zu sein. Verschiedenste Validierungsverfahren und Dateiformate für Zertifikate tragen nicht gerade dazu bei, den Durchblick zu behalten. Bereits die Erstellung einer Zertifikatsanfrage gerät dabei häufig genug zu einem Problem. Die richtige Konfiguration der zu sichernden Server bzw. Dienste erscheint kompliziert und Fehler in der Konfiguration führen nicht selten zur Nichterreichbarkeit einer Webseite. Die Folge: Immer noch wird viel zu häufig auf den Einsatz von TLS/SSL-Verschlüsselung verzichtet.

Mit meinem TLS-Kochbuch möchte ich dazu beitragen, etwas Licht ins Dunkel zu bringen. Darin finden sich Rezepte mit praktischen Tipps für die Verwendung von TLS/SSL-Verschlüsselung mittels OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP).

Aus dem Inhalt

Nach der Einleitung führt Kapitel 2 in das Thema ein und definiert die wesentlichen Begriffe. Es bildet die Grundlage für das Verständnis der daran anschießenden Kapitel.

In Kapitel 3 geht es um die Implementierung von TLS/SSL. Hier werden verschiedene Methoden zur Generierung von privaten Schlüsseln und Certificate Signing Requests vorgestellt. Darüber hinaus werden einige Zertifizierungsstellen kurz vorgestellt, bei denen Zertifikate beantragt werden können. Im Folgenden wird auf die Implementierung von TLS/SSL-Zertifikaten in verschiedenen Diensten eingegangen. Hier wird insbesondere die Implementierung von Zertifikaten der recht jungen Zertifizierungsstelle „Let’s Encrypt“ erläutert, mit deren Hilfe sich der Prozess der Zertifikatserneuerung automatisieren lässt.

Der Implementierung des HTTP Public Key Pinning (HPKP) widmet sich Kapitel 4. Das Pinning-Verfahren wird am Beispiel des Webservers NGINX erläutert und getestet.

Zum Schluss werden die in den einzelnen Kapiteln vorgestellten Techniken und Methoden nochmals zusammenfassend an einem konkreten Beispiel in Kapitel 5 verdeutlicht.

Hier geht es zum Text

Mir persönlich hat die Arbeit an folgendem Dokument geholfen, mich detailliert mit der Thematik auseinanderzusetzen und mein Wissen zu erweitern und zu vertiefen. Ich freue mich, wenn mein Kochbuch auch euch dabei hilft, ein besseres Verständnis für das Thema zu entwickeln.

Dies ist die erste Ausgabe meines TLS/SSL-Kochbuchs und es gibt sicher noch viel mehr, was man zu diesem Thema schreiben kann. Fehler sowie Wünsche zum Inhalt zukünftiger Ausgaben können gern an die E-Mail-Adresse tls-rezepte(aet)my-it-brain(Punkt)de gemeldet werden.

Downloads zum Text