Indy: HTTPS-Calls mit eigener CA – Zertifikat-Pinning und typische EIdSSL*-Fehler debuggen

Leserfrage: „Warum klappt der HTTPS-Call aus meinem Delphi/Indy-Client beim Kunden nicht, obwohl derselbe Endpoint im Browser funktioniert – und im Log steht nur irgendwas mit EIdSSL…?“

Kurze Antwort: Bei Indy: HTTPS-Calls mit eigener CA müssen drei Dinge gleichzeitig stimmen: (1) OpenSSL muss in Ihrer Anwendung wirklich ladbar und kompatibel sein, (2) die TLS-Aushandlung (Version, Cipher, Proxy-Pfad) muss durchlaufen und (3) die Zertifikatsprüfung muss eine Kette bis zu einem vertrauenswürdigen Trust Anchor schließen. Zertifikat-Pinning setzt danach bewusst noch eine vierte Hürde oben drauf – und erzeugt dadurch auch neue Ausfallmodi.

Wenn Sie das Problem schnell lösen wollen, dürfen Sie nicht „irgendwo an Zertifikaten drehen“. Sie müssen zuerst die Fehlerklasse treffen. Dann wird aus EIdSSL* ein konkreter Arbeitsauftrag: Deployment fixen, Handshake isolieren oder Trust/Kette korrigieren. Genau darauf ist dieser Beitrag ausgelegt: sauberer Ansatz, typische Randfälle und Debugging-Hinweise, die im Betrieb funktionieren.

Warum „Indy: HTTPS-Calls mit eigener CA“ in Projekten so oft kippt

Indy macht HTTPS typischerweise über TIdSSLIOHandlerSocketOpenSSL (IOHandler für TLS über OpenSSL). Das bedeutet praktisch: Nicht Windows SChannel (der Windows-TLS-Stack) entscheidet über Trust und Kompatibilität, sondern OpenSSL – inklusive eigener Trust-Logik (CA-Bundle, Verify-Pfad).

Daraus kommen zwei wiederkehrende Überraschungen:

• „Die Root-CA ist im Windows-Store“ reicht Ihrem Indy/OpenSSL-Client nicht automatisch. Der Trust muss im OpenSSL-Kontext verfügbar sein.
• „Im Browser geht’s“ ist kein Beweis. Browser sind bei TLS-Details oft toleranter, nutzen OS-Trust und haben ausgereifte Fallbacks.

Zusätzlich gibt es die Unternehmensnetz-Realität: Proxy, SSL-Inspection (TLS-Interception), AV/Firewall mit TLS-Filterung. Dann „spricht“ Ihr Client nicht wirklich mit dem Zielserver, sondern mit einem System, das TLS terminiert und mit einem eigenen Zertifikat neu aufbaut. Für normale PKI-Prüfung kann das (unter einer Corporate-CA) noch passen. Für Pinning ist es ohne explizites Design fast immer ein harter Bruch.

Erst trennen, dann lösen: drei Fehlerklassen hinter EIdSSL*

Viele Indy-Exceptions sehen ähnlich aus, weil am Ende nur „TLS kaputt“ ankommt. Für eine schnelle Diagnose ist wichtiger, wann es scheitert: vor dem Handshake (Library), während des Handshakes (Negotiation) oder beim Verify (Trust/Kette).

Merksatz: Wenn die SSL-Library nicht lädt, gibt es keinen Handshake. Wenn der Handshake scheitert, ist Trust oft noch gar nicht sauber erreicht. Und wenn Trust scheitert, ist es selten „Indy spinnt“, sondern fast immer eine Ketten-, Store- oder Proxy-Frage.

Eigene CA: Was OpenSSL beim Verify wirklich erwartet

OpenSSL prüft bei TLS (vereinfacht) eine Zertifikatskette: Serverzertifikat (Leaf) → Zwischenzertifikat(e) (Intermediate) → vertrauenswürdiger Anker (Trust Anchor, meist Root-CA). Ohne Trust Anchor ist das Ergebnis „nicht vertrauenswürdig“ – unabhängig davon, ob das Leaf technisch korrekt ist.^[Quelle]

Praktische Konsequenz bei privater PKI: Sie müssen den Trust Anchor für Ihre Anwendung gezielt bereitstellen. In OpenSSL-Stacks ist das typischerweise ein CA-Bundle (PEM/CRT-Datei) oder ein definierter Verify-Pfad. Und Sie müssen verstehen, was der Server liefern muss: Leaf plus Intermediates. Die Root-CA wird normalerweise nicht mitgesendet, sondern ist lokal als Trust Anchor vorhanden.

Das klingt nach Detail, ist aber ein Betriebspunkt: Wenn der Server die Intermediates nicht mitsendet, kann der Client die Kette nicht schließen – selbst wenn die Root-CA vorhanden ist.

Verify error 20: „unable to get local issuer certificate“ ist fast immer Kette oder Trust

OpenSSL-Verify-Fehler 20 bedeutet: Der Prüfer findet lokal kein passendes Ausstellerzertifikat (Issuer), um die Kette zu verifizieren.^[Quelle] Die zwei Hauptursachen sind:

• Client-seitig fehlt Issuer/Trust: Root/Intermediate sind im OpenSSL-Trust-Kontext nicht verfügbar (CA-Bundle/Verify-Pfad falsch oder unvollständig).
• Server-seitig ist die Kette unvollständig: Ein Intermediate wird nicht mitgesendet oder falsch geliefert.

Beides sieht im Log ähnlich aus, ist aber ein komplett anderer Fix. Genau deshalb ist Fehler 20 keine „Enddiagnose“, sondern nur ein Wegweiser.

Der schnelle Gegencheck: Kette vom Server ansehen

Für die saubere Trennung hat sich openssl s_client -showcerts etabliert: Sie sehen, welche Zertifikate der Server tatsächlich sendet. Fehlen Intermediates, ist die Serverkonfiguration der erste Fixpunkt. Ist die Kette vollständig, liegt es wahrscheinlicher am lokalen Trust (CA-Bundle/Trust Anchor) oder am Proxy-Pfad.^[Quelle]

Grenze: s_client testet den Pfad, den Sie ihm geben. Wenn Ihr Produktivclient durch einen Proxy/Inspection muss und s_client direkt ins Internet geht, testen Sie nicht denselben Fehler. Dann brauchen Sie zusätzlich eine klare Antwort, ob TLS-Inspection aktiv ist und wie der Proxy-Pfad aussieht.

Zertifikat-Pinning: zusätzlicher Schutz, zusätzlicher Ausfallmodus

Pinning heißt: Der Client akzeptiert nur ein erwartetes Zertifikat oder einen erwarteten Public Key (meist als Hash/Fingerprint) für einen Host. Weicht das ab, wird abgebrochen – auch wenn die CA-Kette formal gültig wäre. Dass Pinning einen eigenen Fehlerfall (Pin-Mismatch) darstellt, ist z. B. in den Netzwerk-Fehlerdefinitionen von Chromium als eigener Fall dokumentiert.^[Quelle]

Damit ist auch klar, warum Pinning in Unternehmensnetzen schwer werden kann: Wenn ein Proxy TLS terminiert, „sieht“ der Client nicht mehr das Serverzertifikat, sondern das Proxy-Zertifikat. Ihre Pins passen dann nicht – und sollen es aus Sicht von Pinning auch nicht.

Wann Pinning Sinn ergibt

• Sie kontrollieren Zielserver und Client-Updateweg (auch für Services ohne UI).
• Sie planen Zertifikatswechsel: Roll-over mit mindestens zwei gültigen Pins parallel.
• Sie wissen, ob Proxy/Inspection vorkommt, und haben dafür eine Entscheidung (unterstützen, umgehen, oder bewusst nicht unterstützen).

Wenn diese Punkte nicht erfüllt sind, ist Pinning oft nicht „mehr Sicherheit“, sondern „mehr Störung“, die sich als sporadische Ausfälle tarnt (weil sie erst beim Zertifikatswechsel oder beim Wechsel in ein anderes Kundennetz zuschlägt).

Typische Indy-/OpenSSL-Fehler: Bedeutung und erster Blick

Die Namen der Exceptions sind hilfreich, wenn Sie sie in die richtige Phase einordnen. Drei Fälle sind besonders typisch.

„Could not load SSL library“: Deployment statt Zertifikatsdiskussion

Wenn Indy die OpenSSL-Libs nicht laden kann, ist jede Analyse von Zertifikatskette, CA oder Pinning Zeitverlust. Typische Ursachen:

• DLLs fehlen im Suchpfad (Service-Deployment ist hier oft strenger als interaktiver Start).
• OpenSSL-Version passt nicht zur Indy-Erwartung (ABI/Build-Kompatibilität).
• 32/64-Bit-Mismatch oder fehlende Abhängigkeiten.

Dass Indy für HTTPS passende OpenSSL-DLLs voraussetzt und sonst mit „Could not load SSL library“ scheitert, wird in der Praxis rund um Indy/OpenSSL regelmäßig bestätigt.^[Quelle] Folgerung für Betrieb: Liefern Sie OpenSSL als versionierten Bestandteil Ihrer Anwendung aus (CI-Artefakt/Installer) und behandeln Sie es wie eine Systemabhängigkeit, nicht wie „ist irgendwo installiert“.

EIdOSSLGetMethodError: TLS-Methode/Version passt nicht zur Library

Wenn Sie in Indy eine Protokollmethode/TLS-Version erzwingen, die die eingesetzte OpenSSL-Version nicht anbietet, ist eine Exception erwartbar. Indy beschreibt diesen Zusammenhang explizit als Folge einer nicht verfügbaren Protokollauswahl in den SSL-Optionen.^[Quelle]

Praktisch bedeutet das: Nicht an der CA drehen, sondern Kompatibilität prüfen. Was akzeptiert der Server (Policy)? Was kann Ihre OpenSSL-Version? Und gibt es im Kundennetz einen Proxy, der den TLS-Teil anders terminiert als Ihre Testumgebung?

„SSL handshake failed“: Sammelbecken, in dem Proxies gern verschwinden

Handshake-Fehler sind nicht automatisch „Trust kaputt“. Ursachen reichen von Protokoll-/Cipher-Inkompatibilität über abgelaufene/hostnamenfalsche Zertifikate bis zu Interferenz durch Proxy/AV/Firewall. Diese Breite wird auch in allgemeinen Diagnoseleitfäden betont.^[Quelle]

Folgerung: Wenn Sie „handshake failed“ sehen, brauchen Sie zuerst Klarheit über Netzpfad und TLS-Parameter. Erst dann ist die Trust-Frage sinnvoll zu beantworten.

Konstruiertes Beispiel: „Beim Kunden knallt es, bei uns nicht“

Debugging-Ablauf: Schrittfolge, die Tickets wirklich schließt

Der Ablauf muss Belege produzieren, nicht Vermutungen. Damit können Entwickler, technische Leads und Admins parallel arbeiten, ohne aneinander vorbeizureden.

1. Kontext fixieren: Hostname/Port, betroffene Maschine, Zeitfenster, direkter Weg oder Proxy, letzte Änderungen (Zertifikat/Serverupdate/Netzpolicy). Ohne diese Fakten sind TLS-Diskussionen unproduktiv.
2. Library-Layer abräumen: Bei „Could not load SSL library“ zuerst Deployment lösen (richtige DLLs, richtige Architektur, Service-Suchpfad). Erst danach Handshake/Trust.
3. Kette sichtbar machen: s_client mit „-showcerts“ aus dem betroffenen Netz. Prüfen: Werden Intermediates mitgesendet? Passt Issuer/Subject? Ist das Zertifikat zeitlich gültig? Passt Hostname (SAN/CN)?
4. Trust-Modell festlegen: Woher kommt Trust im Indy/OpenSSL-Kontext? CA-Bundle und Pflegeprozess definieren (Austausch, Update, Rollout) statt „irgendwo importieren“.
5. Handshake-Probleme isolieren: Bei Method/Protocol-Errors (z. B. EIdOSSLGetMethodError) TLS-Versionen/Methoden gegen OpenSSL-Version und Serverpolicy prüfen. Proxy/Inspection als Variable bewusst ein- oder ausschließen.
6. Pinning erst nach Stabilität: Erst wenn normale PKI-Prüfung sauber läuft, Pinning aktivieren. Dann mit Roll-over (zwei Pins) und Logdaten, die Pin-Mismatch eindeutig zeigen.

Verify error 19: „self-signed certificate in chain“ und die typischen Ketten-Fallen

„Self-signed certificate in chain“ (häufig Verify-Fehler 19) bedeutet: In der gelieferten Kette taucht ein selbstsigniertes Zertifikat auf, das der Client nicht als vertrauenswürdigen Anchor akzeptiert. Chain-Verify-Anleitungen führen das als typisches Fehlerbild: Selbstsigniert ist nicht automatisch „verboten“, aber es muss als Trust Anchor hinterlegt sein – sonst bleibt es untrusted.^[Quelle]

Typische Ursachen, die Sie gezielt abprüfen können:

• Es wird ein falsches Intermediate ausgeliefert (z. B. Test-PKI statt Produktiv-PKI).
• Der Server schickt Zertifikate, die nicht zur beabsichtigten Kette gehören (Issuer/Subject passt nicht sauber).
• Der Client vertraut „irgendwie“ einem Zertifikat, aber nicht kontrolliert (kein sauberer Trust Anchor im OpenSSL-Kontext).

Konsequenz: Kette (Server liefert) und Trust (Client vertraut) strikt getrennt betrachten. Wer das vermischt, landet schnell beim gefährlichen Workaround „Verify aus“ statt bei einer stabilen Lösung.

Truststore vs. CA-Bundle vs. Pinning: Entscheidungen mit Admin-Folgen

Für Betrieb und Administration ist weniger entscheidend, ob ein Ansatz „elegant“ ist, sondern wie Trust aktualisiert wird, wie Fehler reproduzierbar werden und wie Rollouts in heterogenen Umgebungen funktionieren.

• OS-Truststore: Zentral via GPO/MDM verwaltbar, gut für große Flotten. Hilft aber nur, wenn der verwendete TLS-Stack den OS-Store nutzt (bei Indy/OpenSSL nicht automatisch).
• App-eigenes CA-Bundle: Reproduzierbar und unabhängig vom OS-Zustand. Dafür muss CA-Rotation in Ihren Release- und Patchprozess.
• Pinning: Stärkste Bindung an erwartete Identität, aber empfindlich bei Zertifikatswechseln und oft inkompatibel mit TLS-Inspection.

Für viele individuelle Unternehmenssoftware-Setups ist ein app-eigenes CA-Bundle der pragmatische Standard: Es bildet „eigene CA“ sauber ab, bleibt in der PKI-Logik und ist beherrschbar. Pinning ist dann eine gezielte Zusatzmaßnahme für besonders kritische Calls – nicht der Default für jede Schnittstelle.

Logging, das wirklich hilft: Welche Daten in Support-Logs gehören

„Mehr Logs“ bringen nichts, wenn Sie danach immer noch raten. Was Sie brauchen, sind Informationen, die eine Entscheidung ermöglichen: Server fixen, CA-Bundle ergänzen, Proxy-Pfad klären oder TLS-Methode anpassen.

• Ziel: Host, Port, ob Hostname oder IP genutzt wird (SNI und Hostname-Validierung hängen daran).
• Netzpfad: Proxy ja/nein (Typ wenn möglich), Hinweis auf SSL-Inspection.
• Runtime: 32/64-bit, ob OpenSSL-Libs erfolgreich geladen wurden, welche OpenSSL-/Indy-Version im Deployment steckt (Build-Info).
• Verify-Daten: Verify-Code/Message (z. B. 20/19), Subject/Issuer, Gültigkeitszeitraum.
• Pinning (falls aktiv): erwarteter Pin-Identifier und ermittelter Fingerprint/Key-Hash als Hashwert (kein Zertifikatsdump ins Log).

Damit kann der Betrieb gezielt reagieren, ohne dass jemand „mal schnell“ remote in eine IDE muss. Und das ist bei HTTPS-Problemen mit privater CA meistens der Unterschied zwischen einem Tag und einer Woche.

Ihre nächste Priorität: Was Sie jetzt zuerst tun sollten

Wenn Sie gerade so ein Ticket haben, hilft eine harte Reihenfolge mehr als zusätzliche Komplexität:

• Priorität 1: OpenSSL-Deployment stabilisieren (passende DLLs, richtige Architektur, reproduzierbarer Auslieferungsweg). Ohne das ist alles Weitere Zufall.
• Priorität 2: Kette und Trust sauber machen (Server liefert Intermediates; Client hat einen klaren Trust Anchor im OpenSSL-Kontext, z. B. via CA-Bundle). Das ist die Basis für „eigene CA“.
• Priorität 3: Pinning nur als geplantes Hardening (Roll-over mit zwei Pins, Proxy-Realität geklärt, Logs für Pin-Mismatch). Nicht als erster Reflex.

Wenn Sie dabei Unterstützung für Architektur, Trust-Entscheidung oder einen belastbaren Debugging-Prozess brauchen: Kontakt mit Net-Base aufnehmen.

Für dieses Thema sind auch Indy Openssl Dlls und Private Ca Truststore wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.