Many thanks for your detailed reply!
> You mentioned it 'does not post' - what do you mean exactly?
At artfulsoftware.net (StableHost), when it runs as https, Submit fails to populate $_POST with the form vars. eg...
$_POST remains empty.
The form posts fine as https from local Windows instances when the script runs at another host (MDD Hosting). It also posts fine when it posts to another https artfulsoftware.net page. And it self-posts fine when it runs as http.
> What does the browser devtool console say?
> If it's a browser specific error it will show in the browser console
It happens with Chrome, Edge, Firefox, Opera.
And as above, it posts fine as https at MDD Hosting.
> On windows you can debug http calls by installing Fiddler,
> enabling Tools > Options > Https> Decrypt Https traffic, and
> inspecting the http request/response (Download Fiddler Web
> Debugging Tool for Free by Telerik).
Again thanks, I'll install Fiddler and see if I can discern anything interesting about the http response.
> Look out for a proxy server that may be blocking something,
> (see also Malware Bytes software etc).
None of these 'puters uses a Proxy. MWB found nothing.
> The first question would be does that client
> use a proxy to connect to the internet,
The same script posts fine, running as https from these Windows clients at another host (MDD Hosting), which also uses Let's Encrypt.
The problem occurs from four Windows computers here, two using build 19042 of Win 10, one using an earlier build, one using Win 7 Pro. On this Win 10 build 19042 machine it happens with Chrome & Edge, and with freshly installed Firefox & Opera.
The problem does not occur from Linux or Android clients.
> if so could it be blocking because it thinks this PHP endpoint is malware?
Could this AT&T Arris router be making mischief? I need to run this script from Windows connected to a hotspot.
> Your form prompts for 'username' and 'password' fields ...
If that were the problem, it wouldn't post at MDD Hosting either unless there's corruption at StableHost.
> Make sure you don't have mixed content (http and https resources on the same page).
As above. And it posts fine when invoked as http.
> Check also that the server and the client (windows) both
> support a compatible combination of SSL/TLS cipher suites.
As above, two Win instances are version 10 build 19042. Since StableHost changed ownership, I trust them little. The form runs fine as https from these Windows instances at MDD Hosting, so it doesn't appear to be a local client configuration issue (unless the router here has identified the StableHost url as a threat.
That leaves StableHost as the issue, but they've been slow to get past the stage of "let's you buy better SSL".
> Note that none of this is really related to Let's Encrypt.
The question was, would another SSL implementation fix this? From what you've said, no. If it's local, it will post for Windows testers who aren't on this router. I'll test that today.
Many thanks for your many tips.