Xojo.Net.HttpSocket Fails with some URLs in Web App

We have new and old Xojo web executables built with Xojo 2019R3.2 (Framework 1) and Xojo 2021R2.1, respectively. They have been running unaltered for months on a dedicated server. Recently, the Xojo.Net.HttpSocket component quit working when sending HttpGet and HttpPost commands under specific conditions in both new and old executables.

After running hundred of tests, working with our hosting company for days, rebuilding our SSL certificate and testing the OLD and NEW executables on a different server, here is a summary of the problem.

The old executables can still communicate fine with some external servers, but always fail to communicate with other external servers. The HttpGet and HttpPost commands always fail with no error reported when attempting to run a local PHP file using a URL that uses http, https and the domain name or the IP address directly. The same results occur when running this old executable on a different server. I have found no work-around.

The new executables can still communicate with all external servers I have tested. Running a local PHP file on the same server using the direct IP address works OK. When using http or https URL that includes the domain name of the local server, the error message “Unacceptable TLS Certificate” is returned. The SSL certificate has been verified to be fine and even regenerated. There are multiple domains that point at this server and when any domain name is used in the URL of a local file, the same error occurs.

The PHP curl command can run local PHP files using http, https with a domain name or IP in the URL. The problem appears to be narrowing focused to something within the implementation of the Xojo.Net.HttpSocket component.

Any suggestions?

Is the client using TLS/1.0? Many servers that use OpenSSL are configured to reject TLS/1.0 connections(due to the “Heartbleed” bug). This caused problems for the old HTTPSecureSocket class, which defaulted to TLS/1.0. I’m not sure what the Xojo.Net.HttpSocket uses by default.

Move to TLS 1.2, make sure both ends have the correct current system date/time. A NTP clock sync service is your friend here.

Our server runs centos 7 with TLS 1.2. After countless hours of testing we finally did a “yum update” command and the issue was resolved.

3 Likes