Zertifikate und Zertifikatsketten

Zum Managed Hosting gehört mehr als nur der Betrieb von Servern. Dazu gehören auch komplexe Themen wie HTTPS und Zertifikatsketten. Wir erklären, wie sie funktionieren, welche Fehler dabei am häufigsten gemacht werden und wie wir diese Fehler beheben.

HTTPS und Zertifikatsketten

Verschlüsselung ist heikel. An ihr hängen die Vertrauenswürdigkeit einer Seite und die Sicherheit von Kundendaten. Auch die Performance kann beeinflusst werden.

Für die Sicherheit sind folgende drei Aspekte entscheidend:

  • verwendete Protokolle (SSL vs. TLS)
  • zugelassene Cipher
  • benutzte Zertifikatsketten (Root-CAs, Intermediates und Zertifikate)

Bei den Protokollen (SSL/TLS) gilt immer TLS1.0 oder höher. Es gibt Ausnahmen, aber die machen wir bei SysEleven nicht ohne auf die Gefahren hinzuweisen.

Die Cipher sind für die Verschlüsselung zuständig. Hierbei setzen wir auf Sicherheit und Verfügbarkeit: mit weit verbreiteten Ciphern und Prefer Server Cipher Order.

Häufige Probleme

Nicht korrekt erstelle Zertifikatsketten können die Verbindungsgeschwindigkeit nach unten ziehen oder – in sehr seltenen Fällen – die Nutzer von der Seite aussperren. Viele Fehler verhindern wir, bevor sie passieren: wir tauschen SHA1 Intermediates oder übernehmen auf Kundenwunsch die komplette Bestellung und Installation eines Zertifikats.

Manchmal passieren aber auch Dinge, für die es keine Präventivmaßnahmen gibt. Sei es ein Softwarefehler wie Heartbleed oder eine nicht optimale Zertifikatskette. Bereits seit Ende 2016 prüfen wir Zertifikate automatisch auf SHA1 Signatur, da diese inzwischen nicht mehr als sicher gelten. Um ganz sicher zu gehen, prüfen wir nicht nur das Intermediate in einer Zertifikatskette, sondern jedes einzelne Zertifikate.

Die Bausteine einer Zertifikatskette

Zertifikatsketten dienen der Authentifizierung gegenüber dem Client.

Der Ablauf kann wie folgt beschrieben werden (leicht vereinfacht, z.B. kein OCSP):

  1. Client erhält Zertifikat vom Server
  2. Solange weiteres Intermediate benötigt:
    1. Intermediate vom Server benutzen oder notfalls herunterladen
    2. Client prüft vorheriges Zertifikat mit Intermediate
  3. Client prüft Validität des letzten Intermediates mit installierten Root-CAs

Root-CAs

Root-CAs sind Zertifikate, denen der User bedingungslos vertraut. Dazu gehört zum Beispiel GeoTrust oder der Staat der Nederlanden. Diese Zertifikate sind entweder im Betriebssystem oder in der Applikation verankert. Sind diese Zertifikate nicht aktuell, besteht die Gefahr, dass neuere Zertifikate nicht anerkannt werden oder sogar noch CAs vertraut werden, die bereits unsicher sind. Mit solchen CAs im CA-Store ist es nicht mehr möglich eine sichere Verbindung herzustellen.

Intermediates

Es ist schwer, eine Root-CA auszutauschen. Diese werden daher mit langer Gültigkeitsdauer (mehrere Jahrzehnte) erstellt. Bei Problemen ist es nicht möglich, die Root-CA einfach durch eine neue zu tauschen. Daher werden sogenannte Intermediates erstellt und mit dem Root-Zertifikat signiert. Anschließend wird das Root Zertifikat weggesperrt und nicht mehr angefasst außer unbedingt nötig. Diese Intermediates haben eine kürzere Laufzeit und können einfacher widerrufen werden. Sie werden dann genutzt, um die Zertifikate zu signieren, die man bei einer CA bekommt. Üblicherweise hat jede Root-CA mehrere Intermediates. Beispiele sind GeoTrust SSL CA – G3 und GeoTrust EV SSL CA – G4.

Zertifikate

Ein Zertifikat ist letzten Endes die Bestätigung einer CA, dass der Inhaber des Private Keys auch tatsächlich die Person ist, die den Antrag auf das Zertifikat gestellt hat. Da den Root-CAs bedingungslos vertraut wird, heißt das, dass aus Sicht des Users ein Zertifikat von z.B. SysEleven auch tatsächlich uns gehört.

Aufbau einer Zertifikatskette

Heutzutage verwendet man üblicherweise das PEM Format (Base64 encoded DER certificate). Um nur eine Datei handhaben zu müssen, unterstützen es die meisten Webservern auch den Private Key dort einzufügen. Auch ist hier die Reihenfolge der Zertifikate wichtig, da der oben erwähnte Ablauf sonst nicht funktioniert.

Daher sehen unsere Zertifikate meist so aus:

-----BEGIN CERTIFICATE-----
{Zertifikat in Base64}
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
{Intermediate in Base64}
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
{Private Key in Base64}
-----END RSA PRIVATE KEY-----

Falscher Aufbau

Zertifikatsketten sind falsch, wenn

  • falsche Zertifikate enthalten sind.
  • zu viele Zertifikate enthalten sind.
  • Zertifikate fehlen.
  • Root-Zertifikate enthalten sind.
  • die Reihenfolge nicht vom Zertifikat in Richtung Root-CA verläuft.
  • der Private Key nicht am Ende steht.

Zertifikatsketten reparieren

Ab und zu findet man auch mal ein Zertifikat, das die Root-CA beinhaltet. Trotzdem kommt in den meisten Fällen eine erfolgreiche Verbindung zustande. Dies ist den modernen Clients zu verdanken, die automatisch die passende Kette zusammenbaut. Es sorgt aber dafür, dass bei jedem Verbindungsaufbau ein weiteres Zertifikat gesendet wird. In manchen Fällen wird dadurch auch ein anderes Zertifikat als Root Zertifikat verwendet. Das resultiert dann in einem anderen Certification Path und schlimmstenfalls sogar zum Download des passenden Intermediates. Der Verbindungsaufbau wird dadurch wesentlich langsamer. Sollte das andere Root Zertifikat bereits abgelaufen sein, so verweigert der Client den Verbindungsaufbau möglicherweise gänzlich.

Diese Zertifikate reparieren wir, indem wir alle Zertifikate prüfen und die korrekte Reihenfolge herstellen. Wenn es um den Livebetrieb geht, sprechen wir die Maßnahmen natürlich mit unseren Kunden ab.

Sonderfall Comodo

Wie oben bereits erwähnt, kommt es vor, dass unter bestimmten Umständen andere Zertifikate als Root-CA benutzt werden. Wie kann das sein?

Ein gutes Beispiel hierfür ist die Comodo CA. Die CA wurde damals, als sie erstellt wurde, nicht direkt in alle Systeme eingebaut, da die Aufnahme einer Root-CA ein langer Prozess ist. Daher wurde diese CA von einer anderen, bereits etablierten CA, signiert. Somit war die Comodo CA gültig.

Da die Comodo CA sich heutzutage aber in jedem aktuellen Trust Store wiederfindet, wird ein davon gezeichnetes Intermediate sofort als gültig angesehen. Liefert man nun diese Root-CA von der Website aus mit, wird sie selbst als Intermediate angesehen. Es findet also die Verifizierung über die frühere CA statt. Dies ist vollkommen unnötig und wird wahrscheinlich zu großen Problemen führen, sobald die zeichnende CA abläuft.

Da dies ein sehr komplexes Thema ist, habe ich mich auf das Wesentliche beschränkt. Für weitere Informationen empfehle ich das OpenSSL Cookbook.