Hi list,

I'm currently trying to investigate about a little leak of memory in
the certificates loading, and I try to test ECDSA certificates and

I can't done this :( I don't understand anything in the ECDSA
certificate process.

So, after many fails with HAProxy, I tried to validate the concept only
with openssl. I used openssl 1.0.2j.

First I test classic RSA ciphers (I suppose that OpenSSL build its own
certificates ?):

   openssl s_server -accept 10000 -cipher RSA
   openssl s_client -connect -cipher RSA

That's run ! I tried with ECDSA. I ts exactily the same command but
with ECDSA ciphers.

   openssl s_server -accept 10000 -cipher ECDSA
   openssl s_client -connect -cipher ECDSA

That's no work. I read these error: "ssl3_get_client_hello:no shared
cipher". I don't understand because the server and the client are the
same binary, and I suppose that the cipher are obviously the same.

I have exactly the same behaviour with haproxy (I wrote a temporary
path for having the detail of the handshake errors). If I load only a
ECDSA certificate, and I enable only the ECDSA ciphers.

I run a tcpdump network capture, and I se that the client announce
the right list of ECDSA ciphers. In other way, the protocol used is TLS

   ... and others ...

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 \

   openssl req -new -key $CN.ecdsa.key -out $CN.ecdsa.csr -subj \

   openssl x509 -req -in $CN.ecdsa.csr -CA inter2.pem -CAkey \
      inter2.key -CAcreateserial -out $CN.ecdsa.cert -days 500000 \

Any ideas ?

PS: I can't neither test the DSA, but in this case, the openssl
s_client fail before trying to connect :) This is another story.


Thierry Fournier
m: +33 6 68 69 21 85      | e: thierry.fourn...@ozon.io
w: http://www.ozon.io/    | b: http://blog.ozon.io/

Reply via email to