Unvollständige Zertifikatskette: Browser ja, App nein

Was die Kette ist und wo sie reißt

Ein TLS-Serverzertifikat sagt für sich genommen nur, dass irgendeine Stelle für einen Namen unterschrieben hat. Belastbar wird die Aussage erst durch das, was darüber liegt: Das Serverzertifikat wurde von einem Zwischenzertifikat ausgestellt, dieses von einem weiteren oder direkt von einem Wurzelzertifikat. Nur das Wurzelzertifikat liegt bereits im Vertrauensspeicher des Clients, hinterlegt vom Betriebssystem, vom Browser oder von der Laufzeitumgebung, und es ist damit der einzige Teil der Kette, den der Server nicht mitzuliefern braucht. Wie lang die Kette insgesamt wird, hängt an der Hierarchie der ausstellenden Stelle: Die Standardkette der ECDSA-Hierarchie einer verbreiteten Zertifizierungsstelle umfasst fünf Glieder, von denen nur das erste zwangsläufig auf dem eigenen Server liegt (Let’s Encrypt).

Der Standard beschreibt genau, was in dieser Lage zu tun ist. RFC 8446 legt für die Certificate-Nachricht fest, dass das eigene Zertifikat als erster Eintrag der Liste kommen muss, dass jedes folgende Zertifikat das unmittelbar vorangehende beglaubigen soll und dass ein Zertifikat, das einen Vertrauensanker benennt, ausgelassen werden darf, weil die Gegenstelle es ohnehin besitzt (IETF, RFC 8446). Aus diesem Absatz folgt die gesamte Betriebspraxis: Blatt zuerst, Zwischenzertifikate dahinter, Wurzel optional. Wer die Zwischenzertifikate weglässt, verstößt gegen keine Muss-Vorschrift des Protokolls. Er verlagert die Beschaffung auf den Client und macht die eigene Erreichbarkeit von dessen Ausstattung abhängig.

• Blattzertifikat: trägt den Domainnamen und den öffentlichen Schlüssel des Servers; ohne dieses Glied kommt keine Verbindung zustande.
• Zwischenzertifikate: verbinden Blatt und Wurzel, wechseln regelmäßig und sind der Teil, der in der Praxis fehlt.
• Wurzelzertifikat: liegt im Vertrauensspeicher des Clients und wird laut Protokoll ausdrücklich nicht erwartet (IETF, RFC 8446).
• Kreuzsignaturen: zusätzliche Pfade für ältere Speicher; ihr Wegfall sparte über 40 Prozent der im Handshake übertragenen Zertifikatsbytes (Let’s Encrypt).
• Vertrauensspeicher: die Liste der akzeptierten Wurzeln, gepflegt vom Betriebssystem, vom Browser oder von der Laufzeitumgebung.

Damit ist die Kette kein Beiwerk der Verschlüsselung, sondern ihr Beweisteil. Die Schlüsselaushandlung kann tadellos sein, die Cipher-Suite aktuell, das Protokoll auf dem neuesten Stand: Fehlt ein Glied, endet die Verbindung trotzdem, und zwar bei genau den Clients, die keinen Ersatz beschaffen können. Warum diese Prüfung nicht einmalig, sondern in festem Takt gehört, beschreibt der Beitrag zur automatischen Zertifikatsüberwachung.

Warum der Browser verzeiht und die Anwendung nicht

Browser haben sich darauf eingestellt, dass Server unvollständige Ketten liefern, und gleichen das auf zwei Wegen aus. Der erste ist ein Vorrat: Ein Browserhersteller lädt die offengelegten Zwischenzertifikate der Web-PKI vorab in den Client; die Liste umfasst nach Angabe des Herausgebers über zweitausend Einträge (Mozilla 2020). Fehlt ein Glied im Handshake, wird es aus diesem Vorrat ergänzt, ohne dass jemand etwas bemerkt. Der Herausgeber berichtet, dass die Zahl der Handshake-Fehler wegen unbekannter Aussteller nach Einführung des Verfahrens in Firefox 68 zurückging (Mozilla 2020). Der zweite Weg ist das Nachladen über die Adresse, die im Zertifikat selbst hinterlegt ist: Der Client ruft das ausstellende Zwischenzertifikat dort ab und schließt die Lücke in eigener Regie.

Andere Clients tun beides nicht. In der Java-Laufzeitumgebung ist das Nachladen über diese Adresse aus Kompatibilitätsgründen ab Werk abgeschaltet und muss über eine Systemeigenschaft eingeschaltet werden (Oracle). Wird sie eingeschaltet, greift die nächste Sperre: Ohne gesetzte Regelliste gilt eine Alles-verbieten-Voreinstellung (Oracle). Damit bricht dieselbe Verbindung, die im Browser hält, in der Warenwirtschaft, im Zahlungsabgleich oder im nächtlichen Import ab. Die Zertifizierungsstelle benennt die fehlerhafte Kette selbst als häufigste Ursache, wenn moderne Plattformen streiken (Let’s Encrypt). Dazu kommt, dass ein Wurzelspeicher langsam altert: Der Herausgeber maß im Juli 2023, dass 93,9 Prozent der Android-Geräte seiner Wurzel vertrauten, drei Jahre zuvor waren es 66 Prozent (Let’s Encrypt).

Was das Protokoll verlangt und was das Regelwerk offen lässt

Das Protokoll ist an dieser Stelle bewusst nachsichtig formuliert. RFC 8446 empfiehlt allen Implementierungen, mit überzähligen Zertifikaten und beliebiger Reihenfolge aus jeder TLS-Fassung zurechtzukommen; verbindlich ist allein, dass das Endzertifikat zuerst steht (IETF, RFC 8446). Nachsichtig heißt aber nicht verbindlich: Eine Empfehlung verpflichtet keinen Client, und ein schlanker Prüfpfad in einem eingebetteten Gerät oder einer alten Laufzeitumgebung darf sie ausschlagen. Ähnlich verhält es sich mit dem Verweis auf das ausstellende Zwischenzertifikat im Zertifikat selbst: Im Zertifikatsprofil des Branchenregelwerks ist er als Soll-Vorgabe geführt, nicht als Pflicht (CA/Browser Forum). Wer das Nachladen als Rettungsanker einplant, plant mit einer Angabe, die fehlen darf.

Für Einrichtungen der Bundesverwaltung kommt eine weitere Ebene hinzu. Der Mindeststandard des BSI zur Verwendung von Transport Layer Security schreibt ihnen den Einsatz von TLS 1.2 und/oder TLS 1.3 vor (BSI); für Länder, Kommunen, Hochschulen und private Dienstleister ohne entsprechende Anordnung ist er eine Orientierung, keine Pflicht. Die Kettenprüfung ist Teil der Sorgfalt, die diese Vorgabe voraussetzt. Praktisch heißt das: Die Protokollfassung lässt sich in einer Konfigurationszeile nachweisen, die Vollständigkeit der Kette nicht. Sie zeigt sich erst im Handshake selbst. Wie sich Protokoll- und Verfahrensauswahl davon getrennt beobachten lassen, beschreibt der Beitrag zum Härten der TLS-Cipher-Suites.

Fünf Fehlerbilder und woran man sie erkennt

Unvollständig ist nicht gleich unvollständig. In der Praxis treten wenige, klar unterscheidbare Muster auf, die verschiedene Ursachen haben und verschiedene Reparaturen verlangen. Im Monatsscan Juni 2025 traf das auf 1.256 Auftritte zu (Qualys SSL Labs). Die Muster auseinanderzuhalten lohnt sich, weil der erste Reflex, ein neues Zertifikat ausstellen zu lassen, nur bei einem davon hilft.

Verbreitet ist das Bild, bei dem der Server ausschließlich das Blattzertifikat sendet, weil in der Konfiguration die Datei mit dem Einzelzertifikat statt der Datei mit der vollständigen Kette eingetragen ist. Beide liegen im selben Verzeichnis, beide enden auf denselben Dateisuffix, und beide führen im Browser zum gleichen grünen Ergebnis. Das zweite Bild entsteht beim Wechsel des Zwischenzertifikats: Die ausstellende Stelle betreibt inzwischen vier davon parallel, ausdrücklich mit dem Ziel, eine Festlegung auf ein einzelnes Glied zu verhindern (Web Almanac 2025). Wer das Glied fest in seine Konfiguration geschrieben hat, liefert nach dem Wechsel ein Zwischenzertifikat aus, das nicht mehr zum neuen Blatt passt.

• Nur das Blattzertifikat: die Konfiguration verweist auf das Einzelzertifikat statt auf die vollständige Kette.
• Veraltetes Zwischenzertifikat: ein fest eingetragenes Glied passt nach dem Wechsel der ausstellenden Stelle nicht mehr zum Blatt.
• Falsche Reihenfolge: das Blatt steht nicht zuerst; genau das ist der einzige Punkt, den das Protokoll zwingend vorschreibt (IETF, RFC 8446).
• Überzählige Zertifikate: abgelaufene Kreuzsignaturen bleiben in der Datei stehen und blähen den Handshake auf; der Wegfall einer Kreuzsignatur sparte über 40 Prozent der Zertifikatsbytes (Let’s Encrypt).
• Kette hinter dem Lastverteiler: die Anwendung liefert vollständig aus, die vorgelagerte Schicht terminiert TLS mit einer eigenen, unvollständigen Datei.

Das letzte Muster ist das unangenehmste, weil es die Prüfung am Ursprungsserver bestätigt und den Fehler trotzdem ausliefert. Ein Auftritt liegt hinter einem Lastverteiler, einem Zwischenspeicher oder einem vorgelagerten Dienst; die Verbindung des Besuchers endet dort, nicht am Anwendungsserver. Geprüft gehört deshalb die Adresse, die der Besucher aufruft, und zwar aus einem Netz, das nicht das eigene ist. Dieselbe Trennung gilt für API-Endpunkte, die häufig über einen anderen Hostnamen und damit über eine andere Terminierung laufen.

Die Kette selbst nachmessen

Der Nachweis kostet einen Befehl. Entscheidend ist, dass er ohne die Hilfsmittel des Browsers arbeitet: kein vorgeladener Vorrat, kein Nachladen über die Ausstelleradresse, nur der Systemspeicher und das, was der Server tatsächlich schickt. Das übliche Kommandozeilenwerkzeug gibt die gelieferten Zertifikate einzeln aus und benennt den Prüffehler im Klartext.

Zwei Angaben genügen zur Beurteilung. Erstens die Anzahl der ausgelieferten Zertifikate: Kommt genau eines zurück, während die ausstellende Stelle mit einem Zwischenzertifikat arbeitet, ist die Kette unvollständig. Zweitens die Prüfmeldung: Ein Hinweis auf einen fehlenden lokalen Aussteller ist genau der Befund, den ein Browser stillschweigend repariert. Wer keinen Zugriff auf eine Kommandozeile hat, kommt mit dem SSL-Schnelltest zum selben Ergebnis.

Die Gegenprobe gehört dazu. Derselbe Aufruf gegen einen Auftritt mit vollständiger Kette liefert zwei oder mehr Zertifikate und keine Prüfmeldung. Wer den Unterschied einmal gesehen hat, erkennt ihn danach in Sekunden. Wichtig bleibt, dass ein Ergebnis ohne Prüfmeldung nur die Kette betrifft und über den Rest der Konfiguration nichts aussagt.

Ursachen, die regelmäßig auftauchen

Hinter den Fehlerbildern stehen wenige Ursachen, und sie wiederholen sich über Branchen und Serversysteme hinweg. Ihnen ist gemeinsam, dass sie an einer Stelle entstehen, an der niemand mit einer Zertifikatsfrage rechnet: bei einer Dateiumstellung, bei einem Umzug, bei einem Skript, das seit Jahren unbeachtet läuft.

Kurze Laufzeiten machen aus dem Einzelfall einen Takt

Die Lücke wäre ein einmaliger Konfigurationsfehler, wenn Zertifikate lange gälten. Das ist vorbei. Für Zertifikate, die ab dem 15. März 2026 ausgestellt werden, sieht das Branchenregelwerk höchstens 200 Tage Laufzeit vor (CA/Browser Forum); ab dem 15. März 2027 sind es höchstens 100 Tage (CA/Browser Forum) und ab dem 15. März 2029 höchstens 47 Tage (CA/Browser Forum). Gerechnet wird dabei mit einem Tag zu exakt 86.400 Sekunden (CA/Browser Forum), sodass eine Erneuerung auf die letzte Minute den Rahmen überzieht. Plattformhersteller deckeln unabhängig davon: Serverzertifikate, die ab dem 1. September 2020 ausgestellt wurden, dürfen unter den betroffenen Systemen höchstens 398 Tage gelten (Apple 2020).

Damit wird aus dem Einzelfall ein Takt. Eine Zertifizierungsstelle bietet neben dem 90-Tage-Standard bereits Zertifikate mit sechs Tagen Gültigkeit an, die sich ohne Automatisierung nicht betreiben lassen (Let’s Encrypt). Jede Erneuerung schreibt die Kette neu, und jede Erneuerung ist damit eine Gelegenheit, ein Glied zu verlieren. Dass auch Kettenwechsel harte Stichtage haben, zeigte die Abschaltung der langen, kreuzsignierten Kette am 6. Juni 2024 (Let’s Encrypt). Was das für die Taktung der Überwachung bedeutet, führen die Beiträge zu den 6-Tage-Zertifikaten und zum 200-Tage-Limit aus.

Das eigene Zertifikat muss als erster Eintrag der Liste kommen. Jedes folgende Zertifikat soll das unmittelbar vorangehende beglaubigen.

— RFC 8446, Abschnitt 4.4.2, sinngemäß übersetzt

Wo die Kette in der Serverkonfiguration steht

In der Serverkonfiguration ist die Kette ein Dateiverweis, mehr nicht. Verbreitete Webserver erwarten eine Datei, die Blatt und Zwischenzertifikate in dieser Reihenfolge enthält; getrennte Angaben für Blatt und Kette gibt es je nach Serversoftware zusätzlich. Der häufigste Fehler ist deshalb keine falsche Syntax, sondern ein Verweis auf die Datei, die nur das Blatt enthält.

Nach jeder Änderung gilt derselbe Ablauf: Konfiguration neu einlesen, Handshake gegen die öffentliche Adresse prüfen, Zertifikate zählen. Wer den zweiten Schritt auslässt, verlässt sich auf eine Datei, die er nicht ausgeliefert gesehen hat. Bei automatisierter Ausstellung gehört der Prüfschritt in denselben Ablauf wie die Erneuerung selbst; der Beitrag zur Zertifikatsautomatisierung mit ACME beschreibt, an welcher Stelle dieser Haken sinnvoll sitzt.

# fullchain.pem enthält Blatt UND Zwischenzertifikate - cert.pem nur das Blatt
ssl_certificate     /etc/letsencrypt/live/shop.example/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/shop.example/privkey.pem;

# Apache trennt die Angaben; die Kette gehoert in SSLCertificateChainFile
# SSLCertificateFile      /etc/letsencrypt/live/shop.example/cert.pem
# SSLCertificateChainFile /etc/letsencrypt/live/shop.example/chain.pem

# Nach dem Neuladen gegenprüfen - erwartet werden mindestens 2 Zertifikate:
# openssl s_client -connect shop.example:443 -servername shop.example \
#   -showcerts </dev/null | grep -c "BEGIN CERTIFICATE"

Überwachung, die den Fehler vor dem Kunden sieht

Eine unvollständige Kette ist ein Zustand, kein Ereignis. Sie entsteht bei einer Änderung und bleibt danach bestehen, bis jemand sie bemerkt – und bemerkt wird sie erfahrungsgemäß von einem Kunden, dessen Anwendung sich nicht mehr verbindet. Eine Überwachung, die den Handshake in festem Takt aus einem fremden Netz führt und dabei die Kette vollständig auswertet, verschiebt diesen Zeitpunkt nach vorn.

• Zahl der ausgelieferten Zertifikate je Prüflauf erfassen, nicht nur den Statuscode der Seite.
• Kettenprüfung ohne Nachladehilfe führen, damit die Messung nicht repariert, was sie messen soll (Oracle).
• Restlaufzeit gestaffelt melden, weil die zulässige Laufzeit auf 200 Tage sinkt (CA/Browser Forum).
• Wechsel des Zwischenzertifikats erkennen, denn die ausstellende Stelle betreibt vier Glieder parallel (Web Almanac 2025).
• Alle Terminierungspunkte einzeln prüfen: Ursprungsserver, Lastverteiler, Zwischenspeicher, Nebenhostnamen.
• Sperrstatus über Sperrlisten führen, seit der Online-Abruf am 6. August 2025 abgeschaltet wurde (Let’s Encrypt).

Der Aufwand dafür ist gering, weil der Abruf ohnehin stattfindet. Ein Prüflauf, der die Erreichbarkeit misst, hat den Handshake bereits geführt; die Kettenprüfung ist ein Auswertungsschritt auf demselben Ergebnis. In XICTRAQ liegt das im Uptime-Monitoring und im Security-Scan, die Meldung läuft über die eingerichteten Alarmkanäle. Wer zusätzlich den Bestand an ausgestellten Zertifikaten beobachten will, findet den Weg im Beitrag zu den Certificate-Transparency-Logs.

Die Kette gehört in die laufende Überwachung

Die Kette ist der Teil von TLS, der am wenigsten Aufmerksamkeit bekommt und am leichtesten still bricht. Verschlüsselung ist dabei kein Randfall mehr: 98,8 Prozent aller mobilen Anfragen liefen im Erhebungsjahr 2025 über TLS (Web Almanac 2025), und rund 76 Prozent der erfassten Seiten sprechen TLS 1.3 (Web Almanac 2025). Je breiter die Verschlüsselung, desto breiter wirkt ein Kettenfehler – und desto häufiger trifft er nicht den Browser, sondern die Maschine dahinter.

Dazu kommt eine Konzentration, die den Hebel vergrößert: 52,6 Prozent der erfassten Seiten nutzen ein Zertifikat derselben Zertifizierungsstelle (Web Almanac 2025). Ein Wechsel ihrer Zwischenzertifikate berührt entsprechend viele Auftritte am selben Tag. Der Schluss daraus ist unspektakulär und trägt weit: Die Vollständigkeit der Kette gehört in denselben Prüflauf wie Erreichbarkeit und Restlaufzeit, sie gehört gegen die öffentliche Adresse geprüft, und sie gehört in einen Statusbericht, den jemand liest. Wie die Sperrprüfung nach dem Ende des Online-Abrufs organisiert wird, steht im Beitrag zur Zertifikatssperrung über Sperrlisten.