Mittels einer eigenen X.509-Zertifikatsinfrastruktur sorgen Sie für wasserdichte Informationssicherheit zwischen Ihrem heimischen Server und Ihren Mobilgeräten.

Betreibt man einen eigenen Home-Server, zum Beispiel für E-Mail, Kontakte, Kalender, Web- und Cloud-Dienste, um von unterwegs mit all seinen Mobilgeräten zentral auf die eigenen Daten zugreifen zu können, dann stellt sich schnell die Frage der Informationssicherheit.

Um die zu gewährleisten, sichert man am besten mittels digitaler Zertifikate die typischen Zugangsprotokolle ab, wie HTTP(S), IMAP(S), SMTP(S), alternativ auch direkt die Netzwerkebene (zum Beispiel per OpenVPN) via TLS. Diese Absicherung durch ein Zertifikat basiert einerseits auf dem im Zertifikat enthaltenen öffentlichen Schlüssel zum Chiffrieren des Datentransports und andererseits auf den zusätzlichen Informationen zur Bestätigung der Authentizität des öffentlichen Schlüssels. Weitere Informationen finden Sie im Kasten “Zentrale Zertifikatsinfrastruktur”.

Zertifizierungsstelle

Als Certificate Authority (CA) dient im besten Fall ein von jeglichem Netzwerk getrennter Rechner: Hier erstellen Sie nicht nur die meisten Server-Zertifikate, sondern beglaubigen auch alle Zertifikate durch das Root-Zertifikat. Jede Kompromittierung dieses äußerst sensiblen Bereichs bedeutet den vollständigen Verlust jeglicher Sicherheit.

In der Praxis genügt aber bereits eine Linux-Installation auf einer SD-Karte oder einem USB-Laufwerk mit verschlüsselter Datenpartition. Dann booten Sie einen beliebigen Rechner, etwa ein Notebook oder einen Raspberry Pi, von diesem Datenträger. Diesen Computer verbinden Sie für die Zeit zwischen Hoch- und Herunterfahren niemals mit einem Netzwerk – und schon gar nicht mit dem Internet.

Jeglicher Datenaustausch zwischen dieser Zertifizierungsstelle und beliebigen anderen Geräten – den eigentlichen Servern oder Mobilgeräten – kann dann über einen stets sorgfältig “bereinigten” USB-Stick oder ein ähnliches Medium erfolgen.

Die CA einrichten

Bei Easy-RSA [2] handelt es sich um einen auf OpenSSL aufbauenden, sehr einfach zu bedienenden kommandozeilenbasierten Werkzeugkasten zum Erstellen und Verwalten von X.509- und anderen Zertifikaten [1]. Haben Sie erst einmal die Infrastruktur aufgesetzt, lassen sich Zertifikate schnell erzeugen oder beglaubigen.

Mit den Befehlen aus Listing 1 installieren Sie das Paket und legen das Arbeitsverzeichnis an. Dann bearbeiten Sie die Datei vars wie in Listing 2 gezeigt, um die Zertifizierungsstelle zu konfigurieren. Die kursivierten Angaben ersetzen Sie dabei jeweils um die für Ihre Umgebung gültigen Angaben.

Mit den beiden Kommandos source ./vars und ./clean-all richten Sie dann die Zertifizierungsstelle ein. Später laden Sie vor jeder weiteren Benutzung die Konfiguration mit source ./vars neu.

sudo apt-get install easy-rsa
make-cadir MyCA-Folder
cd MyCA-Folder
ln -s openssl-1.0.0.cnf openssl.cnf

[...]
# Schlüsselgröße min. 2048 Bit, besser 4096 Bit
export KEY_SIZE=4096
[...]
# Gültigkeitsdauer des CA-Zertifikats in Tagen
export CA_EXPIRE=3650
[...]
# Gültigkeitsdauer von Server/Client-Zertifikaten in Tagen
# kürzer als CA-Zertifikat, unbedingt vor Ablauf ersetzen
export KEY_EXPIRE=730
[...]
# Beschreibung der Zertifizierungsstelle (anpassen)
export KEY_COUNTRY="DE"
export KEY_PROVINCE="BY"
export KEY_CITY="Muenchen"
export KEY_ORG="MyServices"
export KEY_EMAIL="it@myservices.org"
export KEY_OU="IT Abteilung"
export KEY_NAME="MyServicesRSA"
[...]

Root-Zertifikat erstellen

Mit ./build-ca MyServicesCA im Verzeichnis MyCA-Folder/ legen Sie im Unterverzeichnis keys/ das Root-Zertifikat inklusive des öffentlichen Schlüssels in der Datei ca.crt und den privaten Schlüssel in ca.key an. Beide Dateien sind Base64-kodiert, sodass Sie sie mit jedem Texteditor einsehen und bearbeiten können. Den Inhalt des Zertifikats machen Sie erst durch einen gesonderten Befehl so richtig lesbar (Listing 3).

$ openssl x509 -in ca.crt -noout -text
Certificate:
  Data:
    Version: 3 (0x2)
    Serial Number: 18229304525504044741 (0xfcfb7fe20916dec5)
  Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=DE, ST=BY, L=Muenchen, O=MyServices, OU=IT Abteilung, CN=MyServicesCA/name=MyServicesRSA/emailAddress=it@myservices.org
    Validity
      Not Before: Sep 15 12:00:01 2018 GMT
      Not After : Sep 12 12:00:01 2028 GMT
    Subject: C=DE, ST=BY, L=Muenchen, O=MyServices, OU=IT Abteilung, CN=MyServicesCA/name=MyServicesRSA/emailAddress=it@myservices.org
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
        Public-Key: (4096 bit)
        Modulus:
          00:ca:a4:91:fe:1e:c1:cc:10:63:9e:b1:75:bf:7c:
[...]
          30:6e:1d
        Exponent: 65537 (0x10001)
    X509v3 extensions:
      X509v3 Subject Key Identifier:
        DD:0A:A7:75:B6:E6:95:7D:11:81:E0:97:A0:19:1B:D3:9B:D9:BD:F4
      X509v3 Authority Key Identifier:
        keyid:DD:0A:A7:75:B6:E6:95:7D:11:81:E0:97:A0:19:1B:D3:9B:D9:BD:F4
        DirName:/C=DE/ST=BY/L=Muenchen/O=MyServices/OU=IT Abteilung/CN=MyServicesCA/name=MyServicesRSA/emailAddress=it@myservices.org
        serial:FC:FB:7F:E2:09:16:DE:C5
      X509v3 Basic Constraints:
        CA:TRUE
  Signature Algorithm: sha256WithRSAEncryption
    70:7f:37:63:39:5c:ca:c9:66:86:1e:b8:b6:38:95:7d:15:49:
[...]
    0e:fd:e3:55:f4:4b:9a:9c

In der Folge müssen Sie (oder andere Anwender) die Integrität des von der Zertifizierungsstelle ausgestellten und von geeigneter Stelle heruntergeladenen Root-Zertifikats per Fingerabdruck überprüfen können, bevor Sie es auf einem Gerät einrichten. Den recht gebräuchlichen SHA1-Fingerabdruck erzeugen Sie mit dem Befehl aus der ersten Zeile von Listing 4. Bei Bedarf können Sie auch andere Fingerabdrucktypen verwenden, etwa mithilfe der Parameter -sha256 oder -md5.

$ openssl x509 -in ca.crt -noout -fingerprint -sha1 > caFingerabdruck.sha1.txt
$ cat caFingerabdruck.sha1.txt
SHA1 Fingerprint=A3:DD:8A:2B:4A:CF:FB:9B:1A:FB:69:7D:06:2C:CB:55:8F:C2:51:8B

Von den erzeugten Dateien dürfen Sie nur das Zertifikat mit dem öffentlichen Schlüssel in ca.crt und dem zugehörigen Fingerabdruck in der Textdatei caFingerabdruck.sha1.txt veröffentlichen. Der geheime Schlüssel in ca.key bleibt dagegen sicher verwahrt in der Zertifizierungsstelle.

Server-Zertifikate

Auch die Server-Zertifikate für die E-Mail-Dienste SMTPS und IMAPS sowie Own/Next-Cloud erzeugen Sie im Verzeichnis MyCA-Folder/. Listing 5 zeigt den Ablauf.

Die Frage nach dem Passwort (Zeile 3) für die Zertifizierungsanfrage können Sie genauso offenlassen wie jene nach dem Firmennamen (Zeile 4). Jeweils mit ja/y(es) beantworten Sie die Fragen, ob das Zertifikat gegengezeichnet (Zeile 5) und der Zertifizierungsstelle übergeben (Zeile 6) werden soll.

Insgesamt entstehen dabei für jeden der oben genannten drei Server im Verzeichnis keys/ jeweils drei Dateien: Die server.key enthält den privaten Schlüssel, die server.csr die eigentliche Zertifizierungsanfrage an die CA. In der Datei server.crt schließlich findet sich das von der CA signierte beziehungsweise beglaubigte Zertifikat.

./build-key-server smtp.myservices.tld
[...]
A challenge password []:
An optional company name []:
Sign the certificate? [y/n]: y
1 out of 1 certificate requests certified, commit? [y/n] y
[...]
./build-key-server imap.myservices.tld
[...]
./build-key-server cloud.myservices.tld
[...]

E-Mail- und Cloud-Dienste

Die erstellten, beglaubigten Schlüssel und Zertifikate übertragen Sie mittels des oben erwähnten “bereinigten” USB-Sticks von der Zertifizierungsstelle auf den oder die Server, wo Sie sie in das Verzeichnis /etc/ssl/ kopieren.

Dabei schieben Sie die geheimen Schlüsseldateien *.key ins Unterverzeichnis private/ und die Zertifikatsdateien *.crt (auch als *.pem) ins Unterverzeichnis certs/. Die Tabelle “Server-Ports” zeigt eine kleine Übersicht der üblichen Secure-Ports.

Beispiel: Dovecot

Der weit verbreitete IMAP-Server Dovecot bietet auf dem entsprechenden Secure-Port seinen Dienst auch verschlüsselt an. Dazu aktivieren Sie in der Konfigurationsdatei /etc/dovecot/conf.d/10-ssl.conf die SSL-Funktion [3] und tragen das Zertifikat mit dem öffentlichen und dem geheimen Schlüssel ein (Listing 6).

Bei dieser Einstellung kann der Client die Authentizität des IMAP-Servers bei der Kontaktaufnahme überprüfen, um sich dann seinerseits über die bereits verschlüsselte Verbindung mit Benutzername und Passwort zu authentifizieren.

[...]
ssl = required
[...]
ssl_cert = </etc/ssl/certs/imap.myservices.tld.crt
ssl_key = </etc/ssl/private/imap.myservices.tld.key
[...]

Beispiel: Postfix

Die vollständige Konfiguration der SSL-Verschlüsselung des mächtigen E-Mail-Servers Postfix führt deutlich über den hier beschriebenen Teilaspekt hinaus [4]. In unserem Beispiel geht es lediglich darum, die SMTP-Verbindung zwischen dem E-Mail-Client am Endgerät und dem Mail-Transfer-Agent auf dem Server abzusichern.

Ähnlich wie bei IMAP muss der Client dabei sicherstellen können, die zu versendenden E-Mails nur an den richtigen Server weiterzureichen. Auch hier authentifiziert sich der Client im Gegenzug mit Benutzername und Passwort über eine bereits verschlüsselte Verbindung auf dem sicheren ESMTP-Port.

Auf dem ESMTP-Port beginnt die Kontaktaufnahme stets unverschlüsselt. Der Server schaltet erst dann auf Verschlüsselung um, wenn der E-Mail-Client diese explizit über ein STARTTLS-Kommando anfordert. Vergessen Sie, in der E-Mail-App die entsprechende Einstellung zu treffen (SSL/TLS/STARTTLS), dann authentifiziert sich der Mailclient ungeschützt beim Server und gibt so Passwort und Benutzernamen preis.

Das Zertifikat und den Schlüssel tragen Sie in der Konfigurationsdatei /etc/postfix/main.cf wie in Listing 7 gezeigt ein.

[...]
smtpd_tls_cert_file = /etc/ssl/certs/smtp.myservices.tld.crt
smtpd_tls_key_file = /etc/ssl/private/smtp.myservices.tld.key
[...]

Beispiel: Nextcloud

Der Zugriff auf einen Cloud-Dienst wie Nextcloud erfolgt typischerweise über WebDAV für Datei- und Verzeichniszugriffe oder die darauf aufbauenden Protokolle CalDAV und CardDAV für Kalender- beziehungsweise Kontaktdaten.

Alle haben gemeinsam, dass sie auf dem HTTP-Protokoll basieren – und damit gilt es, den Webserver (zum Beispiel Apache) auf HTTPS einzustellen. Wie das insgesamt funktioniert, lesen Sie bei Bedarf direkt beim Apache-Projekt nach [5]. Auf jeden Fall müssen Sie dazu in der Konfigurationsdatei /etc/apache2/sites-enabled/ssl.conf die entsprechenden Zertifikatsdateien angeben (Listing 8).

<VirtualHost *:443>
  ServerName cloud.myservices.tld
  SSLEngine on
  SSLCertificateFile /etc/ssl/certs/cloud.myservices.tld.crt
  SSLCertificateKeyFile /etc/ssl/private/cloud.myservices.tld.key
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  # Pfad zu den Webinhalten
  DocumentRoot /var/www/
</VirtualHost>

Die Endgeräte

Es gibt viele verschiedene Wege, um das Root-Zertifikat ca.crt auf diverse mobile Endgeräte zu übertragen und sie dort zu installieren, nachdem Sie sie mithilfe des Fingerabdrucks in <§§I>caFingerabdruck<§§I>.sha1.txt überprüft haben.

Der für alle Geräte wahrscheinlich gangbarste davon: Sie laden die Datei ca.crt auf einen per Webbrowser erreichbaren File-Server. Das kann auch der eigene Webserver sein, der die Cloud-Dienste bereitstellt, oder aber das NAS am eigenen Router.

Den Fingerabdruck müssen Sie dann aber separat übermitteln, zum Beispiel auf einem Blatt Papier. Zwar dürfen Sie beide Dateien grundsätzlich veröffentlichen, doch müssen Sie dabei gewährleisten, dass ein Angreifer nicht beide gemeinsam manipuliert.

iPhone

Recht einfach klappt das Einrichten der Zertifikate auf iPhone und iPad. Mit dem Standard-Webbrowser Safari steuern Sie den Ablageort des Root-Zertifikats an, klicken auf die Zertifikatsdatei und drücken im Popup-Menü auf Zulassen (Abbildung 1).

Abbildung 1: Zum Einrichten des Zertifikats auf einem iPhone oder iPad genügt ein Aufruf von Safari.

Dann überprüfen Sie das Zertifikat, indem Sie sich durch die Details bis zum Fingerabdruck durchklicken und dessen Gültigkeit überprüfen (Abbildung 2). Bei positivem Ergebnis installieren Sie das Zertifikat, sodass es anschließend auf dem Gerät als überprüft vorliegt (Abbildung 3).

Abbildung 2: Vor dem Installieren des Zertifikats überprüfen Sie den Fingerabdruck auf seine Gültigkeit.

Abbildung 3: Passt der Fingerabdruck, richten Sie das Zertifikat auf dem Apple-Gerät ein.

Bei neueren iOS-Versionen genügt das aber noch nicht. In den Einstellungen hangeln Sie sich über Allgemein und Info zum Punkt Zertifikatsvertrauen durch und aktivieren dort nochmals das entsprechende Root-Zertifikat (Abbildung 4).

Abbildung 4: Unter neueren iOS-Versionen fällt eine zusätzliche Bestätigung des Zertifikats an.

Einmal systemweit installiert, gilt das Zertifikat sowohl für alle gängigen Webbrowser (Safari, Chrome, Firefox) als auch für die hauseigenen Apps für E-Mail, Kalender, Aufgaben und Kontakte. Ab jetzt brauchen Sie also beim Einrichten der Anwendungen über Einstellungen | Passwörter**&**Accounts nur mehr darauf zu achten, in den jeweiligen erweiterten Einstellungen SSL zu aktivieren und die korrekten Ports zu setzen.

Android

Recht ähnlich wie beim iPhone, jedoch nicht ganz so konsistent, funktioniert das Einrichten der Zertifikate auch auf den aktuellen Android-Versionen. Am besten benutzen Sie dazu den vom Hersteller vorinstallierten Standard-Webbrowser. Klicken Sie darin das Root-Zertifikat an, erscheint der Zertifikatsmanager. Hier weisen Sie dem Zertifikat einen Namen zu und können es dann benutzen (Abbildung 5).

Abbildung 5: Den Zertifikatsimport erledigen Sie unter Android am besten im Standard-Webbrowser des Systems.

Das gelingt sogar, ohne es zu überprüfen – das erfolgt bei Android überraschenderweise erst im Nachhinein. Dazu klicken Sie sich in den Einstellungen über Sicherheit & Datenschutz bis zur manchmal sehr versteckten Rubrik Vertrauenswürdige Anmeldedaten/CA-Zertifikate durch.

Im Reiter Benutzer finden Sie das zuvor installierte Zertifikat, wieder mit dem Originalnamen. Jetzt können Sie die Informationen sowie den Fingerabdruck einsehen und damit überprüfen (Abbildung 6). Falls etwas nicht stimmt, löschen Sie das Zertifikat sofort wieder. Anderenfalls installieren Sie es mit einem Klick auf OK systemweit.

Abbildung 6: Unter Android überprüfen Sie installierte Zertifikate erst im Nachhinein und richten Sie dann per OK systemweit ein.

Trotz der damit abgeschlossenen Installation nutzen aber nicht notwendigerweise alle Apps das Zertifikat auch. Der Chrome-Browser, der E-Mail-Client K9 und viele Apps zur Synchronisation der Kalender, Aufgaben und Kontaktdaten greifen darauf zu. Firefox und die E-Mail-App R2Mail2 dagegen möchten das Zertifikat in ihren eigenen Zertifikatsspeicher installiert haben.

Die App R2Mail2 unterscheidet zwischen SSL/TLS und STARTTLS. Je nach Serverkonfiguration müssen Sie das eine oder das andere vorgeben. Wählen Sie aber keinesfalls die trust-all-Varianten: Damit entfällt die Prüfung des Server-Zertifikats mittels des Root-Zertifikats. Die Verbindung erfolgt dann zwar immer noch verschlüsselt, aber die Prüfung der Authentizität des Servers entfällt.

Linux

Auf einem Linux-Client funktioniert die Installation recht einfach: Sie kopieren das Root-Zertifikat ca.crt ins Verzeichnis /etc/ssl/certs/. Hier benennen Sie es am besten noch auf einen aussagekräftigeren Namen um, setzen den Eigentümer auf root und legen die Zugriffsrechte so fest, dass alle es lesen können. Das war es dann auch schon. Allerdings gilt hier wie unter Android: Nicht alle Programme nutzen zwangsweise diese Installation, insbesondere Firefox besteht auf seiner Extrawurst.

Firefox

Unabhängig vom verwendeten Betriebssystem besteht Firefox in aller Regel darauf, Root-Zertifikate in seinem eigenen Zertifikatsspeicher zu verwalten. Sie finden die entsprechenden Einstellungen unter Einstellungen | Datenschutz**&**Sicherheit | Zertifikate. Zum Installieren greifen Sie mit dem Browser auf das Zertifikat zu und geben beim Importieren die gewünschte Nutzungsart an (Abbildung 7). Dabei überprüfen Sie über die Details die Ausstellerinformationen und den Fingerabdruck (Abbildung 8).

Abbildung 7: Beim Import des Zertifikats in Firefox geben Sie die gewünschte Nutzungsart an.

Abbildung 8: In der Zertifikatsansicht überprüfen Sie mithilfe der Fingerprints die Gültigkeit.

Fazit

Es fällt im Prinzip nicht besonders schwer, eine eigene Zertifikatsinfrastruktur aufzubauen, um damit die Datenkommunikation zwischen den eigenen Servern und Endgeräten zu schützen. Allerdings schreckt viele potenzielle Nutzer ab, dass die Handhabung auf jeder Plattform etwas anders ausfällt: So kommt oft ein mulmiges Gefühl auf, ob man denn jetzt wirklich alles richtig gemacht hat und sich nicht etwa in falscher Sicherheit wähnt. Mit den Handreichungen aus diesem Artikel bleiben Sie aber immer auf der sicheren Seite.