SSL Error 1407742

[Brian Warner 0]

Running Windows 10/11 Pro, 64-bit, 64-bit application. Delphi 11. GetIt is down, so I can't get exact Indy version but the bpls are *280.

 

As my program starts, it checks the windows path and, if necessary, adds \AROOT\PROGRAMS\ to the path using Get/SetEnvironmentVariable. I've confirmed that the path statement has been altered. In that directory are the two SLL dlls, libeay32.dll and ssleay32.dll (v1.0.22.1). Whenever any program needing FTP or HTTPS under the \AROOT\PROGRAMS runs, it does this check. All of them work fine, i.e., they can do their Internet things. There are no instances of the dlls within the modified Windows PATH.

 

In other words, everything is fine -until- a user tries, or at least this particular one. With the same setup, save using Windows HOME, when he tries to do an https GET, the attached error message is returned. If he puts the program in the same directory as the two dlls, then it works. 

 

I know it's ill-advised to put the dlls somewhere under windows, e.g., SYSTEM32, and it's not practical to have the pair in every directory with a program needing them. Any thoughts on what might solve the problem? I've put enough dents in the wall beating my head today.

 

Brian D. Warner

 

 

 

[mezen 13]

"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.

[Remy Lebeau 1260]

8 hours ago, Brian Warner said:

GetIt is down, so I can't get exact Indy version

Indy is not in GetIt. It is preinstalled with Delphi itself.

8 hours ago, Brian Warner said:

 As  my program starts, it checks the windows path and, if necessary, adds \AROOT\PROGRAMS\ to the path using Get/SetEnvironmentVariable.

That is not the correct approach to take. If you need to control where the DLLs are loaded from at runtime, you should be using the Win32 SetDllDirectory() or AddDllDirectory() function instead.  Or, you can also use Indy's IdOpenSSLSetLibPath() function.

 

In any case, whether you use SetEnvironmentVariable() or (Set|Add)DllDirectory(), this API-based path update only affects the calling process, not the user/system as a whole. So, any app not running in your folder will need to do the same API update for itself to look for the DLLs in your folder.  Unless you manually update the user/system config directly. 

8 hours ago, Brian Warner said:

it's not practical to have the pair in every directory with a program needing them.

That's exactly how they are intended to be used, and should be used. Unless you have a group of related apps that need to use the same version of the DLLs, then they can be shared in a folder that all of the apps agree on.

8 hours ago, Brian Warner said:

Any thoughts on what might solve the problem?

My guess is either:

 

- there is another version of the DLLs present on the system, which is not compatible with the server in question, and the failing app is finding those DLLs instead of the ones you want. You should have the app log out the full paths of the DLLs it actually loaded into memory (not the paths it thinks it loaded).

 

- the failing app is not configuring the DLLs properly to work with the server in question.

 

There is not enough information provided to diagnose your problem one way or another.  We need to see your ACTUAL setup, and your ACTUAL code.

Edited January 18 by Remy Lebeau