Hier beschreibe ich einige Aspekte und Tücken der Transport Layer Security TLS.
Mit TLS-Zertifikaten können sich typischerweise Server gegenüber den Clients ausweisen. Die bekannteste Implementierung ist wohl das HTTPS‑Protokoll im Web. Dabei wird dann auch die Kommunikation zwischen den beiden vertraulich verschlüsselt. Es ist aber auch möglich, dass der Client sich ausweist, und auch die Signierung und Verschlüsselung von E‑Mails ist damit möglich. Das ist als S/MIME bekannt. Hier betrachte ich im weiteren das Zertifikat eines Servers.
Damit das Zertifikat vertrauenswürdig ist, wird es von einer Certification Authority (CA) signiert. Die Zertifikate der CA sind den Clients bekannt. Sie werden typischerweise mit dem Betriebssystem ausgeliefert. Aus verschiedenen technischen Gründen nutzt die CA für die Signierung oft nicht ihr vorab verteiltes Zertifikat, sondern ein damit signiertes. Die dafür zusätzlich benötigten Zertifikate sind als Certificate Chain (Kette) oder Intermediate Certificate bekannt. Sie sollten bei jeder Verbindung mit übertragen werden. Die meisten Clients behalten die Chain aber in ihrem Cache und nutzen sie auch für andere Verbindungen, sodass fehlende Chains oft nicht gleich auffallen.
Technisch wird in einem Certificate Signing Request (CSR) festgehalten, was signiert werden soll. Das ist mindestens ein Canonical Name (CN), der bei einem Server dem Hostnamen entspricht. Der Inhaber des zukünftigen Zertifikats signiert den CSR mit seinem privaten Schlüssel und schickt das CSR weiter an die CA zum Signieren. Grundsätzlich ist zwischen diesen beiden Signierungen kein Unterschied. Er könnte es auch selbst zweimal signieren. Ein solches Zertifikat nennt man dann self-signed. Genau so entstehen auch die Zertifikate der CA. Ist ein solches Zertifikat aber nicht von einer bekannten CA, so spricht man auch von Snake Oil. Das war früher ein Begriff für Substanzen, die eine Wirkung versprechen, die sie nicht halten können.
Wichtig ist hierbei immer zu verstehen, dass ein Zertifikat öffentlich ist. Es muss nicht geheim gehalten werden und bedarf keiner Vertraulichkeit. Im Gegenteil: Es liegt frei verfügbar im Netz und kann von jedem gelesen werden. Das ist auch notwendig, weil genau mit dem Zertifikat auch die Verbindung verschlüsselt wird. Der oben erwähnte Schlüssel hingegen muss geheim gehalten werden. Er darf nur dem Server bekannt sein. Sollte er in falsche Hände fallen, ist er kompromittiert und wertlos und ebenso alle Zertifikate, die mit ihm signiert wurden.
Kompromittierte Schlüssel werden zurückgezogen. Sie werden für ungültig erklärt. Früher konnte man „just in time“ bei jedem Verbindungsaufbau über das Online Certificate Status Protocol OCSP prüfen, ob ein Zertifikat noch gültig ist. Das macht man heute nicht mehr. Zum einen sind die OCSP-Server damit oft überlastet und ein Hacker könnte mit einer DOS-Attacke eine große Anzahl an Servern unbrauchbar machen. Zum anderen ist es problematisch im Sinne des Datenschutzes, dass der OCSP-Server damit Kenntnis erhält, wer wann welchen Server nutzt.
Stattdessen nutzt man eine Certification Revocation List (CRL). So eine CRL ist eine von der CA signierte Datei, die alle Zertifikate enthält, die zurückgezogen wurden. Die Liste enthält nur eine Seriennummer des Zertifikats. Diese Nummer kann ich dem Zertifikat entnehmen. Ich bekomme aber umgekehrt keine Liste von Servern, die kompromittiert wurden. So ist also auch dieser Aspekt der Vertraulichkeit gewährleistet. Da die Datei selbst signiert ist, muss es die Verbindung, über die ich sie erhalte, nicht sein. Und ich kann diese CRL auch speichern und weitergeben, ohne besonders auf die Sicherheit zu achten.