Wenn der Server sein Zertifikat an den Client sendet, sendet er tatsächlich eine Zertifikatkette , damit der Client das Serverzertifikat leichter validieren kann (der Client ist nicht erforderlich em) > um genau diese Kette zu verwenden, aber in der Praxis verwenden die meisten Kunden die Kette und keine andere). Dies wird im SSL / TLS-Standard, Abschnitt 7.4.2 beschrieben, insbesondere mit diesem aufschlussreichen Auszug:

Das Absenderzertifikat MUSS an erster Stelle in der Liste stehen . Jedes folgende Zertifikat MUSS das vorhergehende direkt zertifizieren. Da für die Zertifikatsüberprüfung die unabhängige Verteilung von Stammschlüsseln erforderlich ist, kann das selbstsignierte Zertifikat, das die Stammzertifizierungsstelle angibt, in der Kette weggelassen werden, unter der Annahme, dass das Remote-Ende es bereits besitzen muss, um es in jedem Fall zu validieren.

Da dies ein "MAI" -Fall ist (die Terminologie "MAI", "MUSS", "SOLLTE" ... in RFC hat sehr genaue Bedeutungen, die in RFC 2119 a erläutert werden >) darf der Server das Stammzertifikat (auch "Vertrauensanker" genannt) in die Kette aufnehmen oder weglassen. Einige Server enthalten es, andere nicht. Eine typische Client-Implementierung, die genau die gesendete Kette verwenden möchte, versucht zunächst, die Kettenzertifikate in ihrem Trust Store zu finden. Andernfalls wird versucht, einen Aussteller für das "letzte" Kettenzertifikat in seinem Vertrauensspeicher zu finden. In beiden Fällen ist dies standardkonform und sollte funktionieren.

(Es gibt eine geringfügige Verwirrung in Bezug auf die Kettenreihenfolge. In wahrem X.509 ist die Die Kette wird vom Vertrauensanker zum Endentitätszertifikat geordnet. Die SSL / TLS-Nachricht "Zertifikat" wird in umgekehrter Reihenfolge codiert. Das Endentitätszertifikat, das den Server selbst qualifiziert, steht an erster Stelle. Hier verwende ich "last" in SSL / TLS-Terminologie, nicht X.509.)

Das einzig schlechte am Senden des Stamms in der Kette ist, dass unnötig ein bisschen Netzwerkbandbreite verwendet wird. Das sind ungefähr 1 kB Daten pro Verbindung , einschließlich eines vollständigen Handshakes . In einer typischen Sitzung zwischen einem Client (Webbrowser) und einem Server ist nur eine Verbindung dieses Typs vorhanden. Die anderen Verbindungen vom Client verwenden "abgekürzte Handshakes", die auf dem anfänglichen Handshake aufbauen, und verwenden überhaupt keine Zertifikate. Und jede Verbindung wird für viele aufeinanderfolgende HTTP-Anforderungen am Leben erhalten. Der durch das Root-Senden implizierte Netzwerk-Overhead ist also gering.

Dies bedeutet, dass die von der Site bereitgestellten Zertifikate das Stammzertifikat der Zertifikatkette enthalten (die Kette, in der ein Zertifikat mit dem Zertifikat seines Ausstellers verknüpft ist, wobei der Stamm ein Zertifikat ist, das sein eigener Aussteller ist).

Da ein Zertifikat nur dann vertrauenswürdig ist, wenn das Stammzertifikat (oder ein dazwischen liegendes Zertifikat) seiner Kette vom Client explizit als vertrauenswürdig eingestuft wird, ist die Angabe des Stammzertifikats nicht erforderlich: Wenn es vertrauenswürdig ist, verfügt der Client bereits über das Zertifikat. Der Bericht weist übrigens weiter unten auf die Bemerkung "Im Vertrauensspeicher" hin.

Ich würde das nicht als Grund für eine Warnung betrachten, vielleicht nur für einen Hinweis. ssltest scheint auch glücklich zu sein, wenn man bedenkt, dass das Zertifikat zu 100% bewertet wurde.

Es könnte auch umgekehrt Exploits gegeben haben: Rogue-Sites, die gefälschte Stammzertifikate bereitstellen, die fehlerhafte Clients mit vertrauenswürdigen verwechseln, was dazu führt, dass der Client vertraut der Standort. Benutzer solcher Clients sind jedoch sowieso in Schwierigkeiten.