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

Întrebare de la cititor: „De ce nu funcționează apelul HTTPS din clientul meu Delphi/Indy la client, deși același endpoint funcționează în browser – și în log apare doar ceva cu EIdSSL…?“

Răspuns scurt: Pentru Indy: HTTPS-Calls mit eigener CA trebuie să fie corecte simultan trei aspecte: (1) OpenSSL trebuie să fie efectiv încărcabil și compatibil în aplicația dvs., (2) negocierea TLS (versiune, cipher, traseu prin proxy) trebuie să parcurgă handshake‑ul și (3) verificarea certificatului trebuie să închidă o lanț până la un Trust Anchor de încredere. Certificate pinning adaugă deliberat o a patra barieră deasupra — și generează astfel și moduri noi de eșec.

Dacă vreți să rezolvați problema rapid, nu puteți „mixa certificatele undeva la întâmplare“. Trebuie mai întâi să identificați clasa de eroare. Atunci din EIdSSL* rezultă o sarcină concretă: remediați deployment‑ul, izolați handshake‑ul sau corectați trust‑ul/lanțul. Acest articol este conceput exact pentru asta: o abordare clară, cazuri limită tipice și indicații de depanare care funcționează în producție.

De ce „Indy: HTTPS-Calls mit eigener CA“ eșuează atât de des în proiecte

Indy realizează HTTPS tipic prin TIdSSLIOHandlerSocketOpenSSL (IOHandler pentru TLS peste OpenSSL). În practică asta înseamnă: nu Windows SChannel (Windows-TLS-Stack) decide asupra trust‑ului și compatibilității, ci OpenSSL — inclusiv logica sa proprie de trust (CA‑bundle, calea de verificare).

Din aceasta rezultă două surprize recurente:

• „Die Root-CA ist im Windows-Store“ nu este automat suficient pentru clientul dvs. Indy/OpenSSL. Trust‑ul trebuie să fie disponibil în contextul OpenSSL.
• „Im Browser geht’s“ nu reprezintă o dovadă. Browserele sunt adesea mai tolerante la detalii TLS, folosesc trust‑ul sistemului de operare și dispun de fallback‑uri bine dezvoltate.

Pe lângă acestea există realitatea rețelei corporative: Proxy, SSL-Inspection (TLS-Interception), AV/Firewall cu filtrare TLS. Atunci clientul dumneavoastră „vorbește“ de fapt nu cu serverul țintă, ci cu un sistem care termină TLS-ul și îl reconstruiește cu un certificat propriu. Pentru verificarea PKI obișnuită acest lucru poate încă funcționa (sub o Corporate-CA). Pentru Pinning, fără un design explicit, este aproape întotdeauna o ruptură severă.

Mai întâi separare, apoi rezolvare: trei clase de erori din spatele EIdSSL*

Multe Indy-Exceptions arată similar, pentru că la final apare doar „TLS kaputt“. Pentru o diagnosticare rapidă este mai important când eșuează: înainte de handshake (Library), în timpul handshake-ului (Negotiation) sau la Verify (Trust/lanț).

Regulă: Dacă SSL-Library nu se încarcă, nu există handshake. Dacă handshake-ul eșuează, trust-ul deseori nici măcar nu a fost atins corect. Și dacă trust-ul eșuează, rareori înseamnă „Indy se comportă ciudat“, ci aproape întotdeauna este o problemă de lanț, de store sau de proxy.

CA proprie: Ce așteaptă OpenSSL cu adevărat la Verify

OpenSSL verifică la TLS (simplificat) un lanț de certificate: certificat de server (Leaf) → certificat(e) intermediar(e) (Intermediate) → ancoră de încredere (Trust Anchor, de obicei Root-CA). Fără Trust Anchor rezultatul este „nicht vertrauenswürdig“ – indiferent dacă Leaf este corect din punct de vedere tehnic.^[Sursă]

Consecința practică într-o PKI privată: trebuie să furnizați în mod explicit Trust Anchor pentru aplicația dvs. În stive OpenSSL acesta este, de obicei, un CA-Bundle (fișier PEM/CRT) sau un Verify-Pfad definit. Și trebuie să înțelegeți ce trebuie să trimită serverul: Leaf plus Intermediates. Root-CA nu este, în mod normal, transmisă, ci este prezentă local ca Trust Anchor.

Pare un detaliu, dar este un punct operațional: dacă serverul nu trimite Intermediates, clientul nu poate închide lanțul – chiar dacă Root-CA este prezentă.

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

Eroarea OpenSSL-Verify 20 înseamnă: verificatorul nu găsește local un certificat emitent potrivit (Issuer) pentru a valida lanțul.^[Sursă] Cele două cauze principale sunt:

• Pe partea clientului lipsește Issuer/Trust: Root/Intermediate nu sunt disponibile în contextul de trust OpenSSL (CA-Bundle/Verify-Pfad greșit sau incomplet).
• Pe partea serverului lanțul este incomplet: un Intermediate nu este transmis sau este livrat greșit.

Ambele apar similar în jurnal, dar cer remedieri complet diferite. Exact din acest motiv eroarea 20 nu este o „Enddiagnose“, ci doar un indicator.

Der schnelle Gegencheck: Kette vom Server ansehen

Pentru o separare clară s-a impus openssl s_client -showcerts: vedeți ce certificate trimite de fapt serverul. Dacă lipsesc Intermediates, configurația serverului este primul punct de remediere. Dacă lanțul este complet, problema este mai probabil în trust-ul local (CA-Bundle/Trust Anchor) sau în calea prin proxy.^[Sursă]

Limită: s_client testează calea pe care i-o oferiți. Dacă clientul dvs. de producție trece printr-un proxy/Inspection și s_client merge direct pe Internet, nu reproduceți aceeași eroare. Atunci aveți nevoie suplimentar de o confirmare clară dacă TLS-Inspection este activă și cum arată calea prin proxy.

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

Pinning înseamnă: clientul acceptă doar un certificat așteptat sau o cheie publică așteptată (de regulă ca hash/fingerprint) pentru un host. Dacă există abateri, conexiunea este întreruptă – chiar dacă lanțul CA ar fi formal valid. Faptul că pinning constituie un caz de eroare propriu (Pin-Mismatch) este, de exemplu, documentat în definițiile de erori de rețea ale Chromium ca un caz separat.^[Sursă]

Aceasta explică și de ce Pinning poate deveni dificil în rețelele corporative: când un proxy termină TLS, clientul nu mai „vede” certificatul serverului, ci certificatul proxy-ului. Pins-urile dumneavoastră nu se potrivesc atunci — și din perspectiva Pinning nici nu ar trebui.

Când Pinning are sens

• Controlați serverele țintă și calea de actualizare a clientului (inclusiv pentru servicii fără UI).
• Planificați schimbarea certificatelor: roll-over cu cel puțin două Pins valide în paralel.
• Știți dacă apare Proxy/Inspection și aveți o decizie pentru aceasta (a susține, a o ocoli sau a nu o susține în mod intenționat).

Dacă aceste puncte nu sunt îndeplinite, Pinning deseori nu înseamnă „mai multă securitate”, ci „mai multe perturbări”, care se camuflează ca întreruperi sporadice (deoarece se manifestă abia la schimbarea certificatului sau la trecerea într-o altă rețea a clientului).

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

Numele excepțiilor sunt utile dacă le încadrați în faza corectă. Trei cazuri sunt deosebit de tipice.

„Could not load SSL library“: Deployment statt Zertifikatsdiskussion

Dacă Indy nu poate încărca bibliotecile OpenSSL, orice analiză a lanțului de certificate, CA sau Pinning este pierdere de timp. Cauze tipice:

• DLL-urile lipsesc din calea de căutare (deployment-ul serviciului este adesea mai strict decât pornirea interactivă).
• Versiunea OpenSSL nu corespunde așteptărilor Indy (compatibilitate ABI/build).
• Nepotrivire 32/64-biți sau dependențe lipsă.

Faptul că Indy necesită DLL-uri OpenSSL adecvate pentru HTTPS și altfel eșuează cu „Could not load SSL library” este confirmat frecvent în practică în jurul Indy/OpenSSL.^[Sursă] Consecință pentru operare: livrați OpenSSL ca parte versionată a aplicației dvs. (artefact CI/installer) și tratați-l ca o dependență de sistem, nu ca „este instalat undeva”.

EIdOSSLGetMethodError: TLS-Methode/Version passt nicht zur Library

Dacă în Indy forțați o metodă de protocol/versiune TLS pe care versiunea OpenSSL folosită nu o oferă, o excepție este de așteptat. Indy descrie explicit această legătură ca urmare a unei selecții de protocoale indisponibile în opțiunile SSL.^[Sursă]

Practic înseamnă: nu schimbați CA, ci verificați compatibilitatea. Ce acceptă serverul (politica)? Ce poate versiunea dvs. OpenSSL? Și există în rețeaua clientului un proxy care termină partea TLS diferit față de mediul dvs. de test?

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

Erorile de handshake nu sunt automat „încredere compromisă“. Cauzele variază de la incompatibilitate de protocol/cipher, certificate expirate sau cu nume gazdă greșit, până la interferențe prin Proxy/AV/Firewall. Această varietate este subliniată și în ghidurile generale de diagnostic.^[Sursă]

Consecință: dacă vedeți „handshake failed”, aveți nevoie mai întâi de claritate asupra traseului rețelei și a parametrilor TLS. Abia apoi are sens să abordați problema încrederii.

Exemplu construit: „Beim Kunden knallt es, bei uns nicht“

Flux de depanare: secvența de pași care închide cu adevărat tichetele

Fluxul trebuie să producă probe, nu presupuneri. Astfel, dezvoltatorii, liderii tehnici și administratorii pot lucra în paralel fără să vorbească unul pe lângă altul.

1. Fixarea contextului: Hostname/Port, mașina afectată, intervalul de timp, conexiune directă sau prin proxy, ultimele modificări (certificat/actualizare server/politica de rețea). Fără aceste fapte, discuțiile TLS sunt neproductive.
2. Eliminarea stratului de bibliotecă: La „Could not load SSL library” rezolvați mai întâi deployment-ul (DLL-urile corecte, arhitectura corectă, calea de căutare a serviciului). Abia apoi analizați handshake/încredere.
3. Faceți lanțul vizibil: rulați s_client cu „-showcerts” din rețeaua afectată. Verificați: se trimit certificate intermediare? Se potrivesc Issuer/Subject? Este certificatul valabil din punct de vedere al perioadei de valabilitate? Corespunde Hostname-ul (SAN/CN)?
4. Stabiliți modelul de trust: De unde vine trust-ul în contextul Indy/OpenSSL? Definiți CA-Bundle și procesul de întreținere (înlocuire, actualizare, rollout) în loc de „importat undeva”.
5. Izolarea problemelor de handshake: La erori Method/Protocol (de ex. EIdOSSLGetMethodError) verificați versiunile TLS/metodele în raport cu versiunea OpenSSL și politica serverului. Tratați proxy/Inspection ca variabilă — includeți sau excludeți intenționat.
6. Pinning abia după stabilitate: Abia când verificarea PKI normală funcționează corect, activați pinning. Apoi folosiți roll-over (două pini) și date de jurnal care indică în mod clar un pin-mismatch.

Verify error 19: „self-signed certificate in chain“ și capcanele tipice ale lanțului

„Self-signed certificate in chain“ (frecvent eroarea Verify 19) înseamnă: în lanțul furnizat apare un certificat auto-semnat pe care clientul nu îl acceptă ca ancoră de încredere. Ghidurile de verificare a lanțului prezintă acest lucru ca un tipic model de eroare: auto-semnat nu este automat „interzis”, dar trebuie înregistrat ca ancoră de încredere — altfel rămâne neîncredere.

Cauze tipice pe care le puteți verifica țintit:

• Se livrează un certificat intermediar greșit (de ex. PKI de test în loc de PKI de producție).
• Serverul trimite certificate care nu aparțin lanțului intenționat (Issuer/Subject nu se potrivesc clar).
• Clientul acordă „cumva” încredere unui certificat, dar nu controlat (fără o ancoră de încredere clară în contextul OpenSSL).

Consecință: tratați strict separat lanțul (serverul livrează) și trustul (clientul are încredere). Cine le amestecă ajunge rapid la soluția periculoasă „dezactivare Verify” în loc de o soluție stabilă.

Truststore vs. CA-Bundle vs. Pinning: decizii cu implicații pentru administratori

Pentru operare și administrare contează mai puțin dacă o abordare este „elegantă”, și mai mult cum se actualizează trustul, cum devin erorile reproductibile și cum funcționează rollout-urile în medii eterogene.

• OS-Truststore: Administrabil central prin GPO/MDM, potrivit pentru flote mari. Ajută însă doar dacă stack-ul TLS folosit utilizează store-ul OS (la Indy/OpenSSL nu se întâmplă automat).
• App-eigenes CA-Bundle: Reproductibil și independent de starea OS. În schimb, rotația CA trebuie integrată în procesul dvs. de release și patch.
• Pinning: Cea mai puternică legătură cu identitatea așteptată, dar sensibil la schimbări de certificate și adesea incompatibil cu TLS-Inspection.

Pentru multe configurații individuale de software enterprise, un CA-Bundle propriu al aplicației este standardul pragmatic: redă „propria CA” clar, rămâne în logica PKI și este controlabil. Pinning este atunci o măsură suplimentară planificată pentru apeluri deosebit de critice — nu default-ul pentru fiecare interfață.

Logging care ajută cu adevărat: ce date trebuie să conțină log-urile de support

„Mai multe log-uri” nu sunt de ajutor dacă tot trebuie să ghiciți. Aveți nevoie de informații care permit o decizie: fixați serverul, completați CA-Bundle-ul, clarificați traseul prin proxy sau adaptați metoda TLS.

• Obiectiv: gazdă, port, dacă se folosește hostname sau IP (SNI și validarea hostname-ului depind de asta).
• Traseu rețea: proxy da/nu (tipul, dacă este posibil), indicare privind SSL-Inspection.
• Runtime: 32/64-bit, dacă OpenSSL-Libs s-au încărcat cu succes, ce versiune OpenSSL/Indy este în deployment (informații de build).
• Verify-Daten: Verify-Code/Message (de ex. 20/19), Subject/Issuer, intervalul de valabilitate.
• Pinning (dacă este activ): identificatorul Pin așteptat și fingerprint-ul/Key-Hash determinat ca valoare hash (fără dump de certificat în log).

Astfel operațiunea poate reacționa țintit, fără ca cineva să fie nevoit „să intri rapid” remote într-o IDE. Și la probleme HTTPS cu CA privată acesta este, de regulă, diferența între o zi și o săptămână.

Următoarea dvs. prioritate: ce ar trebui să faceți mai întâi

Dacă aveți tocmai un astfel de ticket, o ordine strictă ajută mai mult decât complexitatea suplimentară:

• Prioritate 1: Stabilizați OpenSSL-Deploymentul (DLL-urile potrivite, arhitectura corectă, un traseu de livrare reproductibil). Fără asta, totul devine întâmplător.
• Prioritate 2: Curațați lanțul și trustul (serverul livrează certificatele intermediare; clientul are o ancoră de încredere clară în contextul OpenSSL, de ex. via CA-Bundle). Aceasta este baza pentru „propria CA”.
• Prioritate 3: Pinning doar ca hardening planificat (roll-over cu două pini, clarificarea realității proxy, log-uri pentru Pin-Mismatch). Nu ca prim reflex.

Dacă aveți nevoie de asistență pentru arhitectură, decizie privind trustul sau un proces de debugging robust: contactați Net-Base.

Pentru acest subiect sunt, de asemenea, importante DLL-urile OpenSSL pentru Indy și un truststore pentru CA private. Articolul plasează aceste aspecte într-un context clar și arată la ce trebuie să se acorde atenție în practică.

Discutați proiectul sau inițiativa de modernizare cu Net-Base.