Erstellung selbst-signierter TLS-Zertifikate

Warum?

Wenn man transport-verschlüsselndes HTTPS benutzen möchte, dann benötigt man auf der Server-Seite ein TLS-Zertifikat. Es gibt verschiedene Wege dies zu erreichen, ein verbreiteter und "sauberer" Weg ist Let's Encrypt. Wenn man sich das Protokoll auf der Unterseite How It Works ansieht wird schnell klar: es funktioniert nur, wenn der Server einen FQDN (Fully Qualified Domain Name) besitzt und aus dem Internet erreichbar ist. Für Szenarien mit DynDNS funktioniert das, aber oft möchte man ja gerade nicht, dass die persönlichen Daten aus dem Internet erreichbar sind. Für solche Fälle kann man selbst TLS-Zertifikate erzeugen und diese "inoffiziell" signieren.

Wie?

Das Handwerkszeug dafür ist in quasi jeder Linux-Distribution enthalten und lässt sich leicht installieren:

$ sudo apt install -y openssl

Die Erstellung der Zertifikate erfordert ein paar Entscheidungen. Ein beispielhafter Aufruf:

$ openssl req -x509 -newkey rsa:4096 -nodes -keyout key.pem -out cert.pem -sha256 -days 365

Um zu verstehen, was hier passiert, muss man sich die einzelnen Parameter anschauen (z.B. in der Manpage zu openssl-req):

• Mit req wird das PKCS#10 certificate request and certificate generating utility angeworfen.
• Mit -x509 weist man openssl an, ein selbst-signiertes Zertifikat zu erzeugen (statt einer Zertifikat-Anfrage).
• Mit -newkey wird die Erstellung eines neuen Schlüssels angestoßen (anstatt einen bereits vorhandenen zu verwenden).
• rsa:4096 ist die Spezifikation für den neu zu erstellenden Schlüssel: RSA mit 4096 Bit Länge.
• -nodes hat nichts mit Knoten zu tun, sondern ist als "no DES" zu lesen und besagt, dass der erstellte Schlüssel selbst nicht verschlüsselt werden soll.
• -keyout spezifiziert die Datei, in welcher der Schlüssel gespeichert werden soll.
• -out spezifiziert die Datei, in welcher das Zertifikat gespeichert werden soll.
• Mit -sha256 wird festgelegt, dass das Zertifikat mit SHA-256 signiert werden soll.
• Mit -days 365 wird eine Gültigkeit von einem Jahr konfiguriert.

4096 Bit Schlüssellänge scheint vielleicht mit Kanonen auf Spatzen geschossen zu sein, aber das Bundesamt für Sicherheit in der Informationstechnik (BSI) gibt in seiner Technischen Richtlinie BSI TR-02102-1 von 2022 die Empfehlung, für einen Einsatz über das Jahr 2022 hinaus eine Schlüssellänge von 3000 Bit zu verwenden. Performance-mäßig sollte das auch nicht weiter weh tun, weil bei TLS das Zertifikat ohnehin nur bei der Aushandlung des Sitzungsschlüssels relevant ist; die eigentliche Transportverschlüsselung erfolgt nach einem symmetrischen Verfahren (Firefox 107: ChaCha20-Poly1305; Chromium 107: AES-128-GCM).

Man erhält ein TLS-Zertifikat, das in puncto Transportverschlüsselung einwandfrei funktioniert, den meisten Webbrowsern jedoch zunächst nicht gefallen wird: sie bemängeln, dass das Zertifikat selbst signiert und nicht von einer offiziellen Certificate Authority (CA) beglaubigt wurde. Das ist zwar korrekt, aber uns egal; dies kann man dem Webbrowser üblicherweise auch mitteilen, jedoch funktioniert das bei jedem etwas anders. Hierzu ein paar Links:

• Firefox: How to make "Permanently store this exception" checkbox active?
• Manually importing the client certificate - Windows 10
• How do you get Chrome to accept a self-signed certificate?

Konzeptionell weist ein solches Zertifikat übrigens die Identität eines Hosts aus, also den kompletten (virtuellen) Rechner. Im Kontext dieser Anleitungen ergibt es also durchaus Sinn, ein Zertifikat zu erstellen und dieses für alle Anwendungen auf dem Host zu verwenden.