Hi David, I just did a check to see what Windows libraries the openssl.exe app depends on, going back to look in 1.0.2, and looking at the current development branch (master). 1.0.2: ws2_32.lib (cond: no-sock) gdi32.lib advapi32.lib crypt32.lib user32.lib bufferoverflowu.lib (cond: cl version 14+) unicows.lib (cond: win32 && -DUNICODE) master: ws2_32.lib (cond: no-sock) gdi32.lib advapi32.lib crypt32.lib user32.lib bufferoverflowu.lib (cond: cl version 14+) As you can see, it hasn't changed much (the unicows.lib dependency was there for Win9x compatibility, according to comments). But, it's quite possible that those libraries have dependencies of their own that have changed in newer Windows versions. Let me ask you this: on what Windows version was your application built? Common wisdom would be to build on the oldest version... Cheers, Richard On Thu, 20 Oct 2022 02:54:19 +0200, David Harris wrote: > > 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 -- > -- Richard Levitte levitte@xxxxxxxxxxx OpenSSL Project http://www.openssl.org/~levitte/
