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.2 oder höher.
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 Einrichtung 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):
- Client erhält Zertifikat vom Server
- Solange weiteres Intermediate benötigt:
- Intermediate vom Server benutzen oder notfalls herunterladen
- Client prüft vorheriges Zertifikat mit Intermediate
- 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 Niederlande. 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 verändert. Intermediates haben eine kürzere Laufzeit und können einfacher widerrufen werden. Sie werden genutzt, um 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 die Bestätigung einer CA, dass der Inhaber des Private Key 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 Zertifikatsdatei handhaben zu müssen, ermöglichen die meisten Webserver das Abspeichern des Domain Zertifikats und Intermediate Zertifikate in einer Datei. Der Private Key sollte in einer separaten Datei gespeichert werden. Auch die Reihenfolge der Zertifikate ist 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}
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.
Zertifikatsketten reparieren
Ab und zu findet man 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. Dies resultiert in einem anderen Certification Path und führt 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. Eine Reparatur während des Live-Betriebs finden nur in Absprache mit unseren Kunden statt.
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 sich die Comodo CA 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, wird sie selbst als Intermediate angesehen. Die Verifizierung findet also über die frühere CA statt. Dies ist vollkommen unnötig und kann zu großen Problemen führen, sobald die zeichnende CA abläuft.
Aufgrund der Komplexität des Themas haben wir uns auf das Wesentliche beschränkt. Für weitere Informationen empfehlen wir das OpenSSL Cookbook. Um die SSL-Konfiguration zu erleichtern und unnötige Fehler vorzubeugen, empfehlen wir das SSL Configuration Tool von Mozilla: https://ssl-config.mozilla.org/.
Anschließend sollte die korrekte Konfiguration des Webservers überprüft werden. Dafür kann man den SSL-Test von SSL Labs verwenden. Nach dem Test enthält man einen ausführlichen Report mit allen wichtigen Daten und die unterstützten Browser-Versionen mit der aktuellen Konfiguration: https://www.ssllabs.com/ssltest/
