Netz - Rettung - Recht

SSL-/TLS-Zertifikate und deren Prüfung

Das liegt darin, dass Verschlüsselung allein zumindest im Grundsatz nicht genügt - wichtig ist auch Authentifizierung, also die Überprüfung, ob man auch mit der richtigen Gegenstelle spricht oder sich ein Dritter, der “Man in the middle”, dazwischengehängt hat. Zu einer mittels SSL/TLS (in Zukunft: SSL als Sammelbegriff für beides) gesicherten Verbindung gehört daher - eigentlich - auch immer die Überprüfung des Zertifikats der Gegenstelle. Dazu muss man entweder den Fingerprint des Zertifikats kennen und prüfen - PGP/GPG lässt grüßen -, oder man begnügt sich damit, dass eine Zertifizierungsstelle die Echtheit des Zertifikats bestätigt hat (und hofft auf deren Sorgfalt; eine Hoffnung, die die Praxis bereits vielfach enttäuscht hat).

Will man selbst verschlüsselte Zugänge anbieten, genügt es für die meisten Dienste, ein selbst-signiertes Zertifikat zu erstellen und den Nutzern den Fingerprint mitzuteilen. In der Regel ist der Nutzerkreis selbstgehosteter Dienste nämlich überschaubar: der private Mailserver wird zum Versand und zum Mailabruf in der Regel nur selbst oder allenfalls von Familienmitgliedern und Freunden genutzt, die dem selbst-signierten Zertifikat dann vertrauen können. Nicht unüblich ist es auch, auf eine Zertifikatsprüfung zu verzichten und jedes präsentierte Zertifikat zu akzeptieren, also nur die Verschlüsselung zu nutzen und der Gegenstelle zu vertrauen. Das ist insofern nachvollziehbar, als es deutlich einfacher ist, (unverschlüsselten) Datenverkehr mitzulesen als sich als “Man in the middle” mit einem falschen Zertifikat in den verschlüsselten Datenstrom einzuklinken.

HTTPS im Speziellen

Bei Webdiensten liegt der Fall hingegen etwas anders: zumeist erfolgt der Zugriff für die Allgemeinheit - der nicht zwingend einer Absicherung durch Verschlüsselung bedürfte - über dieselbe “Domain” (ich verwende den Begriff hier umgangssprachlich; richtiger wäre “Hostname”) wie die Administration. Ein Blog, bspw., das unter http://meinblog.example/ zugänglich ist, wird meist über http://meinblog.example/admin/ verwaltet, nicht aber über http://admin.meinblog.example/. Ich muss also damit rechnen, dass auch die Allgemeinheit auf meine Webseiten über HTTPS zugreift, oder ich will das sogar erzwingen, damit ich nicht versehentlich Passwörter über eine ungeschützte Verbindung übertrage.

Dann habe ich aber ein Problem: mein selbst-signiertes Zertifikat ist den Besuchern der Webseite natürlich unbekannt, und Browser generieren für diesen Anwendungsfall zunehmend auffälligere Warn- und Fehlermeldungen, die einen Zugriff auf die Seite entweder ganz unterbinden oder doch arg erschweren und den Durchschnittsnutzer abschrecken (was ja auch Sinn der Sache ist).

Virtual Hosting

Zu diesem Problem der Fehlermeldungen bei selbst-signierten Zertifikaten kommt noch ein ein weiteres hinzu: es ist üblich, über einen Webserver (auf ein- und derselben IP-Adresse) eine Vielzahl von “Domains” (also getrennten Webseiten) anzubieten. Bei größeren Anbietern können das hunderte oder zigtausende Nutzer sein, die sich da auf einem Host tummeln, aber auch der private Nutzer hat vielleicht neben seiner Homepage unter meine-domain.example auch noch ein Blog unter blog.meine-domain.example oder will schlicht seine Webseiten sowohl unter meine-domain.example als auch unter www.meine-domain.example erreichbar machen. Das sind aber alles unterschiedliche Hostnamen, und da jedes SSL-Zertifikat angeben muss, für welchen Hostnamen es gültig ist, haben wir das nächste Problem: liefert der Webserver für www.meine-domain.example das Zertifikat für meine-domain.example aus, verfallen die Warnmeldungen im Browser nicht selten in eine noch schrillere Tonlage.

Es ist leider auch nicht so einfach, für jede “Domain” ein eigenes Zertifikat zu präsentieren. Der Zugriff auf solche virtual hosts erfolgt nämlich in der Weise, dass der Browser einen Header mitschickt, aus dem sich ergibt, auf welche “Domain” er zugreifen will. Für diesen Zugriff muss aber die verschlüsselte Verbindung schon stehen; andersherum weiss der Server beim Verbindungsaufbau noch nicht, welche “Domain” angefragt wird, und kann daher auch nicht das jeweils “richtige” Zertifikat ausliefern.

Was also tun?

Lösungswege

Über die Jahre habe ich verschiedene - allesamt mehr oder weniger unbefriedigende - Möglichkeiten getestet, um diesem Problem zu Leibe zu rücken.

Die eigene CA

Angefangen habe ich vor gut einem Jahrzehnt mit einer eigenen Zertifizierungsstelle, die meine SSL-Zertifikate signiert. Dann reicht es nämlich, das Stammzertifikat dieser Zertifizierungsstelle dem Browser (und ggf. dem Mailprogramm) als gültig unterzuschieben, und alle anderen Zertifikate werden automatisch akzeptiert. Das erleichtert zumindest einmal mir selbst (und Freunden und Bekannten, die mir ausreichend trauen) den Umgang mit verschiedenen Servern und ggf. verschiedenen Hostnamen, behebt aber nicht das Problem, dass das Zertifikat immer nur für einen Hostnamen (eine “Domain”) gültig ist, und hilft auch den Webseitenbesuchern nicht.

Ich habe mich daher in der Regel darauf beschränkt, HTTPS nur ergänzend anzubieten oder nur für solche Webseiten, die ausschließlich intern genutzt werden und sich nicht an die Allgemeinheit richten. Professionell geht aber fraglos anders.

SAN

Danach habe ich mich mit Subject Alternate Names, kurz SAN, vertraut gemacht. Es ist nämlich möglich, einem Zertifikat mitzugeben, dass es für mehr als einen Hostnamen gültig ist. Zum einen gibt es - nicht empfehlenswerte - sog. “Wildcard-Zertifikate”, die für alle Subdomains einer bestimmten Domain gültig sind, bspw. *.domain.example. Zum anderen gibt es SAN - zusätzliche Hostnamen, für die das jeweilige Zertifikat auch gilt. Die kann man bei der Erstellung des Zertifikats mit angeben.

Das funktioniert ganz gut, löst aber zum einen nicht das Problem der fehlenden allgemeinen Akzeptanz des Zertifikats und schafft zudem zwei neue Schwierigkeiten. Zum einen kann jeder Besucher durch Ansicht des Zertifikats feststellen, welche Webseiten auf dem Server sonst noch so gehostet werden (was nicht immer optimal ist), zum anderen braucht es für jede neue “Domain”, auf die auch per HTTPS zugegriffen werden soll, auch ein komplett neues Zertifikat.

SNI

Dem strukturellen Problem, dass der Server erst die verschlüsselte Verbindung aufbauen muss und danach erfährt, für welche “Domain” er das eigentlich tun soll, ist man mit Server Name Indication, kurz SNI, zu Leibe gerückt. Das ist eine Erweiterung des TLS-Protokolls, die es dem Client erlaubt, beim Verbindungsaufbau bereits mitzuteilen, aus welcher “Domain” er später Webseiten abrufen will, so dass der Server ihm dann das richtige Zertifikat präsentieren kann. So kann auch der Webserver für jede “Domain” ein eigenes Zertifikat anbieten.

Mittlerweile darf man davon ausgehen, dass SNI so verbreitet ist, dass man es im praktischen Betrieb voraussetzen kann: Firefox unterstützt es seit Version 2.0, der Internet Explorer seit Version 7 und Windows Vista (nicht unter Windows XP), und auch wget sollte das seit 2012 beherrschen.

Kommerzielle Zertifikate

Dies wiederum ermöglicht es, auf kommerzielle SSL-Zertifikate zurückzugreifen. Deren Anbieter lassen sich nämlich ihre Dienste bei “Wildcard-Zertifikaten” oder solchen mit einer Vielzahl von Hostnamen (oder auch bei erweiterter Validierung der “Domains”, für die das Zertifikat gelten soll) geradezu fürstlich bezahlen; Zertifikate für nur ein oder zwei Namen (also bspw. domain.example und www.domain.example) sind hingegen erschwinglich oder gar kostenlos. SNI macht es jetzt möglich, jeder “Domain” ihr eigenes günstiges Zertifikat zuzuweisen, bspw. von StartCom, einem Anbieter, der Zertifikate für maximal zwei “Domains” kostenlos abgibt (dann allerdings für den Widerruf eines kompromittierten Zertifikats Geld verlangt - nun ja).

So kann man dann allmählich vernünftig mit SSL arbeiten.

Die Zukunft: letsencrypt

Neuerdings befindet sich zudem mit Let’s Encrypt ein Anbieter am Start, der sich kostenloses, freies und massentaugliches SSL/TLS auf die Fahnen geschrieben hat:

Let’s Encrypt is a new Certificate Authority:
It’s free, automated, and open.

Dazu werde ich später mehr berichten.

SSL-Zertifikate und Apache

Nach der Theorie nun etwas Praxis: wie richte ich beim Apache-Webserver einen virtual hosts mit SSL ein?

Im Prinzip ist das recht einfach; Debian liefert bspw. eine entsprechende Konfiguration schon mit. Ich setze im Folgenden voraus, dass sowohl passende SSL-Zertifikate (mit dem zugehörigen private key in entschlüsselter Form, d.h. ohne Passwortschutz) vorhanden als auch virtual hosts grundsätzlich eingerichtet sind. Die Zertifikate speichere ich im Verzeichnis /etc/apache2/ssl.

Eine Basis-Konfiguration könnte dann - mit einem Zertifikat von StartCom - bspw. so aussehen:

<VirtualHost *:443>
    ServerName meine-domain.example
    ServerAlias www.meine-domain.example

    DocumentRoot /var/www/meine-domain.example

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/meine-domain.example.crt
    SSLCertificateKeyFile /etc/apache2/ssl/meine-domain.example.key
    SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem
</VirtualHost>

Will man alle Zugriff von HTTP auf HTTPS umleiten, kann man bspw. folgendes ergänzen:

<VirtualHost *:80>
    ServerName meine-domain.example
    ServerAlias www.meine-domain.example

    Redirect / https://meine-domain.example/
</VirtualHost>

Disclaimer

SSL/TLS, der Umgang mit Zertifikaten und die Konfiguration des Apache sind ein weites Feld, für das ich zudem kein Spezialist bin.

Dieser Beitrag will einen kurzen, knappen und daher notwendigerweise unvollständigen Überblick zu diesem Thema geben und zur eigenen Beschäftigung damit anregen. Ich habe daher manches vereinfacht, anderes weggelassen, wieder anderes - absichtlich oder unabsichtlich - ungenau dargestellt.

Dies ist kein Tutorial, und die am Schluss genannten Beispiele sind nicht zur 1:1-Übernahme via copy & paste geeignet.

Wenn sich Fehler eingeschlichen haben, bin ich über Kommentare dankbar - und auch Ergänzungen nehme ich natürlich gerne entgegen.