{"id":13568,"date":"2026-10-15T13:00:00","date_gmt":"2026-10-15T11:00:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13568"},"modified":"2026-10-09T23:06:14","modified_gmt":"2026-10-09T21:06:14","slug":"zertifikatsketten-warum-eine-seite-im-browser-aufgeht-und-in-curl-scheitert","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/it-networks-de\/tutorials-de-it-networks-de\/zertifikatsketten-warum-eine-seite-im-browser-aufgeht-und-in-curl-scheitert\/","title":{"rendered":"Zertifikatsketten: Warum eine Seite im Browser aufgeht und in curl scheitert"},"content":{"rendered":"

Ein TLS-Handshake sieht aus wie ein einziges Ja oder Nein. Tats\u00e4chlich ist er ein kleiner Beweis: Der Server legt ein Zertifikat vor, und der Client muss daraus einen Pfad zu einer Wurzel bauen, der er ohnehin vertraut. Der Beweis gelingt oder nicht, und die Antwort h\u00e4ngt davon ab, wer fragt.<\/p>\n

Genau das \u00fcberrascht. Derselbe Server kann in derselben Sekunde von Chrome anerkannt und von curl abgewiesen werden.<\/p>\n

\n\"Eine
Eine unvollst\u00e4ndige Kette, zwei Urteile – der Unterschied ist ein Abruf, den nur einer von beiden macht.<\/figcaption><\/figure>\n

Was im Handshake \u00fcbertragen wird<\/h2>\n

Der Server sendet sein eigenes Zertifikat, das Blatt, und normalerweise ein oder zwei dar\u00fcber. Das Blatt tr\u00e4gt die Hostnamen, f\u00fcr die es gilt, einen \u00f6ffentlichen Schl\u00fcssel und eine Signatur. Diese Signatur stammt nicht von der Wurzel, sondern von einem Zwischenzertifikat, das seinerseits von der Wurzel signiert wurde.<\/p>\n

Die Wurzel selbst wird nie gesendet. Im Vertrauensspeicher des Betriebssystems oder des Browsers liegen einige Hundert davon, und sie sind der einzige Teil, den der Client schon hat.<\/p>\n

Der Client braucht also alles zwischen dem Blatt und dieser Wurzel. Sendet der Server das Zwischenzertifikat nicht, entsteht eine L\u00fccke, und eine L\u00fccke hei\u00dft: kein Beweis.<\/p>\n

Das Glied, das verloren geht<\/h2>\n

Fast jede Zertifizierungsstelle liefert zwei Dateien: das Zertifikat selbst und ein B\u00fcndel aus Zertifikat und Zwischenzertifikat. Bei Let’s Encrypt hei\u00dfen sie cert.pem<\/code> und fullchain.pem<\/code>. Die Namen sind keine Zierde.<\/p>\n

cert.pem<\/code> dort einzutragen, wo fullchain.pem<\/code> hingeh\u00f6rt, ist die h\u00e4ufigste TLS-Fehlkonfiguration \u00fcberhaupt, und der Grund liegt auf der Hand: Die Seite geht danach einwandfrei auf. Nichts warnt, nichts protokolliert, und das Zertifikat ist tats\u00e4chlich g\u00fcltig.<\/p>\n

Die L\u00fccke besteht nur f\u00fcr Clients, die sich weigern, sie selbst zu schlie\u00dfen.<\/p>\n

Warum der Browser verzeiht<\/h2>\n

In einem Zertifikat steckt ein Feld namens Authority Information Access. Darin steht unter anderem eine Adresse: die Stelle, an der sich das ausstellende Zwischenzertifikat herunterladen l\u00e4sst. Browser nutzen sie. Fehlt der Kette ein Glied, holen sie das fehlende Zertifikat von dieser Adresse, vervollst\u00e4ndigen den Pfad und zeigen das Schloss.<\/p>\n

Manche Browser speichern zus\u00e4tzlich Zwischenzertifikate, die sie auf anderen Seiten gesehen haben. Dadurch ist das Problem schwerer nachzustellen: Ein Server mit unvollst\u00e4ndiger Zertifikatskette kann auf zwei Rechnern korrekt zu funktionieren scheinen, aber auf jedem aus einem anderen Grund.<\/p>\n

curl, OpenSSL und die meisten HTTP-Bibliotheken in Python, PHP, Go und Java tun das nicht. Diese Clients lesen dasselbe Feld und \u00fcbergehen es, denn ihm zu folgen macht aus einem Handshake zwei Netzuml\u00e4ufe und h\u00e4ngt mitten in eine Verbindung, die direkt sein soll, die Abh\u00e4ngigkeit von einem fremden Host. Die Weigerung ist Absicht.<\/p>\n

Daraus entsteht ein Fehlerbild mit sehr klarer Form: Die Website funktioniert, der Verkehr zwischen Maschinen nicht. Ein Zahlungsdienstleister, der einen Webhook aufruft, eine \u00dcberwachungssonde, eine App, ein Partner, der eine API abfragt – alle melden unable to get local issuer certificate<\/code>, w\u00e4hrend der Browser \u00fcberhaupt nichts anzeigt.<\/p>\n

\n\"Zwei
\n<\/figure>\n

Was zw\u00f6lf Seiten wirklich senden<\/h2>\n

Zw\u00f6lf bekannte Adressen wurden am 2. September 2026 gemessen, gelesen wurde allein, was der Server im Handshake anbot.<\/p>\n

Sechs sendeten drei Zertifikate, sechs vier. Keine einzige sendete das Blatt allein. Die Laufzeit war bei allen zw\u00f6lf gleich: 90 Tage, wie sie die automatisierten Aussteller vergeben und worauf sich die Branche eingependelt hat. Die Restg\u00fcltigkeit lag zwischen 31 und 88 Tagen, im Mittel bei 70 – die Streuung, die eine automatische Erneuerung bei zwei Dritteln der Laufzeit erzeugt.<\/p>\n

Elf der zw\u00f6lf handelten TLS 1.3 aus, eine blieb bei 1.2. Keine nahm TLS 1.0 an. Neun verwendeten einen ECDSA-Schl\u00fcssel statt RSA. Acht Zertifikate kamen von Let’s Encrypt, drei von Google Trust Services, eines von Sectigo.<\/p>\n

Weit st\u00e4rker als alles andere schwankte die Zahl der Namen im Zertifikat: einer am unteren Ende, 41 bei wikipedia.org. Diese Zahl ist kein G\u00fctezeichen, sondern nur ein Hinweis darauf, wie der Bestand organisiert ist.<\/p>\n

Namen, nicht der Common Name<\/h2>\n

Ein zweiter Fehler sieht von au\u00dfen \u00e4hnlich aus. Das Zertifikat ist vollst\u00e4ndig und g\u00fcltig, nur steht der Host nicht darin.<\/p>\n

Aktuelle Browser ignorieren den Common Name vollst\u00e4ndig und vergleichen ausschlie\u00dflich die Subject Alternative Names. Ein Zertifikat f\u00fcr example.com<\/code>, in dem www.example.com<\/code> fehlt, deckt genau eine der beiden Adressen ab, und die Weiterleitung zwischen ihnen scheitert, bevor sie beginnt.<\/p>\n

Platzhalter decken eine Ebene und keine weitere. *.example.com<\/code> passt auf www.example.com<\/code>, aber weder auf example.com<\/code> selbst noch auf a.b.example.com<\/code>. Beide H\u00e4lften dieses Satzes kosten regelm\u00e4\u00dfig jemanden einen Ausfall.<\/p>\n

Lesen ohne Browser<\/h2>\n

Der Unterschied, auf den es ankommt, ist im Browser nicht zu sehen, gerade weil der Browser ihn repariert. N\u00f6tig ist ein Client, der das nicht tut.<\/p>\n

openssl s_client -connect example.com:443 -servername example.com < \/dev\/null\ncurl -vI https:\/\/example.com\/<\/code><\/pre>\n
In der Ausgabe von OpenSSL listet der Block zur Zertifikatskette auf, was der Server gesendet hat. Ein einziger Eintrag hei\u00dft: Das Zwischenzertifikat fehlt, unabh\u00e4ngig davon, ob die Pr\u00fcfzeile darunter ok meldet – ein lokal zwischengespeichertes Zwischenzertifikat kann auch sie irref\u00fchrend machen. Verl\u00e4sslich ist das Z\u00e4hlen dessen, was ankam.<\/p>\n
Dieselbe Lesart ohne Kommandozeile liefert der TLS-Zertifikat- und Handshake-Inspector<\/a> in der Toolbox: Er \u00f6ffnet den Handshake, verifiziert einmal mit dem Vertrauensspeicher und einmal ohne, listet die Kette genau so auf, wie der Server sie gesendet hat, und probiert danach jede TLS-Version einzeln. Die L\u00fccke erscheint als Kette der L\u00e4nge eins, daneben eine Verifikation, die aus einem lesenswerten Grund gescheitert ist.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Geh\u00f6rt das Wurzelzertifikat mit in die Kette, die der Server sendet?<\/h3>\n
Nein. Der Client muss der Wurzel ohnehin schon vertrauen, eine mitgeschickte Wurzel beweist also nichts und kostet bei jedem Handshake nur Bytes; RFC 8446 erlaubt ausdr\u00fccklich, sie wegzulassen. Entscheidend ist allein, dass jedes Zwischenzertifikat zwischen Blatt und Wurzel dabei ist, und genau das enth\u00e4lt fullchain.pem.<\/p>\n
Die Kette lief monatelang, pl\u00f6tzlich meldet ein Webhook-Absender unable to get local issuer certificate. Woran kann das liegen?<\/h3>\n
Wenn am Server nichts ge\u00e4ndert wurde, kommen vor allem zwei Ursachen in Frage, eine auf jeder Seite der Verbindung:<\/p>\n
    \n
  1. Das Zwischenzertifikat hat gewechselt. Zertifizierungsstellen stellen von Zeit zu Zeit \u00fcber neue Zwischenzertifikate aus. Eine Konfiguration, die cert.pem mit einer einmal von Hand abgelegten Zwischendatei kombiniert, schickt nach der n\u00e4chsten Erneuerung ein Glied, das nicht mehr zum Blatt passt; der Pfad hat dann dieselbe L\u00fccke wie ganz ohne Zwischenzertifikat. fullchain.pem wird bei jeder Erneuerung mit dem passenden Zwischenzertifikat neu geschrieben und hat dieses Problem nicht.<\/li>\n
  2. Der Vertrauensspeicher des Clients ist veraltet. Endet die Kette nach einer Erneuerung bei einer anderen Wurzel, fehlt diese wom\u00f6glich in alten Betriebssystemen oder in Container-Images, die lange nicht neu gebaut wurden. Die Meldung ist dieselbe, obwohl der Server alles richtig sendet.<\/li>\n<\/ol>\n
    Welche der beiden zutrifft, kl\u00e4rt erneutes Z\u00e4hlen: Kommen bei openssl s_client Blatt und Zwischenzertifikat an und verifiziert ein aktuelles System die Kette, liegt das Problem im Vertrauensspeicher des Absenders, und helfen kann nur ein Update seiner CA-Liste.<\/p>\n<\/div>\n
    \n
    Quellen<\/h2>\n