Wildfly SSL/TLS connection failed, previously working

I have an application on Wildfly 16 that was shut down 2 years ago, but was working fine at the time. I recently restarted it, but am now getting an "SSL/TLS connection failed" error, and am not sure why.

We have other applications on the same Windows server running fine on other Wildfly 16 instances. They all point to the same shared keystore.jks (updated 10 months ago). There are no errors in any log file, and in fact the server.log seems to indicate it's listening fine:

[org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0006: Undertow HTTPS listener https listening on 0.0.0.0:19043

CURL to a 'working' port looks like this: (In example, 'myfake.domain' and ip '155.5.555.555' are not the real values.)

>curl -v https://myfake.domain.com:18743*   Trying 155.5.555.555:18743...* Connected to myfake.domain.com (155.5.555.555) port 18743* schannel: disabled automatic use of client certificate* ALPN: curl offers http/1.1* ALPN: server did not agree on a protocol. Uses default.* using HTTP/1.x> GET / HTTP/1.1> Host: myfake.domain.com:18743> User-Agent: curl/8.4.0> Accept: */*

CURL to the 'failing' port:

>curl -v https://myfake.domain.com:19043*   Trying 155.5.555.555:19043...* Connected to myfake.domain.com (155.5.555.555) port 19043* schannel: disabled automatic use of client certificate* ALPN: curl offers http/1.1* schannel: failed to receive handshake, SSL/TLS connection failed* Closing connection* schannel: shutting down SSL/TLS connection with myfake.domain.com port 19043curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

Here's one more CURL to the 'failing' port provided by another user, that maybe gives a bit more info:

curl https://myfake.domain.com:19043 -v         * Rebuilt URL to: https://myfake.domain.com:19043/*   Trying 155.5.555.555...* TCP_NODELAY set* Connected to myfake.domain.com (155.5.555.555) port 19043 (#0)* ALPN, offering h2* ALPN, offering http/1.1* successfully set certificate verify locations:*   CAfile: /etc/pki/tls/certs/ca-bundle.crt  CApath: none* TLSv1.3 (OUT), TLS handshake, Client hello (1):* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to myfake.domain.com:19043* Closing connection 0curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to myfake.domain.com:19043

I've done a complete comparison of the full Wildfly directories between the 'working' and 'failing' apps, and have not found any key configuration differences between the two. The 'working' applications have had internal jar file changes over the past couple years, including some undertow jars. But I'm not certain if that would contribute to a previously working and untouched application now failing.

What else should I be checking? In the past 2 years, what else could have changed? Something on the Windows server itself?