2

I found my issue with the previous question I asked.

It appears as though when connecting between Windows Server 2003 and 2008 using SSLSTREAM in C# the servers are not able to agree on a common algorithm.

The exact SSPI Exception I get is:

"The client and server cannot communicate, because they do not possess a common algorithm"

I have tried using SSL2, SSL3, TLS1. I tried using Default, I tried installing the AES SSL hotfix for server 2003. It seems no matter what I do, there are no common algorithms..

Does anyone know how I can solve this?

Also, when I try the same code on Windows 7 The Server/Client agree on: Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

That was taken from wireshark.

Windows Server 2003 does not have that cipher, but it should have some that are compatible without having to enable the ones listed here:

http://technet.microsoft.com/en-us/library/cc766285(WS.10).aspx

Thanks for any help

Chris
  • 51
  • 5
  • I tried changing the group policy item to allow all the ciphers from win2k3 but no luck. – Chris Nov 30 '10 at 16:23
  • I don't know if this will solve your problem but maybe it's worth giving a try http://support.microsoft.com/kb/245030 (How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll) – andrei m Nov 30 '10 at 16:47
  • Well, what does wireshark show you for the case that failed? Does the server send a certificate in its server hello? – President James K. Polk Nov 30 '10 at 22:02

2 Answers2

1

I cannot figure out from your question which side is the server and which is the client, and maybe it doesn't matter. Although I'm not that familiar with those servers, I have seen similar errors when the server is not able to find its RSA private key, either due to misconfiguration or more often misunderstanding. The server must have access to both a private key and its matching public key (contained in its certificate) in order to complete an authenticated connection.

President James K. Polk
  • 40,516
  • 21
  • 95
  • 125
  • Client: Win2k3 Server: Wink2k8. The cert I was using is self-signed, and I was not the one who made it. It is password protected though (PK embedded?) I finally seem to have gotten this working by generating a new set of certificates using makecert. Is it possible the certificate I was using prevented certain ciphers from being used? – Chris Dec 02 '10 at 22:35
  • ahh, that might be it too. I also vaguely remember that some products may generate DSA certificates and keys instead of RSA. Those could also result in the error message you see. I'd know if I had a look at the wireshark capture file. – President James K. Polk Dec 03 '10 at 01:04
  • Thanks a lot for your help. I will try and simulate what happened before and post the results. I noticed that before, I was using a CA Root Certificate. Also the previous certs were using md5/rsa for the algorithm, hash and thumbprint. When I created new ones I am using Sha1/RSA for them. – Chris Dec 03 '10 at 20:26
  • 1
    For Posterity: I had a similar problem, and yes, windows (at least server 2003) won't use some ciphers if you generated the certificate with certain settings. The settings that worked for me: **makecert -pe -r -ss my -sr localMachine -n "CN=[DOMAIN NAME OR IP ADDRESS]" -e 01/01/2098 -a sha1 -eku 1.3.6.1.5.5.7.3.1 -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12** (See my question http://stackoverflow.com/questions/17141156 for more info) – MGOwen Jun 19 '13 at 00:52
0

The server likely tried to negotiate a SSLv3.0 connection with an AES cipher. That combination is technically illegal. See http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx?Redirected=true

EricLaw
  • 56,563
  • 7
  • 151
  • 196