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 --
