OpenSSL 1.1.1 Windows dependencies

[David Harris]

Up front, I'd like to apologize if this is an FAQ or has been answered elsewhere 
on this list: my workload means that I simply can't keep as up-to-date as I would 
like.

I have a situation where my application fails to accept an incoming SSL 
handshake on Windows Server 2012, but the identical software running on 
Server 2019 accepts the same connection from the same remote client without 
a problem. Other types of client software (such as Thunderbird) connect to 
either system without any problems. The connecting client is a Windows Cash 
Register using Window's built-in crypto facilities. If I downgrade my app to 
OpenSSL 1.1.1g or earlier, the problem doesn't happen. With 1.1.1k or 1.1.1q, I 
get the error (I haven't built any versions of OpenSSL between k and q). In case 
it helps, the connection is an incoming SMTP connection on port 587, and 
STARTTLS is used to begin SSL negotiation.

SSL_accept returns -1, with an extended error of "SSL_ERROR_SYSCALL" (5), 
which I understand to be largely what it returns when it doesn't have a clear idea 
of what's gone wrong. The error queue is completely empty in this situation. The 
cert is a LetsEncrypt cert that loads without errors and works fine with other 
clients.

Do recent versions of OpenSSL 1.1.1 have dependencies on some Windows 
facility (winsock and wincrypt seem likely candidates) that might work on Server 
2019 but fail on Server 2012?

The version of my application that is in public release uses 1.1.1g, so isn't 
affected by this issue, but I'm slightly worried that I'm going to see an uptick in 
this type of problem if I release builds based on later versions of 1.1.1.

Does this ring any bells with anyone? Again, apologies if this is answered 
elsewhere - I *did* spend some time in Google but couldn't find anything that 
seemed relevant.

Thanks in advance for any advice.

Cheers!

-- David --