> From: owner-openssl-us...@openssl.org On Behalf Of Ratin, Yuliya S. > Sent: Wednesday, 26 October, 2011 09:55
> Connection to SQL Server 2008 R2 database (cluster install) > We're seeing the connection reset while testing from multiple > sources and applications - it seems like the server is not responding > with an SSL certificate during the handshake, here's the output from > OpenSSL's s_client (error 104 indicates a connection reset): Aside: 104 is reset only on Linux, other OSes are different. > OpenSSL> s_client -host 10.0.5.31 -port 1433 -prexit > CONNECTED(00000003) > write:errno=104 > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 0 bytes and written 118 bytes > <snip> It's not that the server is omitting the cert specifically, the server (or perhaps something in between) is resetting BEFORE the handshake gets to the message(s) that would carry the cert, and also several other things. Are you sure the server is ready for SSL? I don't use this SQLSvr option, but from the description in the MSDN it sounds like it does clear and SSL alternatively over the same port. That means it must start in clear and have some explicit command to switch to SSL. Many protocols do this, e.g. SMTP, FTP, often using command STARTTLS. OpenSSL s_client supports several of these (see the help, or man page) but not SQLSvr. (In contrast, HTTPS uses a different port, 443 instead of 80, and starts right in.) If the server is expecting SQLSvr-type packet (in clear), and it gets SSL ClientHello instead, it will have to reject it, and might well do so by a connection reset. If you can find the start-SSL command (or perhaps sequence) in documentation or from a network trace, you could modify s_client to do it, or write a stripped-down version which just does the SQLSvr-specific start-SSL then SSL_connect, with suitable callbacks/tracing. This may be some work. For the java, I'd expect com.microsoft.sqlserver.jdbc.* to handle this correctly, assuming it's honestly named. If the/a client is on a different machine than the server, I'd look at a network trace. If a client is on or near Windows I like www.wireshark.org but there are others. You also say the server is in a cluster. I don't know if that involves some redirector between client and server; if so, that could be the source of the reset rather than the actual server. If you can use a non-cluster server instead, and see if/how that differs, it might help. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
