![]() |
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Hallo,
das CertFile musst du dir meines Wissens separat vom Server holen. Vielleicht stellt es der Server-Besitzer (also du selbst) über einen Download-Link zur Verfügung) ... Das CetFile liegt dann also,Lokal,auf deiner Platte. |
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
So, ich hab mir das mal genauer angeguckt, wenn ich ein Cert mit dem TIdOpenSSLX509 von mir öffne (habs dafür noch ein SaveToFile und eine ctor Überladung mit einem Pfad hinzugefügt, werde das mal die Tage pushen), dann bekomme ich bei ThumbprintAsSHA1 genau das raus, was Windows einem in den Cert Details unter Thumbprint anzeigt.
Wenn das unterschiedlich zu dem alten IO Handler ist, ist dieser vllt nicht ganz korrekt gewesen? Mein IO Handler bietet einmal FIOHandler.Options.VerifyCertificate oder alternativ FIOHandler.Options.VerifyCertDirectory. Du kannst eins von beiden, oder beide gleichzeitig nutzen. Grade beim letzteren ist OpenSSL allerdings ziemlich strict was die Benamung der Dateien angeht, da musste ich auch erst tüfteln bis ich eine funktionierende Variante heraus bekommen habe. Details stehen als XML Doc Kommentar über der Property (Der Teil mit "please look at OpenSSL documentation about "openssl verify -CApath""). Die Funktion ist perfekt darauf ausgelegt, wenn als VerifyCertDirectory ein Linux Cert Store angegeben wird. |
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Habs grade nochmal mit dem alten IO Handler ausprobiert: Da bekomme ich es exakt gleiche Ergebnis bei Certificate.Fingerprints.SHA1AsString raus (Ok, mein IO Handler packt keine : da rein^^).
Allerdings steht der Default von SSLOptions.VerifyDepth auf 0, daher würde er nur das Leaf-Cert prüfen und das OnVerifyPeer gar nicht mehrmals aufrufen. Bei meinem IO Handler ist diese Option gar nicht mehr konfigurierbar und es wird der OpenSSL Standard Wert dafür genutzt (was 100 ist, siehe ![]() |
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Hallo mezen,
mit der Indy-Variante (also TIdSSLIOHandlerSocketOpenSSL) bekomme ich über Certificate.Fingerprints.SHA1AsString genau den gleichen Fingerprint wie er mir angezeigt wird, wenn ich die URL bspw. im Chrome eingebe und dann über das Schloßsysmbol auf das Zertifikat zugreife und in dem Dialog auf der Seite Details mir den Fingerprint ansehe. Die Indy-Variante funktioniert also wunschgemäß und ist auch bei unseren Kunden im produktiven Einsatz. Mit deinem IO-Handler bekomme ich über Certificate.ThumbprintAsSHA1 eine andere Bytefolge als Fingerprint angezeigt und wenn die Eingenschaft VerifyDepth bei Indy auf 0 steht und du die zur Konfiguration nicht mehr anbietest und bei dir als Standardwert 100 benutzt wird, kann dieser Unterschied ja vielleicht die Ursache sein, oder? Ich würde sehr gerne für TLS 1.3 gewappnet sein und dafür ist deine Abeit und dein IO-Handler ja super, solange Indy noch kein TLS 1.3 unterstützt, aber dann muss ich beim Einsatz deines IO-Handlers natürlich das gleiche Ergebnis bekommen, sonst kann ich ihn ja nicht einsetzen. :cry: Ich möchte noch einmal auf meine Fragen verweisen:
|
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Hallo mezen,
bzgl. des Fingerprints mache ich es mal etwas konkreter: URL im Chrome eingegeben und über das Schloßsymbol links neben der URL mir die Zertifikatseigenschaften anzign lassen. Fingerprint: f8 41 4f 2c ... Im Programm mit Indy (TIdSSLIOHandlerSocketOpenSSL) und den OpenSSL-Bibliotheken libeay32.dll und ssleay32.dll in der Version 1.0.2. Certificate.Fingerprints.SHA1AsString: F8:41:4F:2C ... (also der gleiche und erwartete Fingerprint des Zertifikats) Im Programm mit deiner Implementierung (TIdOpenSSLIOHandlerClient) und den OpenSSL-Bibliotheken libcrypto-1_1.dll und libssl-1_1.dll in der Version 1.1.1. Certificate.ThumbprintAsSHA1: 98 C6 A8 DC ... (eine andere Bytefolge :cry:) Vielleicht hilft dir das ja irgendwie weiter, damit wir zusammen zu einer zufriedenstellenden Lösung kommen. :-) |
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Sorry, kam erst jetzt wieder dazu das weiter anzuschauen.
Folgender Code jeweils mit
Delphi-Quellcode:
getestet.
HTTP1.Get('https://www.delphipraxis.net');
Alter IO Handler:
Delphi-Quellcode:
function TForm1.IdSSLIOHandlerSocketOpenSSL1VerifyPeer(Certificate: TIdX509;
AOk: Boolean; ADepth, AError: Integer): Boolean; begin mmo1.Lines.Add('Depth: ' + ADepth.ToString()); mmo1.Lines.Add('ErrorCode: ' + AError.ToString()); mmo1.Lines.Add('Subject: ' + Certificate.Subject.OneLine); mmo1.Lines.Add('Thumbprint SHA1: ' + Certificate.Fingerprints.SHA1AsString); mmo1.Lines.Add(''); Result := True; end;
Code:
Neuer IO Handler:
Depth: 0
ErrorCode: 20 Subject: /CN=*.delphipraxis.net Thumbprint SHA1: 70:B1:AC:83:99:05:36:27:75:AE:7E:ED:92:5E:0F:A8:A0:0B:D0:52 Depth: 0 ErrorCode: 21 Subject: /CN=*.delphipraxis.net Thumbprint SHA1: 70:B1:AC:83:99:05:36:27:75:AE:7E:ED:92:5E:0F:A8:A0:0B:D0:52
Delphi-Quellcode:
procedure TForm1.HandleOnVerify(Sender: TObject; const x509: TIdOpenSSLX509;
const VerifyResult, Depth: Integer; var Accepted: Boolean); begin mmo1.Lines.Add('Depth: ' + Depth.ToString()); mmo1.Lines.Add('ErrorCode: ' + VerifyResult.ToString()); mmo1.Lines.Add('Subject: ' + x509.Subject.AsString); mmo1.Lines.Add('Thumbprint SHA1: ' + x509.ThumbprintAsSHA1); mmo1.Lines.Add(''); Accepted := True; end;
Code:
Wie du siehst ist bei Depth 0 der SHA1 Thumbprint identisch.
Depth: 2
ErrorCode: 19 Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 Thumbprint SHA1: DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 Depth: 2 ErrorCode: 19 Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 Thumbprint SHA1: DF3C24F9BFD666761B268073FE06D1CC8D4F82A4 Depth: 1 ErrorCode: 19 Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte TLS RSA CA G1 Thumbprint SHA1: C9FEFC763D9548B487696F047ACBA0ABE45C7BC1 Depth: 0 ErrorCode: 19 Subject: /CN=*.delphipraxis.net Thumbprint SHA1: 70B1AC839905362775AE7EED925E0FA8A00BD052 |
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Und so sieht es aus, wenn man beim alten IO Handler mal das VerifyDepth hoch dreht:
Code:
Depth: 2
ErrorCode: 19 Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 Thumbprint SHA1: DF:3C:24:F9:BF:D6:66:76:1B:26:80:73:FE:06:D1:CC:8D:4F:82:A4 Depth: 2 ErrorCode: 19 Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2 Thumbprint SHA1: DF:3C:24:F9:BF:D6:66:76:1B:26:80:73:FE:06:D1:CC:8D:4F:82:A4 Depth: 1 ErrorCode: 19 Subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte TLS RSA CA G1 Thumbprint SHA1: C9:FE:FC:76:3D:95:48:B4:87:69:6F:04:7A:CB:A0:AB:E4:5C:7B:C1 Depth: 0 ErrorCode: 19 Subject: /CN=*.delphipraxis.net Thumbprint SHA1: 70:B1:AC:83:99:05:36:27:75:AE:7E:ED:92:5E:0F:A8:A0:0B:D0:52 |
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Hallo mezen,
ich habe deinen Test so bei mir mit meiner URL nachvollzogen und komme zu dem gleichen Ergebnis. Der erwartete Fingerprint wird bei Depth = 0 zurückgegeben. Somit können wir erst einmal feststellen, dass dein IO-Handler funktioniert. :-D Ich habe dann offensichtlich im Verify-Ereignis etwas falsch gemacht und werde das jetzt analysieren. Dabei ist dein Hinweis, dass das Verify-Ereignis durchaus mehrmals ausgelöst werden kann, sehr hilfeich. Sollte ich bei dieser Überprüfungsvariante bleiben, darf ich also den Fingerprint erst bei Depth = 0 auswerten und überprüfen. Ich bedanke mich schon einmal recht herzlich für deine Hilfe. Kannst du mir zum Abschluss bitte noch ein Code-Beispiel geben, wie ich deinen Vorschlag, die Zertifikatsüberprüfung OpenSSL zu überlassen, umsetzen kann und die Nutzung von CertFile richtig gemacht wird? |
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Weiß jemand, ob die neuen TLS Versionen auf Delphi 10.4.2 unterstützt werden?
|
AW: Indy & OpenSSL 1.1.1 & TLS 1.3
Nicht von Indy, von Komponenten wie TRestClient, der nicht auf Indy basiert schon.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:28 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz