Dass es nicht nur sinnvoll, sondern mittlerweile dringend notwendig ist, die eigene Webseite mit einem SSL-Zertifikat auszustatten, darauf hatten wir schon wiederholt hingewiesen. Die meisten Firmen haben das mittlerweile auch gemacht. Aber gerade bei kleineren Unternehmen werden hier noch immer gravierende Fehler gemacht. In diesem Beitrag zeigen wir, wie man sie vermeidet.

Das Thema SSL kam zunächst damit in Fahrt, dass Google angekündigt hat, Webseiten, die mit SSL laufen (also über https und nicht über http aufgerufen werden) in den Suchergebnissen besser zu stellen, als Seite ohne SSL-Zertifikat. Dass die geringen Kosten eines Zertifikats lohnend sein können, hatten wir schon in einem Beitrag von 2016 dargelegt. Spätestens mit Inkrafttreten der DSGVO im Mail 2018 war SSL-Verschlüsselung der Webseite aber kein entbehrlicher Luxus mehr. Sobald die Seite personenbezogene Daten übertragen konnte - wofür schon ein Kontaktformular ausreichte - wurde SSL Pflicht. Die Umstellung der eigenen Webseite auf SSL ist in der Regel nicht besonders schwierig. Für die Umstellung von Drupal oder Wordpress hatten wir das in zwei kleinen Beiträgen beschrieben. Mittlerweile gab es auch kostenlose SSL-Zertifikate. Das wohl bekannteste Projekt hierfür ist Let's Encrypt. Da deren Zertikate nur 3 Monate gültig sind, sollte man deren Erneuerung unbedingt serverseitig automatiseren, damit man nicht plötzlich mit einem abgelaufenen Zertifikat da steht.

Und damit wären wir auch schon bei den Problemen, die wir immer wieder bei Webseiten vor allem kleinerer Firmen oder Vereine finden.

Problem: Abgelaufenes Zertifikat

Die maximale Gültikeit von SSL-Zertifikaten ist in den letzten Jahren sukzessive verkürzt worden. Vor 2015 konnte man sich noch Zertifikate ausstellen lassen, die bis zu fünf Jahren gültig waren. 2018 wurde die maximale Gültigkeit erst auf drei, dann auf zwei Jahre reduziert. Seit September 2020 beträgt dieser Zeitraum nur noch 13 Monate (genauer: 397 Tage). Wie lange das Zertifikat noch läuft, kann sich jeder im Brower anzeigen lassen. Hier haben wir ein Beispiel für ein bereits seit zwei Jahren abgelaufenes Zertifikat.

Problem: Selbst signiertes Zertifikat

Um die jährlichen Gebühren für ein "ordentliches" Zertifikat zu sparen, wurden und werden noch immer gerne auch mal selbst signierte Zertifikate eingesetzt. Die lassen sich leicht erzeugen und genauso einbinden wie Zertifkate von vertrauenswürdigen Zertifizierungsstellen. Das Problem: Jeder Browser stuft solche Zertifikate als "nicht vertrauenswürdig" ein und blockiert erst einmal die Anzeige der Webseite. Im Firefox erscheint dann beispielsweise folgende Fehlermeldung:

Zwar kann man sich in einem solchen Fall durch klicken auf "Erweitert" und "Risiko akzeptieren und fortfahren" die Seite trotzdem anzeigen lassen. Allerdings machen viele Besucher das erfahrungsgemäß nicht und verlassen die Seite. Wertvolles Besucherpotenzial geht verloren!

Problem: Ungültige Domain

Hin und wieder kommt es vor, dass ein Zertikat verwendet wird, das nicht für die Domain gedacht ist. Hier ein schönes Beispiel. Die Domain https://www.rettershof-kelkheim.de/ wird offenbar nicht mehr für den Rettershof genutzt sondern verweist eigentlich auf Inhalte der Stadt Kelkheim. Aus welchen Gründen auch immer, hat man für diese eigenständige Domain aber weder eine Umleitung auf kelkheim.de eingerichtet, noch ein eigenes SSL-Zertifikat verwendet, sondern das der Domain kelkheim.de. Und somit gibt der Browser auch hier eine Sicherheitswarnung aus.

Zwar kann man auch hier durch klicken auf "Erweitert" und "Risiko akzeptieren" die Seite aufrufen und diese Sicherheitsausnahmeregel dauerhaft speichern. Aber wie beim vorherigen Problem gilt auch hier: viele werden das nicht machen.

Das gleiche kann auch passieren, wenn man einen schlecht konfigurierten Webspace nutzt, der es ermöglicht eigene Zertifkat für die eigene Domain einzubinden. Bei einem einfachen Hostingpaket teilt man sich den Server mit zahllosen anderen Domains. Wenn der Server z.B. die (generische) Domain 123.des-providers-server.de hat, lautet das Serverzertifikat entsprechend auf des-providers-server.de. Die eigene Domain heißt aber völlig anders, z.B. mein-super-onlineshop.de. Wird nun das Serverzertifikat eingebunden, kriegen wir wieder die obige Warnung im Browser angezeigt. Und zack, sind die potenziellen Kunden weg noch bevor sie überhaupt auf der Seite waren.

HTTP und HTTPS laufen parallel

Mangelhaft konfigurierte Webseiten erlauben es, die Seite auch noch über eine unverschlüsselte HTTP-Verbindung aufzurufen. Das ist kein so gravierendes Problem wie die oben aufgeführten, führt aber dazu, dass der Browser oben in der Adressleiste eine Warnmeldung ausgibt (z.B. "Nicht sicher" oder ein durchgestrichenes Schloss). Die Seite wird immerhin ohne weitere User-Interaktion angezeigt. Trotzdem sollte man sowas vermeiden und eine korrekte Weiterleitung auf HTTPS einrichten.

Die Lösung

all dieser Probleme ist relativ einfach.

1. Es werden keine selbst signierten Zertifikate verwendet, sondern nur solche von Zertifizierungsstellen, die im Browser eingetragen sind. Let's Encrypt ist hier eine gute Wahl, da es kostenlos ist und von allen Browsern als vertrauenswürdig eingestuft wird.
2. Jede Domain bekommt ein eigenes Zertifikat.
3. Um abgelaufene Zertifikate zu vermeiden, wird jedes Zertifikat rechtzeitig vor Ablauf (möglichst automatisch) erneuert. Gute Provider bieten mittlerweile standardmäßig kostenlose Zertifikate z.B. von Let's Encrypt an und erneuern diese automatisch.
4. In den Einstellungen des Hosting-Paketes wird die "HTTPS-Weiterleitung" aktiviert. Diese erzwingt für alle Besucher eine gesicherte Verbindung - auch wenn diese noch über das ungesicherte HTTP die Seite aufrufen, z.B. weil das noch so in deren Bookmarks eingetragen ist.

Viel Erfolg!