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

Pytanie czytelnika: „Dlaczego wywołanie HTTPS z mojego Delphi/Indy‑Klienta nie działa u klienta, chociaż ten sam endpoint działa w przeglądarce — i w logu jest tylko coś z EIdSSL…?“

Krótka odpowiedź: W przypadku Indy: HTTPS‑Calls mit eigener CA trzy rzeczy muszą jednocześnie pasować: (1) OpenSSL musi w Państwa aplikacji faktycznie dać się załadować i być kompatybilne, (2) negocjacja TLS (wersja, cipher, ścieżka przez proxy) musi się powieść, oraz (3) weryfikacja certyfikatu musi zbudować łańcuch aż do zaufanego Trust Anchor. Certificate‑pinning dokłada celowo czwarte warunkowanie — i przez to wprowadza dodatkowe tryby awarii.

Jeśli chcą Państwo szybko rozwiązać problem, nie wolno „gdzieś grzebać przy certyfikatach”. Najpierw trzeba trafić do klasy błędu. Wtedy z EIdSSL* robi się konkretny zakres prac: naprawa deploymentu, izolacja handshake’u albo korekta trust/łańcucha. Na to właśnie nastawiony jest ten artykuł: uporządkowane podejście, typowe przypadki brzegowe i wskazówki debugowania, które działają w produkcji.

Dlaczego „Indy: HTTPS‑Calls mit eigener CA” w projektach tak często pada

Indy zazwyczaj obsługuje HTTPS przez TIdSSLIOHandlerSocketOpenSSL (IOHandler dla TLS przy użyciu OpenSSL). W praktyce oznacza to: o zaufaniu i kompatybilności nie decyduje Windows SChannel (stert Windows‑TLS), lecz OpenSSL — wraz z własną logiką zaufania (CA‑bundle, ścieżka weryfikacji).

Stąd wynikają dwie powtarzające się niespodzianki:

• „Root‑CA jest w magazynie Windows” nie wystarcza automatycznie dla klienta Indy/OpenSSL. Zaufanie musi być dostępne w kontekście OpenSSL.
• „W przeglądarce działa” nie jest dowodem. Przeglądarki bywają w szczegółach TLS bardziej tolerancyjne, korzystają z zaufania systemu operacyjnego i mają rozbudowane mechanizmy awaryjne.

Dodatkowo istnieje rzeczywistość sieci korporacyjnej: Proxy, SSL-Inspection (TLS-Interception), AV/Firewall z filtrowaniem TLS. Wówczas klient w istocie nie „rozmawia” z serwerem docelowym, lecz z systemem, który terminuje TLS i na nowo buduje połączenie z użyciem własnego certyfikatu. Dla standardowej weryfikacji PKI może to (pod Corporate-CA) nadal pasować. Dla Pinning jest to bez świadomego zaprojektowania prawie zawsze twarde zerwanie.

Najpierw rozdzielić, potem rozwiązywać: trzy klasy błędów stojące za EIdSSL*

Wiele wyjątków Indy wygląda podobnie, ponieważ w rezultacie pojawia się jedynie „TLS zepsute”. Dla szybkiej diagnozy ważniejsze jest, kiedy to się nie udaje: przed Handshake (Library), podczas Handshake (Negotiation) lub przy Verify (Trust/łańcuch).

Zasada: Jeśli biblioteka SSL się nie ładuje, nie ma Handshake. Jeśli Handshake zawodzi, zaufanie często jeszcze nie zostało osiągnięte. A gdy Trust zawodzi, rzadko jest to „Indy wariuje”, zwykle jest to kwestia łańcucha, magazynu (Store) lub Proxy.

Własna CA: czego OpenSSL przy Verify naprawdę oczekuje

OpenSSL sprawdza przy TLS (w uproszczeniu) łańcuch certyfikatów: 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]

Dlatego też staje się jasne, dlaczego pinning w sieciach korporacyjnych może być trudny: jeśli proxy terminuję TLS, klient „widzi” już nie certyfikat serwera, lecz certyfikat proxy. Państwa piny wtedy nie pasują — i z perspektywy pinningu tak być ma.

Kiedy pinning ma sens

• Kontrolują Państwo serwery docelowe oraz ścieżkę aktualizacji klienta (także dla usług bez UI).
• Planują Państwo zmianę certyfikatów: roll-over z co najmniej dwoma jednocześnie ważnymi pinami.
• Wiedzą Państwo, czy występuje Proxy/inspekcja, i podjęli Państwo decyzję (wspierać, obejść lub świadomie nie wspierać).

Jeśli te punkty nie są spełnione, pinning często nie oznacza „więcej bezpieczeństwa”, lecz „więcej zakłóceń”, które maskują się jako sporadyczne awarie (ponieważ ujawniają się dopiero przy zmianie certyfikatu lub przy przejściu do innej sieci klienta).

Typowe błędy Indy/OpenSSL: znaczenie i pierwsze spojrzenie

Nazwy wyjątków są pomocne, jeśli przypiszą je Państwo do odpowiedniej fazy. Szczególnie typowe są trzy przypadki.

„Could not load SSL library“: Deployment zamiast dyskusji o certyfikatach

Jeśli Indy nie może załadować bibliotek OpenSSL, każda analiza łańcucha certyfikatów, CA czy pinningu to strata czasu. Typowe przyczyny:

• Brak DLL w ścieżce wyszukiwania (deploy usługi jest tutaj często bardziej restrykcyjny niż uruchomienie interaktywne).
• Wersja OpenSSL nie pasuje do oczekiwań Indy (kompatybilność ABI/build).
• Niezgodność 32/64-bit lub brakujące zależności.

To, że Indy dla HTTPS wymaga odpowiednich DLL OpenSSL i w przeciwnym razie kończy się błędem „Could not load SSL library”, jest w praktyce wokół Indy/OpenSSL regularnie potwierdzane.^[Źródło] Wniosek dla eksploatacji: dostarczajcie Państwo OpenSSL jako wersjonowany składnik Państwa aplikacji (CI-Artefakt/Installer) i traktujcie go jak zależność systemową, nie jak „coś zainstalowanego gdzieś”.

EIdOSSLGetMethodError: TLS-Methode/Version passt nicht zur Library

Jeśli w Indy wymuszą Państwo metodę protokołu/wersję TLS, której używana wersja OpenSSL nie oferuje, oczekiwany jest wyjątek. Indy opisuje ten związek wprost jako konsekwencję niedostępnego wyboru protokołu w opcjach SSL.^[Źródło]

W praktyce oznacza to: nie zmieniajcie ustawień CA, lecz sprawdźcie kompatybilność. Co akceptuje serwer (polityka)? Co potrafi Państwa wersja OpenSSL? I czy w sieci klienta znajduje się proxy, które terminuję część TLS inaczej niż Państwa środowisko testowe?

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

Błędy handshake nie oznaczają automatycznie „Trust kaputt”. Przyczyny mieszczą się od niekompatybilności protokołu/cipherów, przez wygasłe lub niezgodne z nazwą hosta certyfikaty, aż po interferencję przez proxy/AV/firewall. Ta rozpiętość jest również podkreślana w ogólnych przewodnikach diagnostycznych.^[Źródło]

Wniosek: jeśli widzą Państwo „handshake failed”, najpierw potrzebna jest jasność co do ścieżki sieciowej i parametrów TLS. Dopiero potem sensowne staje się rozstrzygnięcie kwestii zaufania.

Przykład skonstruowany: „U klienta coś wysiada, u nas nie”

Przebieg debugowania: kolejność kroków, która faktycznie zamyka zgłoszenia

Proces musi generować dowody, nie domysły. Dzięki temu deweloperzy, techniczni liderzy i administratorzy mogą pracować równolegle, nie mijając się w komunikacji.

1. Ustalić kontekst: nazwa hosta/port, dotknięta maszyna, okno czasowe, bezpośrednia trasa czy przez proxy, ostatnie zmiany (certyfikat/aktualizacja serwera/polityka sieciowa). Bez tych faktów dyskusje o TLS są nieproduktywne.
2. Wyczyścić warstwę biblioteki: Przy komunikacie „Could not load SSL library“ najpierw rozwiązać kwestie wdrożeniowe (właściwe DLL, właściwa architektura, ścieżka wyszukiwania usługi). Dopiero potem nawiązywanie połączenia (handshake) i kwestie zaufania.
3. Uczynić łańcuch widocznym: s_client z „-showcerts“ z dotkniętej sieci. Sprawdzić: Czy przesyłane są certyfikaty pośrednie? Czy pasuje Issuer/Subject? Czy certyfikat jest ważny czasowo? Czy nazwa hosta pasuje (SAN/CN)?
4. Ustalić model zaufania: Skąd pochodzi zaufanie w kontekście Indy/OpenSSL? Zdefiniować CA-Bundle i proces utrzymania (wymiana, aktualizacja, rollout) zamiast „gdzieś importować”.
5. Izolować problemy z handshake: Przy błędach metod/protokółów (np. EIdOSSLGetMethodError) sprawdzić wersje TLS/metody względem wersji OpenSSL i polityki serwera. Proxy/inspekcję traktować jako zmienną, świadomie włączając lub wyłączając.
6. Pinning dopiero po stabilności: Dopiero gdy standardowa weryfikacja PKI działa poprawnie, aktywować pinning. Wprowadzić roll-over (dwa piny) oraz logi, które jednoznacznie pokażą niezgodność pinów.

Błąd weryfikacji 19: „self-signed certificate in chain“ i typowe pułapki łańcucha

„Self-signed certificate in chain“ (często błąd weryfikacji nr 19) oznacza: w dostarczonym łańcuchu pojawia się certyfikat samo-podpisany, którego klient nie akceptuje jako zaufanego punktu odniesienia (Trust Anchor). Instrukcje dotyczące weryfikacji łańcucha opisują to jako typowy obraz błędu: certyfikat samo-podpisany nie jest automatycznie „zakazany”, ale musi być zarejestrowany jako Trust Anchor – w przeciwnym razie pozostaje niezatwierdzony.^[Quelle]

Typowe przyczyny, które można celowo sprawdzić:

• Wysyłany jest niewłaściwy certyfikat pośredni (np. Test-PKI zamiast Produkcyjnej PKI).
• Serwer przesyła certyfikaty, które nie należą do zamierzonego łańcucha (Issuer/Subject nie pasuje dokładnie).
• Klient „jakoś” ufa pewnemu certyfikatowi, ale nie w sposób kontrolowany (brak prawidłowo zdefiniowanego Trust Anchor w kontekście OpenSSL).

Konsekwencja: łańcuch (serwer dostarcza) i zaufanie (klient ufa) należy rozpatrywać ściśle oddzielnie. Kto to miesza, szybko trafia na niebezpieczne obejście polegające na wyłączeniu opcji „Verify” zamiast na stabilnym rozwiązaniu.

Truststore vs. CA-Bundle vs. Pinning: decyzje z konsekwencjami dla administratorów

Dla eksploatacji i administracji mniej istotne jest, czy podejście jest „eleganckie”, a ważniejsze to, jak aktualizowany jest trust, jak błędy można odtworzyć i jak działają rollouty w heterogenicznych środowiskach.

• OS-Truststore: centralne zarządzanie przez GPO/MDM, dobre dla dużych flot. Pomaga jednak tylko wtedy, gdy używany stos TLS korzysta z magazynu systemu operacyjnego (przy Indy/OpenSSL nie dzieje się to automatycznie).
• App-eigenes CA-Bundle: odtwarzalne i niezależne od stanu OS. Wymaga jednak uwzględnienia rotacji CA w procesie release i patchowania.
• Pinning: najsilniejsze powiązanie z oczekiwaną tożsamością, ale wrażliwe na zmiany certyfikatów i często niekompatybilne z TLS-Inspection.

Dla wielu indywidualnych środowisk oprogramowania korporacyjnego app-eigenes CA-Bundle jest pragmatycznym standardem: wiernie odwzorowuje „własną CA”, pozostaje w logice PKI i jest możliwe do opanowania. Pinning powinien być wtedy planowanym środkiem dodatkowym dla szczególnie krytycznych wywołań — nie jako domyślne rozwiązanie dla każdej integracji.

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

„Więcej logów” nic nie daje, jeśli dalej trzeba zgadywać. Potrzebne są informacje umożliwiające podjęcie decyzji: naprawić serwer, uzupełnić CA-Bundle, wyjaśnić ścieżkę przez proxy lub dostosować metodę TLS.

• Cel: host, port, czy użyto nazwy hosta czy IP (od tego zależą SNI i walidacja nazwy hosta).
• Ścieżka sieciowa: proxy tak/nie (jeśli możliwe — typ), wskazanie na SSL-Inspection.
• Runtime: 32/64-bit, czy OpenSSL-Libs zostały poprawnie załadowane, która wersja OpenSSL/Indy znajduje się w deployment (informacje buildowe).
• Verify-dane: kod/komunikat Verify (np. 20/19), Subject/Issuer, okres ważności.
• Pinning (jeśli aktywne): oczekiwany identyfikator pinu i wykryty fingerprint/key-hash jako wartość hash (bez zrzutu certyfikatu do logu).

Dzięki temu dział eksploatacji może reagować celowo, bez konieczności, by ktoś „szybko” zdalnie otwierał IDE. Przy problemach HTTPS z prywatną CA to najczęściej różnica między jednym dniem a tygodniem.

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

Jeżeli mają Państwo obecnie takie zgłoszenie, lepsza jest twarda kolejność działań niż dodatkowa złożoność:

• Priorytet 1: ustabilizować deployment OpenSSL (odpowiednie DLL, właściwa architektura, odtwarzalny sposób dostarczania). Bez tego wszystko inne to przypadek.
• Priorytet 2: uporządkować łańcuch i trust (serwer dostarcza intermediates; klient ma wyraźny Trust Anchor w kontekście OpenSSL, np. poprzez CA-Bundle). To podstawa dla „własnej CA”.
• Priorytet 3: pinning tylko jako zaplanowane wzmocnienie (roll-over z dwoma pinami, jasna rzeczywistość proxy, logi dla pin-mismatch). Nie jako pierwszy odruch.

Jeśli potrzebują Państwo wsparcia w zakresie architektury, decyzji dotyczących trustu lub rzetelnego procesu debugowania: prosimy o kontakt z Net-Base.

W tym temacie istotne są także Indy Openssl Dlls i prywatny truststore CA. Artykuł porządkuje te zagadnienia i pokazuje, na co zwracać uwagę w praktyce.

Omówić projekt lub przedsięwzięcie modernizacyjne z Net-Base.