I have an application that is outside of my normal work that I created for my Son’s business several years ago and up until now has worked flawlessly. It is an inventory tracking application which has a server and client aspect. It has clients in the office, warehouse and several vans on the road. As their vans can often be in locations where internet connectivity is unreliable, the client app is designed to work offline and then periodically (at least daily) synchronise with the server using SSL/TLS and a self signed certificate.
It is written using Delphi 2007 and Indy http components. Up until recently I have been using Indy 10.6.1 and as mentioned above has been working flawlessly for years.
My Son has added a computer in the office, a refurbished HP mini pc from Harris Technology loaded with Windows 11 Pro. The Inventory client runs fine on this but won’t communicate with the server using SSL/TLS. If I set the server and client to run in plain HTTP then it will work perfectly, but as soon as I turn SSL/TLS back on it doesn’t seem to hit the server. I know it’s not a firewall issue.
I have spent countless hours trying to fix this. Have upgraded to Indy 10.6.3 and searched for solutions online until my fingers started bleeding and in the process found some pearls that I’m sure have improved my code and method, but none which make the client on this one particular system communicate using SSL/TLS. I haven’t needed to install the certificate on any of the other client machines but I have done that on this system and that doesn’t help.
As a result, the whole Inventory system is having to run in HTTP mode which is not ideal.
I’m reluctant to tell my Son that he needs to buy a different computer and that shouldn’t be necessary anyway. It shouldn’t be this hard.
Has anyone had a similar problem and found a way to resolve it?
Are you using OpenSSL?
I’ve hit something similar (not exactly the same) and we eventually traced it back to having a later version of the OpenSSL dll’s on the path, and the app was finding these first. Indy wouldn’t work with them and due to the way the code was written it was failing silently.
From memory, Indy can’t use OpenSSL later than v1.02 (hopefully someone else can confirm my memory is correct)
Cheers
Malcolm
PS. If you can get on the same network as this machine, you can use PAServer to remotely debug it. At least that way you’ll get to see whatever exceptions get thrown.
Update: Just saw it’s Delphi 2007. I can’t remember but I don’t think PAServer was in 2007
It depends on how much time you want to spend on this problem. If you’ve already confirmed it works on other Windows 11 PC’s which the exact same build, then clean install Windows 11 on that PC. Be careful here because Windows 11 is just a product name and different builds have different SSL/TLS protocols enabled. We found very recent builds broke some other vendors http stacks. If that doesn’t work and the rest of the company is using Windows 10, you can install that on the PC instead if its the fastest solution.
Otherwise you need to look into which TLS standards are enabled on both client and server in the operating system in question and match that with the Indy options you’ve set. In Debug mode you should get an exception which will help you trace the issue.
Its really not practical to write internet/http applications with old versions of Delphi. These old versions are not secure and contain protocols that are slowly being disabled.
Yes - I too struggled with this. I finally bit the bullet and purchased Secure Bridge components. Just the ScHttpWebRequest etc component set. It fixed that and other issues with scFTP access as well. I didn’t have to do much to convert the indy code over. and it didn’t cost much. But it’s down the implementation of current ssl which indy does not support.
Alan
Hi John,
This is possibly a TLS version issue. TLS v1.0 and v1.1 have been deprecated and are disabled in Windows 11 by default (for both server and client connections). If your client/and/or server app and/or server host only accepts one of these versions then that may be the cause. The Indy components have a TLS version property that you may be able to switch to TLS v1.2 but also check the registry keys mentioned in the article below. Note that there are additional registry keys required in some cases (or you may be able to use a tool such as IISCrypto to set them).
See the following for more information:
Cheers,
Jarrod
Yes, I’m using OpenSSL with DLL version 1.0.2.21. I believe that this is the latest version of these that Indy can use.
I’m specifying TLS 1.2 which shouldn’t be a problem. All windows versions should support this as far as I know. Not sure why using Delphi 2007 makes the app less secure as I’m using the latest version of Indy.
Thanks Alan, I might have to check Secure Bridge out.
Thanks Jarrod. I’m specifying TLS 1.2 but followed the advice in the link to enable older versions of TLS in Windows 11 as a test (I’m desperate enough to try anything at this point) but it didn’t help.
Have you tried to debug it on the machine to see if you are getting an exception?
Hi Malcom,
Not yet but I should. I’ll try using the remote debugger when I get the chance.
I was also thinking about switching to using ICS on the client as a test. If that works then I’ll also consider changing the server to using ICS as I believe that supports TLS 1.3 whereas Indy doesn’t.
I have mailing list mode enabled but since my original post on this topic I don’t seem to be getting them anymore. I haven’t received any emails from this topic or anything else since.
spam folder?
Good thought but no, not there.
I have changed to using ICS 9.2 in the client instead on Indy (but left the server using Indy) and everything is working perfectly with SSL/TLS.
Thanks for everyone’s help and suggestions.