And some diag suggestions about the error returned by the browser:
First, what the error narrows down
PR_CONNECT_RESET_ERROR is Firefox's way of saying it received a TCP RST, not a TLS alert. That distinction is the most useful clue you have:
- A plain protocol or cipher mismatch normally produces a clean TLS
handshake_failure alert, and Firefox reports SSL_ERROR_NO_CYPHER_OVERLAP or SSL_ERROR_PROTOCOL_VERSION_ALERT. - An RST means something tore the socket down instead of answering — HTTP.sys aborting before it could build a credential, a middlebox interfering, or the server killing the connection after the ClientHello.
So look first at things that make the listener fail rather than negotiate.
Most likely causes, roughly in order
Broken Schannel credential / private key access. HTTP.sys can't build the server credential, so it resets. Classic symptoms are Schannel event 36870 (0x8009030D) or 36871 in the System log. Causes: private key ACLs on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, a certificate imported without its key, or a cert whose keyset broke after a renewal or restore.
Missing or orphaned HTTP.sys SSL binding. The IIS site binding exists in the UI but netsh http show sslcert shows no entry for that IP:port, or shows one with a stale certhash/appid. Very common after a certificate renewal done outside IIS Manager, or after a site was recreated.
SNI mismatch. A binding set to Require Server Name Indication with a client or health-check that doesn't send SNI, or two bindings on the same IP:port where only one has SNI. Also relevant if you use Centralized Certificate Store and the .pfx filename doesn't match the requested hostname — CCS resets rather than falls back.
Over-aggressive hardening. IIS Crypto templates, CIS baselines, or the SSL Cipher Suite Order GPO. Two specific traps here: the GPO string is limited to 1023 characters, so a long cipher list gets silently truncated and can leave an unusable set; and restricting ECC Curve Order (e.g. to P-384 only) will break clients that only offer P-256. Enabling FIPS mode (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy) has a similar effect.
Client certificate configuration. Require client certificate combined with TLS 1.3, or with renegotiation disabled, is a known source of resets on Server 2022. Try setting the SSL negotiation to Accept rather than Require, or pin the site to TLS 1.2, as a test.
Something in the path. Firewall/IPS with TLS inspection, a load balancer with its own cipher policy, or endpoint antivirus doing HTTPS scanning. Test from a machine on the same subnet as the server to rule this out.
How to pin it down
Enable verbose Schannel logging, then reproduce:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v EventLogging /t REG_DWORD /d 7 /f
That requires a reboot to take full effect. Watch the System log for 36870, 36871, 36874, 36887 and 36888 — the internal error state number in those events is what actually identifies the failure.
Then check the binding layer:
powershell
netsh http show sslcert
Get-WebBinding | Format-List
And test the handshake directly from a client, which tells you whether the server answers at all:
openssl s_client -connect yourhost:443 -servername yourhost -tls1_2
openssl s_client -connect yourhost:443 -servername yourhost -tls1_3
If TLS 1.2 works and 1.3 resets (or vice versa), you have your answer immediately. If the ClientHello gets an RST with no ServerHello at any version, it's a credential or binding problem, not a cipher problem.
Finally, check C:\Windows\System32\LogFiles\HTTPERR\ — HTTP.sys logs connection-level aborts there with reason codes, and the IIS site logs will show nothing at all for these requests (which itself confirms the connection died before HTTP.sys handed it to IIS).
One note: this is unrelated to the session ticket key warning from your earlier question — that one degrades performance but never resets connections.