GlobalSign Blog

21 Nov 2017

So vermeiden Sie die häufigsten SSL-bezogenen Browserwarnungen

Google hat kürzlich die Ergebnisse einer Studie zu Browserwarnungen veröffentlicht. - Sie kennen das, diese abschreckenden Meldungen "Ihre Verbindung ist nicht privat", denen Sie wahrscheinlich irgendwann schon begegnet sind?

Warning message for self-signed or untrusted roots in Chrome

Warnmeldung für selbstsignierte oder nicht vertrauenswürdige Roots in Chrome (Quelle: BadSSL.com)

Obwohl diese Warnungen offensichtlich einem Zweck dienen - Benutzer daran zu hindern, sich mit unsicheren Websites zu verbinden - können viele Dinge diese Warnungen auslösen und einige der Ursachen sind schwerwiegender als andere. Die Sache ist die, dass alle diese Warnungen - ohne dass der durchschnittliche Benutzer eine Chance hat, die schwerwiegenden zu erkennen - nicht nur eine schlechte allgemeine Benutzererfahrung schaffen, sondern auch dazu führen können, dass Benutzer damit anfangen, ALLE Warnungen zu ignorieren. Das Ziel der Untersuchung von Google war es, bei der Lösung gutartiger Fehler zu helfen, ohne Beeinträchtigung der rechtmäßigen.

Sie sollten den vollständigen Bericht lesen, wenn Sie die Gelegenheit dazu haben - Where the Wild Warnings Are (Wo die wilden Warnungen wohnen): Root Causes of Chrome HTTPS Certificate Errors (Grundursachen für HTTPS Zertifikatfehler in Chrome). In der Zwischenzeit habe ich die wichtigsten Ergebnisse im Folgenden zusammengefasst und einige umsetzbare Ratschläge für die Lösung einiger der häufigsten Probleme zusammengestellt.

Was sind die häufigsten Ursachen für Browserwarnungen?

Was steckt also hinter diesen Warnungen? Aus einer Stichprobe von über 300 Millionen Fehlern, die in ca. einem Jahr erfasst wurden (siehe Bericht für die vollständige Methodik), konnte Google die Ursachen von zwei Dritteln der Fehler leicht klassifizieren. Damit kategorisierten sie die Fehler in drei Haupttypen: Server, Client und Netzwerk.

The report goes into great detail about how they defined these categories, including notes on false positives and negatives, but at a high level:

Quelle: Google

Der Bericht geht ausführlich darauf ein, wie sie diese Kategorien definiert haben, wie z.B. Hinweise zu falschen Positiven und Negativen, aber auf hohem Niveau:

Serverfehler treten auf "wenn ein Server eine ungültige oder unvollständige Zertifikatkette präsentiert". Beispielsweise:

  • Serverdatumsfehler (z.B. eine Website verwendet ein abgelaufenes Zertifikat)
  • Fehler 'Servername stimmt nicht überein' (z.B. das Zertifikat enthält nicht den Hostnamen der Website)
  • Fehler 'Serverautorität ungültig' (z.B. das Zertifikat ist nicht mit einer vertrauenswürdigen Root verkettet)
  • Fehler 'Unzureichendes Zwischenzertifikat' (z.B. der Server sendet nur das Endzertifikat, nicht die Zwischenzertifikate)
  • SHA-1-Fehler (d.h. das Zertifikat verwendet den veralteten SHA-1-Algorithmus, der veraltet ist und nicht mehr von Chrome vertraut wird)

Clientfehler treten auf, "wenn ein Client eine Zertifikatkette von einem ordnungsgemäß konfigurierten Server nicht validieren kann". Beispielsweise:

  • Falsch eingestellte Client-Uhren (z.B. ist eine Client-Uhr auf eine Zeit in der Zukunft eingestellt. Also kann es falsch sein, zu behaupten, dass ein Zertifikat abgelaufen ist, obwohl dies in Wirklichkeit nicht stimmt)
  • Anti-Virus-Fehler (z.B. verwendet die Antiviren-Software, die als Proxy zum Entschlüsseln, Überprüfen und Wiederverschlüsseln von HTTPS-Verkehr fungiert, eine abgelaufene Root für die Wiederverschlüsselungszertifikate)

Netzwerkfehler treten auf "wenn ein Netzwerkgerät eine HTTPS-Verbindung abfängt und die Zertifikatkette durch eine ersetzt, die der Client nicht validieren kann". Beispielsweise:

  • Erfassungsportal-Fehler (z.B. ein Erfassungsportal, wie die, denen Sie begegnen, wenn Sie zum ersten Mal versuchen, das WLAN eines Hotels zu benutzen und aufgefordert werden, sich zuerst anzumelden. Es verursacht einen 'Name stimmt nicht überein' -Fehler, weil der Browser den Hostnamen der Website, zu der Sie gehen wollen, anfordert, aber die Login-Seite erhält, deren Zertifikat einen anderen Hostnamen enthält)
  • Fehlende TLS-Proxy-Roots (z.B. einem Browser fehlt das Root-Zertifikat des TLS-Proxys, sodass jedes Mal, wenn der Benutzer versucht, eine Website zu besuchen, die vom Proxy abgefangen und wiederverschlüsselt wurde, er eine Fehlermeldung erhält, weil die Root nicht vertrauenswürdig ist)

Besonders interessant war die gleiche Verteilung auf Server und Nicht-Server- (Client- und Netzwerk-) Fehler - das meiste Material zu diesem Thema konzentriert sich auf die Serverkonfiguration und nehmen Server- und Site-Administratoren in die Pflicht, diese Arten von Warnungen zu verhindern. Diese Ergebnisse zeigen, dass mehr dahinter steckt.

Hinweis: Sie haben sich auch manuell durch eine Stichprobe der nicht klassifizierten Fehler gearbeitet und fanden einen noch höheren Anteil an Netzwerk-/Client-Fehlern im Vergleich zu Server-Fehlern, was die Rolle von Client und Netzwerk noch weiter betont.

So können die häufigsten Browserfehler behoben und vermieden werden

Obwohl der Bericht eine sehr gute Erklärung dieser Fehler und ihrer Ursachen gibt, geht er nicht ins Detail dazu, wie man jeden einzelnen von vornherein behebt oder vermeidet. Dies ist völlig fair, wenn man das Ziel des Berichts berücksichtigt, und in einigen Fällen werden Lösungen angesprochen oder sind aufgrund des Fehlers irgendwie offensichtlich. Aber ich denke, etwas mehr Details und Anleitungen wären hilfreich.

Sie merken, dass ich mich hauptsächlich auf die Serverfehler konzentriere, weil sie mehr in mein Fachgebiet fallen und sie tatsächlich von Site-Admins gelöst werden können. Schließlich können Sie nicht genau kontrollieren, ob die Systemuhren Ihrer Website-Besucher richtig eingestellt sind oder ob ihr Unternehmen einen SSL-Inspection-Dienst verwendet. Außerdem ist die Wichtigkeit der Serverkonfiguration ein Punkt, den wir immer verständlich machen wollen - ein Zertifikat zu erhalten ist nur ein Schritt zur Aktivierung von HTTPS. Sie müssen auch Ihren Server richtig konfigurieren

Hinweis: Während der Bericht nicht intensiv auf Serverfehler eingeht, gibt es einen Abschnitt, der den Änderungen in Chrome gewidmet ist, um einige der anderen Fehler zu minimieren. Sie haben z. B. eine separate Warnung für Clients mit falsch eingestellten Systemuhren erstellt, die tatsächlich erklärt, warum sie den Fehler erhalten, anstatt dieselbe generische Warnung ohne umsetzbaren Hinweis anzuzeigen, und sie haben seit der Umsetzung bereits einen Rückgang dieses Fehlers bemerkt. Sie arbeiten auch an Lösungen für die Erkennung von Erfassungsportalen, unzureichenden Zwischenzertifikaten, nicht übereinstimmenden Namen und mehr. Ich empfehle Ihnen wirklich, den ganzen Bericht zu lesen! Schauen Sie sich zumindest den Abschnitt "Schadensbegrenzungen" am Ende an, um einen Einblick darin zu bekommen, was noch in Planung ist.

Serverdatumsfehler

Der Bericht stellte, nicht überraschend, fest, dass fast alle Serverdatumsfehler durch abgelaufene Zertifikate verursacht wurden. Hier gibt es eine ziemlich offensichtliche Lösung - lassen Sie Ihre Zertifikate nicht ablaufen! Oha, was ist das? Sie behalten immer noch Ihre Zertifikate in einer Excel-Tabelle im Auge und einige davon sind Ihnen durch die Maschen geschlüpft?

Also bitte. Holen Sie sich eine Management-Plattform, um Ihnen dabei zu helfen, auf dem Laufenden zu bleiben. Sie haben Zertifikate von mehreren CAs und können nicht den Überblick behalten? Suchen Sie nach einem Inventar-Tool, das alle Ihre Zertifikate und deren Herkunft findet. Möchten Sie die ganze Sache automatisieren, damit Sie sich darüber keine Gedanken machen müssen? Sie können mit APIs und dem ACME-Protokoll einige ziemlich coole Sachen machen (nicht nur für DV). Es gibt keine Entschuldigung für abgelaufene Zertifikate mehr!

Fehler 'Name stimmt nicht überein'

Google nennt spezifisch www/nicht-www und "außerhalb des Platzhalterbereichs" Subdomain-Fehler. Aber die gleiche Logik gilt wirklich für jeden Hostnamen oder jede Domain. Der Hostname muss im Zertifikat aufgeführt sein, entweder explizit oder im Geltungsbereich eines Platzhalters (z. B. ein Zertifikat für *.example.com würde demo.example.com abdecken).

Es ist möglich, dass die www-Fehler von einer falschen Annahme herrühren, dass ein Zertifikat automatisch sowohl die www- als auch die Nicht-www-Versionen einer Domain abdeckt. Das stimmt nicht! Beide müssen im Zertifikat aufgeführt sein (oder den entsprechenden Platzhalter verwenden). Zu Ihrer Information: Bei GlobalSign ist dies kostenlos in den Zertifikaten enthalten (d.h. wir berechnen es Ihnen nicht extra, das sowohl www als auch nicht-www im selben Zertifikat abgedeckt sind).

Bei den Platzhalterfehlern kann es sich um ein schlichtes Übersehen oder möglicherweise Probleme mit mehreren Domain-Leveln handeln (z. B. würde ein Zertifikat für *.example.com weder test.demo.example.com noch example.com abdecken). Und die Moral von der Geschicht': Überprüfen Sie genau, ob Ihr Hostname tatsächlich in Ihrem Zertifikat oder im Geltungsbereich des Platzhalters enthalten ist.

Ungültige Serverautoritätsfehler

Damit dem Zertifikat Ihrer Website (manchmal als "End" - oder "Untergeordnetes" -Zertifikat bezeichnet) vertraut wird, muss es sich mit einer Root (oder einer "Autorität") verketten, die im Vertrauensspeicher des Browsers aufgeführt ist. Google fand heraus, dass die meisten dieser Fehler, bei denen Zertifikate, die mit einer Root verkettet waren, die nicht im Speicher des Browsers enthalten war, auf selbstsignierte Zertifikate oder behördenbetriebene Roots zurückzuführen waren.

Einfach ausgedrückt: Sie sollten keine selbstsignierten Zertifikate auf öffentlichen Websites verwenden. Niemals. Sie fragen sich vielleicht: "Was ist mit internen Websites oder Intranets"? Auch hier besteht eine Gefahr, da Ihre Mitarbeiter immer noch über einen Browser darauf zugreifen und daher Browserwarnungen begegnen. Ihnen beizubringen, die Warnungen für interne Websites zu ignorieren, könnte dazu führen, dass sie sie auch für das allgemeine Browsen ignorieren, was Ihr Unternehmen anfällig für Malware machen könnte.

Hinweis: Wenn Sie selbstsignierte Zertifikate in Ihren internen Netzwerken verwenden, da Sie Konfigurationen benötigen, die von den CA/Browser Forum Baseline Requirements nicht erlaubt sind (z. B. interne Servernamen, lokale Hostnamen, lange Gültigkeitsdauern), bieten einige CAs (wie GlobalSign) Zertifikate an, die von nicht-öffentlichen Roots ausgestellt werden, die speziell für diese Anwendungsfälle entwickelt wurden.

Behördenbetriebene Roots können zu Fehlern führen, da sie oft nicht in Standard-Vertrauensspeichern enthalten sind. Daher müssen Bürger sie separat auf ihren Rechnern und Geräten installieren. In dem Bericht erwähnt Google eine mögliche zukünftige Minimierung dafür. Grundsätzlich schlagen sie vor, dass, wenn ein Benutzer auf diese Art von Fehlern stößt, er eine spezifische Meldung mit Anleitungen zur Installation der entsprechenden Behörden-Root erhalten würde. Sie erwähnen die offensichtlichen Probleme dabei, aber es ist interessant zu hören, was sie in Erwägung ziehen.

Unzureichende Zwischenzertifikate

Zwischenzertifikate verbinden Endzertifikate (die für Domains/Websites ausgestellten Zertifikate) mit dem vertrauenswürdigen Root-Zertifikat (die oben erwähnte Serverautorität), das im Vertrauensspeicher des Browsers gespeichert ist und eine Vertrauenskette bereitstellt. Dies bedeutet, dass ein Server zusätzlich zum Endzertifikat typischerweise auch die Zwischenzertifikate bereitstellen muss.

Daraus folgt, dass die Lösung zur Vermeidung dieser Art von Fehlern darin besteht, sicherzustellen, dass Sie die entsprechenden Zwischenzertifikate auf Ihrem Server installieren. Die Zertifizierungsstelle (CA), von der Sie Ihr Zertifikat erhalten haben, verfügt über eigene Zwischenzertifikate, die wahrscheinlich von der Art des Zertifikats abhängt, das Sie haben. Bei GlobalSign stellen wir bei der Ausstellung Ihres Zertifikats die entsprechenden Zwischenzertifikate zur Verfügung. Wir haben hier auch Anleitungen für die Installation von Zertifikaten und Zwischenzertifikaten nach Servertyp.

SHA-1 Fehler

Ich denke, wir haben schon alles über SHA-1 gesagt . Verwenden Sie es nicht!!

Bonus - Client-Uhrenfehler

Okay, dieser Abschnitt ist nicht serverbezogen. Aber es gibt etwas, das Server- und Site-Admins tun können, um diese Art von Fehlern zu verhindern (wo die Systemuhr nicht richtig geht und den Browser dazu veranlasst, zu denken, dass die aktuelle Zeit und die Gültigkeitsdauer des Zertifikats nicht übereinstimmen, sodass dem Zertifikat nicht vertraut werden sollte). Wenn Sie zwischen dem Zeitpunkt, an dem Sie das Zertifikat erhalten und wann Sie das Zertifikat tatsächlich verwenden, einen kleinen Abstand lassen, können Sie dies ein wenig minimieren. Wenn Sie beispielsweise Ihr Zertifikat heute erhalten und es heute installieren, würde eine Client-Uhr, die auf eine Zeit in der Vergangenheit eingestellt ist, wenn auch nur einen Tag zu spät, einen Fehler auslösen. Google nennt dieses Szenario als Grund für eine Spitze von Client-verursachten Fehlern bei Windows-Computern im September 2016.

Bonus - TLS-Proxyvorgang-Fehler

Auch dies ist nicht serverbezogen, aber es ist etwas, das in der Kontrolle des Unternehmens liegt. Viele Unternehmen haben SSL-Inspection-Appliances implementiert, die den HTTPS-Datenverkehr abfangen und entschlüsseln, um nach schädlichen Inhalten zu suchen. Die Anwendungen benötigen ihre eigenen, nicht öffentlich ausstellenden CAs, um nach Abschluss der Inspection neue SSL-Sitzungen mit den End-Clients zu erstellen. Da diese ausstellenden CAs nicht öffentlich vertrauenswürdig sein können, sind ihre Roots nicht automatisch im Vertrauensspeicher der Browser. Sie sehen schon, wohin dies führt - wenn der Browser des Endbenutzers nicht die Root in seinem Vertrauensspeicher hat, erhält er einen Zertifikatfehler für jede Website, auf die er zugreift.

Die Lösung dafür ist, sicherzustellen, dass Sie diese Appliance-Root auf alle Endbenutzer-Computer und -Geräte übertragen. Dies kann einfacher gesagt als getan sein, insbesondere, wenn Sie gemischte Endpunktumgebungen mit Nicht-Windows-Clients oder Mobilgeräten und mehrere Roots zu managen und pflegen haben. Wenn Sie sich in der Situation befinden, sollten Sie möglicherweise eine private, dedizierte Root von einer Drittanbieter-CA in Erwägung ziehen. Auf diese Weise hätten Sie nur eine Haupt-Root zu übertragen, mit mehreren untergeordneten ausstellenden CAs, die Sie für verschiedene Anwendungen verwenden können (z. B. SSL-Inspection, Benutzerauthentifizierungszertifikate usw.). Wir haben dieses Thema in einem kürzlich erschienenen Beitrag ausführlich behandelt. Zusammenfassend lässt sich jedoch festhalten, dass dies helfen kann, die Probleme mit der Root-Pflege- und -bereitstellung zu eliminieren, und Sie können CA- und Crypto-Management an eine vertrauenswürdige Drittpartei auslagern.

Zusammenfassung - Übersehen Sie nicht Ihre Serverkonfiguration!

Obwohl wir die Rolle der Client- und Netzwerkkonfiguration bei Browserwarnungen nicht ignorieren sollten, und es toll ist, zu lesen, wie Google durch die Erstellung von mehr benutzerdefinierten und umsetzbaren Fehlermeldungen helfen will, diese zu minimieren, unterstreichen die Ergebnisse der Studie ein weiteres Mal die Wichtigkeit der richtigen Serverkonfiguration.

Wir predigen dies jetzt schon eine Weile ... Habe ich schon unseren kostenlosen Server Konfigurationstest erwähnt? Obwohl die oben genannten Ratschläge helfen, einige der häufigsten Fehler zu vermeiden, empfehle ich Ihnen, das Tool auszuprobieren, um sicherzustellen, dass Sie auch bei anderen Konfigurationskomponenten alles Mögliche tun (z. B. welche SSL/TLS-Protokolle und Cipher-Suites Sie verwenden im Vergleich zu dem, was empfohlen wird, ob Sie für gängige SSL-Schwachstellen anfällig sind). Vergessen Sie nicht - Sie benötigen mehr als ein Zertifikat zur Implementierung von HTTPS!

Haben Sie weitere Fragen zu SSL oder Serverkonfiguration? Lassen Sie es uns wissen! Wir helfen Ihnen gerne!

von Lea Toms

Artikel teilen

Jetzt Blog abonnieren