mezen

Hi, when you read the title, you probably already had the standard answer in your head: "Does not work with Indy, supports only OpenSSL 1.0.2 at most and thus no TLS 1.3". I can reassure you, that is not my point. Or actually even more precisely: That is exactly my point 😉 I've spent "a little" time writing the Indy support for OpenSSL 1.1.1 and TLS 1.3, and added a push request to Indy: #299. At the same time I have fixed a few issues that have been posted to GitHub (see PR). I wrote 2 new IO handlers ( one for server and one for client), the old ones are unchanged to avoid conflicts. Everything was written and tested in Delphi Berlin 10.1.2 on Win32 and Win64. I have neither macOS nor iOS nor Linux nor Android, nor FreePascal, nor older (or newer) Delphi versions. I have tried to keep older Delphi versions in mind to ensure that it will run on them, but there have been no tests on my part. I have tested it extensively in small test applications with other servers/clients. In addition, I built it into a large Real World program with TCP server/client, SMTP/IMAP/POP clients, FTP client, HTTP client, and it also ran there without problems. Unfortunately the nice man, who has provided new binary files of OpenSSL under indy.fulgan.com has said that he does not offer versions > 1.0.2 anymore. So I used the versions of slWebPro in the beginning (they even still work on WinXP), later I used the versions of Overbyte, because they do not have any external dependencies (and are digitally signed, but no XP anymore^^). But both worked without problems. All files are located in the subfolder "Lib/Protocols/OpenSSL". There are also subfolders "static" and "dynamic" which offers quite extensive imports of the OpenSSL API, once for static linking, once for dynamic loading/unloading. For dynamic loading there are also possibilities in the "IdOpenSSLLoader.pas" to trigger the loading/unloading itself, if you need the API outside of the IO handler (e.g. for your own x509 generation). To save me the double writing of the imports, I wrote a kind of intermediate code in the folder "Intermediate", which I let generate with "GenerateCode" to the two variants. The tool "GenerateCode" is only a simple string customization and actually only designed for Berlin, so I didn't bother about downward compatibility. As a normal user of the IO handlers you don't need them, only if you make changes to the API implementation. So and now comes your. It would be nice if one or the other would test this, so that it is not only WOMM certified, but can withstand more real situations. For me it also works with the Indy, which comes with Delphi Berlin, when I create another unit, which provides some new Indy types and functions. Of course some units have to be adapted locally to use the new unit.

"tlsv1 alert protocol version" means the tls handshake failed, there was no matching version. Because you have the strange EnvVar behaviour my gues would be: There is an really old OpenSSL binaries reachable with that user PATH variable BEFORE your placed dlls. If you place the correct dlls in the same directory they are found earlier. Personally, I would ship the dependancies of my application with my application within the application directory. But you could also specify a path to the OpenSSL binaries and do not rely on the users PATH variable.

I wrote on the PR a comment some days ago. tl;dr: Stopped on that PR, currently working on OpenSSL 3, will create a new PR when its done.

THTTPClient (from unit System.Net.Client) uses OS specific implementations. On Windows it uses the WinHTTP API. WinHTTP uses the Windows Certificate Store and Microsofts Trusted Root Certificate List. But it also offers the possibility to use a callback: OnValidateServerCertificate, see https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Net.HttpClient.THTTPClient.FValidateServerCertificateCallback TValidateCertificateEvent = procedure(const Sender: TObject; const ARequest: TURLRequest; const Certificate: TCertificate; var Accepted: Boolean) of object; You could use a handler, which sets Accepted always to false, except for your specific server certificate (to implement something like certificate pinning).

Nop, that pull request is still pending, just read "error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed" The last part is the interessint part, it contains the error message. By default is certificate verification active. You have two possibilites: 1.) Just ignore the verification and accept every certificate, even if it is a malicious from an attacker... MyIOHandler.Options.VerifyCertificate := False; 2.) Let OpenSSL handle certificate verification LMyIOHandler.Options.VerifyCertDirectory := 'C:\Path\To\Certificates'; { OR USE THIS ALTERNATIVE } LMyIOHandler.Options.CertFile := 'C:\Path\To\MyCertificates.pem'; 3.) Implement the certificate verification on your own procedure HandleMyCertificateVerification(Sender: TObject; const x509: TIdOpenSSLX509; const VerifyResult: Integer; const Depth: Integer; var Accepted: Boolean); begin Accepted := DoMyVerification(x509); end; LMyIOHandler.Options.OnVerify := HandleMyCertificateVerification;

The error "error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed" means your certificate verification failed. Use IoHandler.Options.VerifyServerCertificate and/or IoHandler.Options.OnVerify