Hi, Thanks guys for the tips. I can connect to haproxy with ECDSA cipher using the following cipher string on the OpenSSL client side:
openssl s_client -connect 127.0.0.1:10000 -cipher ECDSA:EECDH:ECDH and this string in the haproxy configuration: ssl-default-bind-ciphers "ECDSA:EECDH:ECDH" and only ECDSA certificates. The negociated cipher is "AECDH-AES256-SHA", and I don't know if this cipher is ECDSA :) At least it seems to work. Thierry On Tue, 11 Oct 2016 15:32:04 -0700 Bryan Talbot <bryan.tal...@playnext.com> wrote: > > > On 12 Oct 2016 8:45 am, "Igor Cicimov" <ig...@encompasscorporation.com > > <mailto:ig...@encompasscorporation.com>> wrote: > > > > > > On 11 Oct 2016 7:05 pm, "Thierry Fournier" <thierry.fourn...@ozon.io > > > <mailto:thierry.fourn...@ozon.io>> wrote: > > > > I'm currently trying to investigate about a little leak of memory in > > > > the certificates loading, and I try to test ECDSA certificates and > > > > cipher. > > > > > > > > I can't done this :( I don't understand anything in the ECDSA > > > > certificate process. > > > > > > > > My test certificate is generated from a little chain where the root CA > > > > is autosigned. So the root CA and the 2 intermediate are RSA > > > > certificates. The ECDSA certificate is build with these commands: > > > > > > > > openssl ecparam -name secp521r1 -genkey -param_enc explicit -out \ > > > > $CN.ecdsa.key > > > > > > > I ran into this as well and it turns out that s_client and s_server do not > seem to play nicely with curves when using -param_enc explicit and instead > prefer to only deal with named curves. > > Encode the key params using named curve that both sides can accept and your > test should work. > > Also, see > https://groups.google.com/forum/#!topic/mailing.openssl.users/Rg6yV4ccWeo > <https://groups.google.com/forum/#!topic/mailing.openssl.users/Rg6yV4ccWeo> > > -Bryan > > -- Thierry Fournier Web Performance & Security Expert m: +33 6 68 69 21 85 | e: thierry.fourn...@ozon.io w: http://www.ozon.io/ | b: http://blog.ozon.io/
