Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 3: Verwendung)

Im ersten Teil dieser Artikelserie bin ich zunächst auf die Grundlagen von Verschlüsselung und Authentifizierung via Transport Layer Security (TLS) eingegangen, bevor im zweiten Teil Certificate Signing Requests (CSR) erstellt und durch die eigene Certificate Authority (CA) in Zertifikate überführt wurden.

Im diesem, letzten Teil geht es um die Installation des Stammzertifikats der CA in diversen Clients, sowie die Verwendung der Server-Zertifikate unter Apache HTTPd, lighttpd und nginx.

Verwendung der Zertifikate

Die Absicherung eines Dienstes bedingt im Allgemeinen die Bereitstellung des Server- bzw. Dienst-Zertifikates, des zugehörigen privaten Schlüssels und des CA-Stammzertifikats. Kommt keine eigene CA zum Einsatz, sondern wurden die Dienste eines kommerziellen Anbieters genutzt, so müssen bei Bedarf deren Zertifikate bereitgestellt werden, sofern sie nicht Teil der Standard-Installation moderner Browser sind.

Ziel ist in jedem Fall, daß ein Client (der Browser) die Kette vom Server-Zertifikat bis zu einem vertrauenswürdigen Zertifikat einer Certificate Authority schliessen kann.

Installation eines Server-Zertifikats

In zweiten Teil wurden für einen fiktiven Beispiel-Server example.dahlen.org die folgenden Dateien erzeugt, welche jetzt zum Einsatz kommen:

  • ca.crt: das Stammzertifikat der eigenen CA
  • server.crt: das Zertifikat des Servers
  • server.key: der private Schlüssel zum Zertifikat des Servers

Die tatsächliche Einbindung ist spezifisch für die jeweilige Server-Software. Dabei können einige Dienste (z.B. Apache HTTPd) die Dateien einzeln ansprechen, während andere (z.B. nginx) zusammengefasste Dateien (bundle) erwarten. Dabei ist teilweise sogar die Reihenfolge der Zertifikate im bundle von Bedeutung.

Ein Hinweis an dieser Stelle: Die beschriebenen Konfigurationen beschränken sich auf das Einbinden der Dateien, so daß die jeweilige Server-Software startet und verschlüsselte Kommunikation erlaubt. Für die optimale Absicherung sind weitere Aktionen notwendig, wie das Aktivieren empfohlener und das De-Aktivieren veralteter Protokolle.

Eine gute Anlaufstelle hierfür ist – neben der Dokumentation zur Software – die Webseite bettercrypto.org bzw. die dort angebotene Dokumentation Applied Crypto Hardening.

Apache

Der Apache HTTP Server kann obige Dateien getrennt ansprechen. Ihre Pfade werden in der Konfiguration des virtuellen Hosts eingetragen, der später über https ansprechbar sein soll. Vorher müssen die Dateien noch an die passende Stelle kopiert werden, z.B. /etc/apache2:


<VirtualHost *:443>
 ServerName example.dahlen.org
 DocumentRoot /var/www/html/
 SSLEngine on
 SSLCertificateFile /etc/apache2/server.crt
 SSLCertificateKeyFile /etc/apache2/server.key
 SSLCACertificateFile /etc/apache2/ca.crt
</VirtualHost>

Eine tiefergehende Einführung mit allen Optionen findet sich in der Dokumentation zum Apache HTTP Server. Nochmal der Hinweis: Der Common Name (CN) im Zertifikat muß der Domäne entsprechen, unter welcher die Website angeboten wird.

nginx

nginx benötigt das Server-Zertifikat und das Stammzertifikat der CA in einer Datei. Diese wird zunächst als bundle.crt angelegt:

cat server.crt ca.crt > bundle.crt

Anschließend werden das bundle und der private Schlüssel des Server-Zertifikats in der Konfiguration von nginx (z.B. als virtueller Host) angesprochen:

server {
 listen 443;
 server_name example.dahlen.org;
 ssl on;
 ssl_certificate bundle.crt;
 ssl_certificate_key server.key;
}

Weitere Details, inbesondere zu den Einstellungen unterstützer Protokolle finden sich in der Dokumentation von nginx.

lighttpd

Eine Anleitung für lighttpd habe ich bereits im 1. Teil des oben erwähnten Posts gegeben. Achtung: Für die Beispiele dort wurden ein anderer Hostname (owncloud.dahlen.org) und andere Dateien (in der Regel mit Dateiendung .pem statt .crt) verwendet.

Installation des CA-Zertifikats

Damit auch der Browser die neu geschaffene Certificate Authority bzw. die von ihr beglaubigten Zertifikate als vertrauenswürdig akzeptiert, ist noch die Installation des CA-Zertifikats im jeweiligen Zertifikat-Speicher notwendig. Dieser Schritt entfällt, wenn auf die Zertifizierung durch eine akkreditierte CA zurückgegriffen wurde.

Windows 7 & 8

Unter Windows 7 und 8(.1) reicht ein Doppelklick auf das CA-Zertifikat ca.crt. Im anschließenden Dialog wählt man Zertifikat installieren, um den entsprechenden Assistenten zu starten.

Zertifikat-Installation Windows

Zertifikat-Installation Windows

Wichtig ist der 2. Schritt des Assistenten, im welchem der Zertifikat-Speicher ausgewählt wird. Statt der Vorgabe der automatischen Auswahl ist der Speicher selbst auszuwählen. Er wird bei einem deutschen Windows als Vertrauenswürdige Stamm­zertifizierungs­stellen genannt (siehe Screenshot).

Mozilla Firefox / Thunderbird

Beide Programme verwalten ihre Zertifikate selbst. Die Installation des ca.crt geschieht über den Menüpfad Einstellungen > Erweitert > Zertifikate. Dort ist Zertifikate anzeigen auszuwählen und im daraus resultierenden Fenster der Reiter Zertifizierungsstellen. Der Button Importieren … schließlich öffnet einen Dialog, in welchem ca.crt ausgewählt werden kann.

Zertifikat Installation Firefox / Thunderbird

Zertifikat Installation Firefox / Thunderbird

iPhone / iOS

Die Installation auf einem iOS-Gerät (hier getestet iPhone 5 mit iOS 8.1.3) ist erstaunlich unkompliziert. Einfach die Datei ca.crt als E-Mail-Anhang versenden, auf dem Mobiltelefon auswählen und installieren.

Android

Android ist der Grund, warum ich noch auf die Dienste von Anbietern wie StartSSL zurückgreifen muß. Offenbar ist es auf einem Android-Gerät ohne root-Zugang (hier: Nexus 7 2012, Stock Android 5.0.2) nicht möglich ein CA-Zertifikat systemweit zu installieren.

Insofern liefern die Browser, aber auch diverse Apps, welche auf meine Server-Dienste zugreifen eine entsprechende Warnung. Schlimmer noch: Unmittelbar nach der (unwirksamen) Installation als Benutzer-Zertifikat erscheint in der Mitteilungszentrale Das Netzwerk wird möglicherweise überwacht.

Wer für dieses Problem eine Lösung anbieten kann, dem sei die Kommentarfunktion unterhalb dieses Artikels empfohlen.

Fazit

Am Ende dieser Artikelserie ergibt sich für mich ein zwiespältiges Bild: Die Einrichtung verschlüsselter Verbindungen für eigene Dienste ist in wenigen Minuten durchführbar. Eine eigene Certificate Authority reduziert Aufwand und Kosten und steht technisch gesehen einer externen, oftmals kommerziellen CA in nichts nach.

Dennoch hat der Einsatz nur in kontrollierten Umgebungen Sinn. Das Problem liegt weniger auf der Server-Seite, sondern an der Notwendigkeit die eigene CA allen Clients bekannt zu machen. Unbedarfte Besucher dürften bei einer oftmals plakativen Warnung des Browsers (Dieser Verbindung wird nicht vertraut) entweder kehrt machen oder die Warnung ignorieren. Beides ist sicherlich nicht im Sinne des Erfinders.

Am Einsatz einer kommerziellen CA führt aktuell daher kaum ein Weg vorbei. Die wenigen kostenlosen oder günstigen Angebote (lt; 200 EUR) bestätigen dabei nicht mehr als die Verwendung einer gültigen E-Mail-Adresse und einen korrekten DNS-Eintrag. Sie sind allerdings für Privatpersonen oder kleinere Unternehmen ausreichend. Mit der Let’s Encrypt-Initiative der Internet Security Research Group (Mozilla und andere) soll Mitte 2015 eine interessante Alternative zu etablierten CAs den Markt betreteten.

Organisationen, welche auf hohe Glaubwürdigkeit angewiesen sind (z.B. beim Online-Banking) haben hingegen keine Wahl. Für EV-Zertifkate mit grüner Namenserwähnung in der Browser-Zeile sind üblicherweise über 1.000 EUR zu bezahlen – pro Jahr.

  1. Benedikt sagt:

    Im Freie-Software-Android-Repository F-Droid (f-droid.org, man kann da ein APK installieren und muss noch unbekannte Quellen[1] aktivieren) gibt es zwei Apps, mit denen man das TLS-Zertfikate-Problem lösen kann:

    * Zum einen CAdroid (https://f-droid.org/repository/browse/?fdfilter=cadroid&fdid=at.bitfire.cadroid), damit kann man das Zertifikat anhand einer URL installieren, anschließend hat man aber die Warnung, dass das Gerät angeblich möglicherweise überwacht wird.
    * Um dies zu beheben, braucht man die App Move Certs (https://f-droid.org/repository/browse/?fdfilter=move+certs&fdid=com.nutomic.zertman), mithilfe derer man mit Rootrechten ein Zertifikat in den Systemspeicher verschieben kann, so dass die Warnung verschwindet.

    [1] Im Allgemeinen sollte man von unbekannten Quellen ja eher abraten, aber F-Droid ist für mich da eindeutig eine Ausnahme – zum einen weil ausschließlich Freie und Open Source Software angeboten wird und zum anderen, weil auch noch vor möglichen Antifeatures der Apps hingewiesen wird, weil z. B. beim normalen Firefox noch restliche Binärblobs enthalten sind oder bei „Tinfoil for Facebook“ auf unfreie Netzwerkdienste zurückgegriffen wird.

  2. Zahlauer sagt:

    Super anleitung Danke! Eine frage hätte ich trotz allem, da ich im Netz nichts dazu finden kann bezüglich Let’s Encryp Zertifikat heist es csr teil nicht bereitgestellt. Bekomme ich diesen teil und wie binde ich csr korrekt ein? Wäre super wenn Du darauf noch eine gute Antwort hättest
    Gruß und Dank
    Udo Zahlauer

  3. Christoph sagt:

    Hi Udo,

    mit letsencrypt hab‘ ich mich bisher nicht intensiv beschäftigt, aber wg. des schwächelnden Vertrauens in meine aktuellen Zertifikate von WoSign wird das wohl bald notwendig. Der Prozess der Zertifikatserstellung durch letsencrypt ist tool-basiert, erlaubt aber offenbar auch die Verwendung eines eigenen Key-Files und CSR. Besonders ausführlich ist die F.A.Q. aber nicht.

    Tut mir leid, mehr kann ich aktuell nicht sagen.

    Gruss

    Christoph

Kommentar hinterlassen