While researching how to capture socket data to Wireshark, from my locally hosted page, I accidentally stumbled upon an article saying that "Certificate Verify" isn't sent over TLS 1.2 in "newer versions of Windows" (like Windows 10).

So I changed the protocol to TLS 1.0 and the request went through:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;

With TLS 1.1 I get an exception, unlike what the guy in that article said:

(WebException) The request was aborted: Could not create SSL/TLS secure channel.

Why this worked isn't something I have time to investigate currently, as I'm already way behind schedule debugging this issue, but it sounds to me like a bug, much like another user claimed in another question.

I found a Microsoft article along these lines saying:

This issue only occurs with servers that downgrade the TLS session in an ungraceful way (such as by sending a TCP reset when receiving a TLS protocol version that the server does not support)

But since I start in TLS 1.2, and the server clearly accepts TLS 1.2 (via Postman and Chrome), it must be a tiny part of the TLS 1.2 protocol that isn't implemented the same way or something. I still don't understand how the Postman native Windows app manages to use TLS 1.2 though.

It may be worth noting that Internet Explorer first attempts TLS 1.2, and then after 2 resets (like my client), it just downgrades to TLS 1.0 and gets through. To me this sounds very similar to the update to Internet Explorer talked about in the article:

I realize this is not a great answer (when it comes to details of "why"), but at least it gives a hint as to what one might try if coming across similar issues.

If anyone understands this issue, and perhaps even knows how I can support TLS 1.2, then I'd appreciate it very much.