David Stutzman wrote, On 2009-02-23 08:00: > Using NSS 3.12.2 RTM or NSS 3.11.4 RTM, I get: > org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed: > (-12286) Cannot communicate securely with peer: no common encryption > algorithm(s).
> Stepping back and eliminating JSS, I get similar errors if I use NSS's > command line SSL clients directly: > > NSS 3.12.2: > tstclnt -h ecserver -p 9443 -d . > tstclnt: read from socket failed: Cannot communicate securely with peer: > no common encryption algorithm(s). By default, for reasons of backward binary compatibility, NSS does not enable any new cipher suites that have been added to NSS since NSS 3.0. That means that none of the new ECC cipher suites are enabled unless you explicitly enable them. That's equally true of 3.11.x and 3.12.x. Your tstclnt command lacks the option that enables specific cipher suites. I suspect that if you enable the cipher suites your server supports, it may get farther. BTW, I have written a little sample program that tells you all the cipher suites that are supported by your NSS shared SSL library. It also tells you what cipher suites are enabled by default, and certain other info. Find the source code for it attached to bug https://bugzilla.mozilla.org/show_bug.cgi?id=480076 Try it with NSS 3.11.x and with 3.12.x and diff the two outputs to see what's changed. > Interestingly, with the firefox 3.12.2 NSS libs (and the 3.12.2 command > line tools), tstclnt sits in a loop and never exits of: > tstclnt: about to call PR_Poll ! > tstclnt: PR_Poll returned! > tstclnt: PR_Poll returned 0x00 for stdin out_flags. > tstclnt: PR_Poll returned 0x01 for socket out_flags. > tstclnt: PR_Poll returned 0x01 for socket out_flags. > tstclnt: Read from server -1 bytes tstclnt is able to support protocols in which the client speaks first, and protocols in which the server speaks first. By default, it supports protocols in which the server speaks first. To make it support protocols in which the client speaks first, use the -f command line option. Most IETF applications protocols are server-speaks-first protocols. HTTP is an exception. With it, client speaks first. The effect of the -f flag is somewhat negligible on Unix, but on Windows it makes a BIG difference. I suspect that you did the above test on Windows. Try it with -f. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
