Nelson B Bolyard wrote:
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.
I got some info from Glenn and I was told to try vfyserv and that worked
out OK with the right switches:
vfyserv -p 9443 -C :c005 mink.pki -d .
He also had me build NSS/NSPR/JSS a little differently. I used the head
for each and it was working ok. I need to go back now and use the RTM
versions and see if things are still ok. The server I'm contacting is a
FC8 box running Dogtag so ultimately NSS/JSS are the libraries being
used to serve the pages. Now, those are custom built to support the 3rd
party EC module as instructed on their wiki pages and all certs in the
chain are using NIST P384 curve. One of the things Glenn had me do
differently is use the extended EC env var and pull a specific version
of the eccurve header file after checking out the other pieces.
Knowing I need to explicitly enable the newer ciphers helps.
As an aside, the usage for vfyserv would be a lot better if it told you
what format it was expecting the Ciphers in...I had to browse the source
and do some trial and error to figure out ":c005".
Dave
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
