Below is the method we use to process the incoming handshare messages - during the
#Schannel fatal alert 70 windows terminal server 2008 r2 code#
The SChannel code for the handshake process is pretty straightforward - I've reviewed it and don't see any problems (though I'm not an SChannel expert by any means). The cipher suite chosen is SSL_RSA_WITH_RC4_128_SHA - again I can verify that on the Java side but not on the SChannel side. I am able to get the session key from the Java side but have not found a way to extract it from SChannel so I have been unable to compare the two sides. It seems that the client and server think they agree on the cipher suite and session key but in factĪre not using the same values, otherwise I don't see how SChannel is unable to decrypt the first message. I've debugged this on both ends and sniffed the network and don't see anything wrong with the message flow or how we deliver the messages to SChannel. For some reason, Java SSLSocket prefers to use SSL v3 - I have forced Java to use TLS v1 but that also fails. Have also enabled all cipher suites on the 2008 R2 server and it still fails. I set the 2008 server to only use MD5 but that did not help. I The handshake. Comparing the Java client connecting to the server running on 2003 vs 2008 R2, the only real difference is that 2003 uses MD5 for the hashing algorithm whereas 2008 uses SHA1. Key Exchange and Change Cipher Spec messages - the cipher suite and session key have been agreed upon but when the Java client sends the finished message, the first one to be encrypted using the session key, the server is unable to decrypt it and we abort Up to this point, the server has successfully processed the Client Hello, Client The handshake process fails right at the end when the server is processing the client's handshake finished message, AcceptSecurit圜ontext returns the error SEC_E_DECRYPT_FAILURE. Java's SSLSocket to create an SSL connection and it fails in the same manner against the server running on 2008 R2.
I wrote a simple Java application that just takes an address and port and uses
The native client can complete the handshake to either server. The Java client, which uses the very simple Java SSLSocket class,Ĭan successfully connect to the server when the server runs on Windows 2003 but fails when the server is on 2008 R2. We recently discovered that when the server is run on 2008 R2, one of our clients, written in Java, is unable to complete the SSL handshake while the other one, native, can. Our server uses an Schannel implementation that was written about nine years ago and has been working well I am having a problem with our SChannel server implementation on Windows 2008 R2 that does not happen when running the same server on Windows 2003.
0 kommentar(er)
