Under Let's Encrypt at one host, an elementary php/html login form coded to post back to itself does not post when the page is accessed via https from Windows, but functions normally under https when accessed from Linux, and functions normally always under http.
At another host under Let's Encrypt, the page functions normally.
It seems natural to conclude that a problem other than Let's Encrypt is responsible for this problem, Suggestions please.
Welcome to the Let's Encrypt Community 
Please check where your form is being posted.
You might have some redirection issues or other troubles related to rewrites in a webserver configuration file or .htaccess file.
Thanks, I'll follow that up.
It posts to itself.
At one host only, posting to itself fails from Windows if the page runs under https.
Posting to another page works fine.
Same problem with and without an .htaccess file.
Your redirect url finds "everything ok".
Strange---such forms fail at one host only, at that host only when
(1) the form is running from Windows,
(2) the form is invoked with https.
(3) it posts to itself
What webserver config could bring that about?
You mean the form is running from IE or Edge, right? I believe this may be browser-specific and that your form design or transmission is incompatible with that browser.
That depends upon how the POST request is being structured by the browser. If the host in the request isn't formatted correctly, disaster can occur at many levels.
Same result with Edge, Chrome, Firefox and Opera.
Vanilla html in a vanilla php script.
Same behaviour with
Call the form with http instead, it runs fine.
Odd... 
At an OS level this seems unlikely. It's almost like it's being filtered outside the browser then.
My own ACME client (CertSage) is written entirely in PHP/HTML5 and uses standard form posts. I've never encountered any problems with running it over https in Windows. I just checked and saw that I don't even have an action attribute in the form tag.
There has to be something different about the POST requests coming from Windows. Dumping the entire incoming requests in your PHP script (with the headers) might help.
Thanks, I'll give that a lash.
Personally, I believe we can guess here all we want, but most helpful would be if we can actually see and test the form. If it's not possible to use the actual form for public use, perhaps you could copy the situation to a location which is accessible by us on some kind of test location and has the same erroneous behaviour as you're getting now.
Sure, no problem ... the form is at
/test/testpost.php. At griffin's suggestion, for now, it displays getallheaders() info. It's happy when it gets 123456 submitted & posted back to itself as username & password. At this host only, it fails when it runs under https from a Windows browser.
I don't have a Windows system at hand currently, so I can't test it failing, but perhaps you also have a test setup with a working host? So users without Windows can compare on a TLS level. (If TLS is even the issue here, I dunno.. Could also be something else of course..)
Here are the headers running on FireFox under Ubuntu
[Host] => www.artfulsoftware.net
[User-Agent] => Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0
[Accept] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
[Accept-Language] => en-US,en;q=0.5
[Accept-Encoding] => gzip, deflate, br
[upgrade-insecure-requests] => 1
[te] => trailers
And here are the headers under Chrome from Windows ...
(
[Host] => www.artfulsoftware.net
[Cache-Control] => max-age=0
[sec-ch-ua] => " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
[sec-ch-ua-mobile] => ?0
[upgrade-insecure-requests] => 1
[origin] => https://www.artfulsoftware.net
[Content-Type] => multipart/form-data; boundary=----WebKitFormBoundaryTApCa8sUEkSQPhPz
[User-Agent] => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
[Accept] => text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
[sec-fetch-site] => same-origin
[sec-fetch-mode] => navigate
[sec-fetch-user] => ?1
[sec-fetch-dest] => document
[Referer] => /test/testpost.php
[Accept-Encoding] => gzip, deflate, br
[Accept-Language] => en-US,en;q=0.9
[Cookie] => sess1626805960=c674c0b8144709b2bc8358a2b108f57d; sess1626805974=77bfb56bb69ad5fb410add62dcf68a4f; sess1626806265=6e98ceb573f9f8ea42e4aa2d945929be; sess1626806399=fad8b07db9ba176636a2d1878b963e0f; sess1626807109=401aebf3c8aa5b0a40b7a7c04a406c7b; sess1626807393=f1dddb2763f4864253e0a01ef49bda37
)
You mentioned it 'does not post' - what do you mean exactly? I tested it on Windows and it posts just fine.
What does the browser devtool console say? If it's a browser specific error it will show in the browser console either on networking or javascript/debug console.
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).
Look out for a proxy server that may be blocking something, (see also Malware Bytes software etc). The first question would be does that client use a proxy to connect to the internet, if so could it be blocking because it thinks this PHP endpoint is malware? Your form prompts for 'username' and 'password' fields, which a phishing form would also do, so it could just be being blocked. Some browser security extensions also block this stuff. Make sure you don't have mixed content (http and https resources on the same page).
Check also that the server and the client (windows) both support a compatible combination of SSL/TLS cipher suites. For instance a windows 7 client (or older!) might try to use an out of date cipher to communicate that your server isn't configured to support
Note that none of this is really related to Let's Encrypt.
Christopher,
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...
POSTed:array(3) {
["mode"]=>
string(5) "login"
["username"]=>
string(6) "123456"
["password"]=>
string(6) "123456"
}
$_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?
Nothing interesting.
> If it's a browser specific error it will show in the browser console
> either on networking or javascript/debug 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.
PB
Yeah that pretty weird. If the $POST is coming back empty on submit it seems like something has redirected the request (is there any form of URL rewriting being applied?) and dropped the form post. So that was the first suggestion as made by @griffin
Fiddler will tell you if something is redirecting (as would chrome devtools > network [Preserve Log = Yes]), but it won't tell you if there is a man-in-the-middle system performing traffic interception. Double check the identity of the SSL certificate from an affected host to ensure that the issuer is Let's Encrypt. If it's not then it a man-in-the middle (proxying system which terminates TLS so it can inspect and modify traffic).